Bug#803373: systemd: fail to enable/disable services that have no LSB init script
On 29/10/2015 14:05, Martin Pitt wrote: > Control: tag -1 moreinfo unreproducible > > Hello Luca, > > Luca Bruno [2015-10-29 12:29 +0100]: >> I've put a simple service in /lib/systemd/system. Doing systemctl >> start/stop on this service works correctly, however enable/disable >> doesn't work: "Failed to execute operation: No such file or directory". > Did you systemctl daemon-reload after placing the file there? What's > the exact file name you are adding and which command do you run? Does > this involve Alias= or templates? Does your file perhaps refer to a > nonexisting WantedBy= or RequiredBy=? > > I tried to reproduce this here: > > # cat << EOF > /lib/systemd/system/foo.service > [Unit] > Description=test > [Service] > Type=oneshot > ExecStart=/bin/echo hello > [Install] > WantedBy=multi-user.target > EOF > # systemctl daemon-reload > # systemctl enable foo.service > Created symlink from /etc/systemd/system/multi-user.target.wants/foo.service > to /lib/systemd/system/foo.service. > > So all as expected. I'm afraid we need a more detailled reproducer. > >> The reason is that my systemd service has no LSB init script. > That should be fine. We do call update-rc.d *if* there is an LSB init > script, but we have plenty of units even in a default install which > don't have one (e. g. hwclock-save.service). > >> By doing a touch /etc/init.d/servicename then enable/disable works, >> though update-rc.d will spit out some warning. > Interesting. So somehow your new unit thinks there is a SysV init > script and tries to call update-rc.d. > >> I can see this behaviour only on debian, so pretty sure it must caused >> by one of the 200+ patches. > The vast majority of them are actually ones from 215-stable and > cherry-picked ones from newer upstream versions, it's not actually > that bad. > > Do you have a chance to try this under testing/unstable? The whole > SysV init script handling got dramatically simplified there. > > Thanks, > > Martin > I installed a new service on a new jessie and didn't happen. I think it this bug can be closed for now, I guess it must have been something weird on my side... Thanks. Best regards,
Bug#803373: systemd: fail to enable/disable services that have no LSB init script
Am 29.10.2015 um 22:10 schrieb Martin Pitt: > Hello Luca, > > Luca Bruno [2015-10-29 14:13 +0100]: >>> I tried to reproduce this here: > > Sorry, that was unclear: I tried that on jessie, exact same systemd > version as you have. > >> I can try in some virtual machine I guess. So I fear this is only >> related to jessie at the moment, if it works for you on sid. Fwiw, I can not reproduce the problem. Both on jessie with v215 and on sid with v227. > It should still work in jessie too. If my toy example produces the > same bug for you, then indeed there's something significantly > different in your setup. > > Can you try running > > SYSTEMD_LOG_LEVEL=debug systemctl enable foo.service > > and copy&paste the output here? A strace might be helpful as well. -- 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
Bug#803373: systemd: fail to enable/disable services that have no LSB init script
Hello Luca, Luca Bruno [2015-10-29 14:13 +0100]: > > I tried to reproduce this here: Sorry, that was unclear: I tried that on jessie, exact same systemd version as you have. > I can try in some virtual machine I guess. So I fear this is only > related to jessie at the moment, if it works for you on sid. It should still work in jessie too. If my toy example produces the same bug for you, then indeed there's something significantly different in your setup. Can you try running SYSTEMD_LOG_LEVEL=debug systemctl enable foo.service and copy&paste the output here? Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#803373: systemd: fail to enable/disable services that have no LSB init script
On 29/10/2015 14:05, Martin Pitt wrote: > Control: tag -1 moreinfo unreproducible > > Hello Luca, > > Luca Bruno [2015-10-29 12:29 +0100]: >> I've put a simple service in /lib/systemd/system. Doing systemctl >> start/stop on this service works correctly, however enable/disable >> doesn't work: "Failed to execute operation: No such file or directory". > Did you systemctl daemon-reload after placing the file there? What's > the exact file name you are adding and which command do you run? Does > this involve Alias= or templates? Does your file perhaps refer to a > nonexisting WantedBy= or RequiredBy=? > > I tried to reproduce this here: > > # cat << EOF > /lib/systemd/system/foo.service > [Unit] > Description=test > [Service] > Type=oneshot > ExecStart=/bin/echo hello > [Install] > WantedBy=multi-user.target > EOF > # systemctl daemon-reload > # systemctl enable foo.service > Created symlink from /etc/systemd/system/multi-user.target.wants/foo.service > to /lib/systemd/system/foo.service. > > So all as expected. I'm afraid we need a more detailled reproducer. Thanks for the quick reply. I did exactly your steps and I get the error above. WantedBy only, no Alias. Yes I did daemon-reload of course, start/stop works. > Do you have a chance to try this under testing/unstable? The whole > SysV init script handling got dramatically simplified there. Thanks, > Martin I can try in some virtual machine I guess. So I fear this is only related to jessie at the moment, if it works for you on sid. Best regards,
Bug#803373: systemd: fail to enable/disable services that have no LSB init script
Control: tag -1 moreinfo unreproducible Hello Luca, Luca Bruno [2015-10-29 12:29 +0100]: > I've put a simple service in /lib/systemd/system. Doing systemctl > start/stop on this service works correctly, however enable/disable > doesn't work: "Failed to execute operation: No such file or directory". Did you systemctl daemon-reload after placing the file there? What's the exact file name you are adding and which command do you run? Does this involve Alias= or templates? Does your file perhaps refer to a nonexisting WantedBy= or RequiredBy=? I tried to reproduce this here: # cat << EOF > /lib/systemd/system/foo.service [Unit] Description=test [Service] Type=oneshot ExecStart=/bin/echo hello [Install] WantedBy=multi-user.target EOF # systemctl daemon-reload # systemctl enable foo.service Created symlink from /etc/systemd/system/multi-user.target.wants/foo.service to /lib/systemd/system/foo.service. So all as expected. I'm afraid we need a more detailled reproducer. > The reason is that my systemd service has no LSB init script. That should be fine. We do call update-rc.d *if* there is an LSB init script, but we have plenty of units even in a default install which don't have one (e. g. hwclock-save.service). > By doing a touch /etc/init.d/servicename then enable/disable works, > though update-rc.d will spit out some warning. Interesting. So somehow your new unit thinks there is a SysV init script and tries to call update-rc.d. > I can see this behaviour only on debian, so pretty sure it must caused > by one of the 200+ patches. The vast majority of them are actually ones from 215-stable and cherry-picked ones from newer upstream versions, it's not actually that bad. Do you have a chance to try this under testing/unstable? The whole SysV init script handling got dramatically simplified there. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Bug#803373: systemd: fail to enable/disable services that have no LSB init script
Package: systemd Version: 215-17+deb8u2 Hello, using systemd 215-17+deb8u2 on jessie. I've put a simple service in /lib/systemd/system. Doing systemctl start/stop on this service works correctly, however enable/disable doesn't work: "Failed to execute operation: No such file or directory". The reason is that my systemd service has no LSB init script. By doing a touch /etc/init.d/servicename then enable/disable works, though update-rc.d will spit out some warning. But I DON'T want an LSB init script for my service, only the systemd service. I can see this behaviour only on debian, so pretty sure it must caused by one of the 200+ patches. Is there a way to properly workaround the issue? Is creating an empty LSB script ok or not? Because I don't know the consequences. Best regards,
