summaryrefslogtreecommitdiff
path: root/test/sysv-generator-test.py
AgeCommit message (Collapse)Author
2015-02-19sysv-generator: fix wrong "Overwriting existing symlink" warningsMartin Pitt
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
2015-02-19systemd-sysv-generator test: Adjust to dropped runlevelN.target mappingMartin Pitt
Commit d5d8429a dropped the explicit runlevelN.target mapping. Adjust the tests accordingly to explicitly state the expected targets instead of runlevels.
2015-02-11sysv-generator: Skip init scripts for existing native servicesMartin Pitt
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.
2015-01-21sysv-generator: Replace Provides: symlinks with real unitsMartin Pitt
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
2015-01-21systemd-sysv-generator test: test scripts with hidden suffixesMartin Pitt
We don't expect any unit generated from temporary package manager, swap, and similar files.
2015-01-21sysv-generator: Handle .sh suffixes when translating Provides:Martin Pitt
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
2015-01-21systemd-sysv-generator test: fix enabled checkMartin Pitt
Fix hardcoded "foo.service", test for the actual unit parameter.
2015-01-21systemd-sysv-generator test: don't parse symlinksMartin Pitt
Generated services which are symlinks should be tested/handled differently from files, so ignore them in run_generator()'s result parsing.
2015-01-21test: add integration test for systemd-sysv-generatorMartin Pitt
This covers the general functionality as well as regression tests for recent fixes like commits b7e718 and 1ed0c19.