This is useful on systems like NixOS, where python3 is not in
/usr/bin/python3 as well as for people using alternative ways to
install python such as virtualenv/pyenv.
~ suffix works fine, but looks to much like it the file is supposed to be
automatically cleaned up. For new versions of configuration files installers
might want to using something that looks more permanent like foobar.new.
So let's add treat ".old" and ".new" as special.
Update test to match.
If there is a lot of initscripts and dependencies between them we might
end generating After= (and similar) lines which are longer then LINE_MAX
and thus rejected by parser in systemd.
Fixes#2099
test_simple_escaped() sometimes fails with
AssertionError: Lists differ: ['foo\\x2b.service', 'foo-admin.service'] != ['foo-admin.service', 'foo\\x2b.service']
We don't need to assume any order here, so compare them as a set, not a list.
Set $SYSTEMD_LOG_TARGET so that the output always goes to stdout/stderr. This
fixes running the test as root, as that logged to the journal previously.
https://github.com/systemd/systemd/issues/195
Fix result testing of is_symlink() to ignore negative results, which happen if
the file name does not exist at all. In this case we do not want a warning and
unlink the non-existing link.
https://bugs.debian.org/778700
Commit d5d8429a dropped the explicit runlevelN.target mapping. Adjust the tests
accordingly to explicitly state the expected targets instead of runlevels.
This avoids taking the SysV init script enablement state into account if we
have native units. Otherwise systemctl disable on native unit would not
be respected in the presence of an enabled SysV script.
Also, there's no need to do all the parsing and creation of service files if we
already have a native systemd unit for the processed SysV init script.
Since commit b7e7184 the SysV generator creates symlinks for all "Provides:" in
the LSB header. However, this is too greedy; there are cases where the
creation of a unit .service file fails because of an already existing
symlink with the same name:
- Backup files such as /etc/init.d/foo.bak still have "Provides: foo", and
thus get a foo.service -> foo.bak.service link. foo.bak would not be enabled
in rcN.d/, but we (deliberately) create units for all executables in init.d/
so that a manual "systemctl start" works. If foo.bak is processed before,
the symlink already exists.
- init.d/bar has "Provides: foo", while there also is a real init.d/foo. The
former would create a link foo.service -> bar.service, while the latter
would fail to create the real foo.service.
If we encounter an existing symlink, just remove it before writing a real unit.
Note that two init.d scripts "foo" and "bar" which both provide the same name
"common" already work. The first processed init script wins and creates the
"common.service" symlink, and the second just fails to create the symlink
again. Thus create an additional test case for this to ensure that it keeps
working sensibly.
https://bugs.debian.org/775404
When deciding whether the provided name equals the file name in
sysv_translate_facility(), also consider them equal if the file name has a
".sh" suffix.
This was uncovered by commit b7e7184 which then created a symlink
"<name>.service" to itself for ".sh" suffixed init.d scripts.
For additional robustness, refuse to create symlinks to itself in add_alias().
Add test case which reproduces the bug.
https://bugs.debian.org/775889
Jörg Thalheim