Remove src/sysv-generator
sysv-generator: initialize LookupPaths just once With debugging on, sysv-generator would print the full set of lookup paths for *every* sysv script. While at it, pass LookupPaths as a pointer in sysv-generator, and constify it everywhere.
remove unused includes This patch removes includes that are not used. The removals were found with include-what-you-use which checks if any of the symbols from a header is in use.
sysv-generator: fix wrong "Overwriting existing symlink" warnings 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
everywhere: remove configurability of sysv runlevel to target mapping With this change runlevel 2, 3, 4 are mapped to multi-user.target for good, and 5 to graphical.target. This was already the previous mapping but is now no longer reconfigurable, but hard-coded into the core. This should generally simplify things, but also fix one bug: the sysv-generator previously generated symlinks to runlevel[2-5].target units, which possibly weren't picked up if these aliases were otherwise only referenced by the real names "multi-user.target" and "graphical.target". We keep compat aliases "runlevel[2345].target" arround for cases where this target name is explicitly requested.
sysv-generator: Skip init scripts for existing native services 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.
sysv-generator: no need to check for identical symlinks source and target twice http://lists.freedesktop.org/archives/systemd-devel/2015-January/027594.html
sysv-generator: Re-fix .sh suffix handling Commit 4e48855534 caused the .sh suffix to be stripped from the original "filename", which caused the generated units to call the wrong init.d script. Only use the .sh stripped file name for comparing with Provides:, not for generating the Exec*= lines. Spotted by sysv-generator-test.
sysv-generator: there's really no need to invoke fstatat() multiple times on the same sysv script It's sufficient to check once if something is a regular file, hence, let's do that.
sysv-generator: use is_symlink() utility call where appropriate
sysv-generator: minor simplifications
sysv-generator: only allow regular files in enumerate_sysv() Otherwise, if the directory contains other directories we fail at fopen in load_sysv() with EISDIR.
sysv-generator: Replace Provides: symlinks with real units 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
sysv-generator: Handle .sh suffixes when translating Provides: 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
sysv-generator: always use fstatat() if we can
sysv-generator: fix memory leak on failure This fixes a memory leak introduced by 1ed0c19f81fd13cdf283c6def0168ce122a853a9
sysv-generator: initialize units before use to ensure correct ordering The original loop called fix_order() on each service immediately after loading it, but fix_order() would reference other units which were not loaded yet. This resulted in bogus and unnecessary orderings based on the static start priorities. Therefore call load_sysv() for every init script when traversing them in enumerate_sysv(). This ensures that all units are loaded when fix_order() is called. Bug-Debian: https://bugs.debian.org/771118
sysv-generator: handle Provides: for non-virtual facility names The list of provided facility names as specified via Provides: in the LSB header was originally implemented by adding those facilities to the Names= property via unit_add_name(). In commit 95ed3294c632f5606327149f10cef1eb34422862 the internal SysV support was replaced by a generator and support for parsing the Names= option had been removed from the unit file parsing in v186. As a result, Provides: for non-virtual facility was dropped when introducing the sysv-generator. Since quite a few SysV init scripts still use that functionality (at least in distros like Debian which have a large body of SysV init scripts), add back support by making those facility names available via symlinks to the unit filename to ensure correct orderings between SysV init scripts which use those facility names. Bug-Debian: https://bugs.debian.org/774335
util: rename ignore_file() to hidden_file() hidden_file() is a bit more precise, since dot files usually shouldn't be ignored, but certainly be considered hidden.
core: warn and ignore SysVStartPriority= Option was being parsed but not used for anything.