Hi Martin, Am 20.01.2015 um 17:46 schrieb Martin Pitt: > > Michael Biebl [2015-01-15 1:25 +0100]: >>>> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=7024b5117a >> >> A user reported a nasty regression via IRC regarding this patch. >> For SysV init scripts having a .sh extension, we create a foo.service -> >> foo.service symlink, and subsequently, systemctl start/stop/restart >> foo.service will fail: > > Confirmed. I got a bit tired with the sysv generator and finally sat > down to write a test suite now (discussing with upstream, I'll land > this in the next days). > > For this particular bug I just created a fix: > http://lists.freedesktop.org/archives/systemd-devel/2015-January/027224.html > > I'll upload -10 with the fix ASAP.
I looked into this a bit more myself. Unfortunately, those .sh suffixes are not the only ways to trigger this particular bug. As can be seen in [1], this can also be caused by backup/temporary files, i.e. the name of the sysv init script no longer matches the name in the Provides: field, and therefor we create a symlink and subsequent creation of the real unit file fails. I wonder, if this this needs a more elaborate fix, like creating those symlinks *after* the unit files have been generated. And also, ignoring any sysv init scripts which aren't enabled (so we don't consider such backup/temporary files). The alternative would be, to back out this change again, which in turn though, would break the ordering for certain init scripts. Does the release team have any preference? Michael [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775404#15 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
