Bug#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)
Hi Michael, On Fr, 2015-11-20 at 14:15 +0100, Michael Biebl wrote: > Am 23.10.2015 um 17:43 schrieb Stephan Sürken: > > So yes, for a non-existing script, that's (changed behaviour) but > > correct. > > > > For the example wicd service however, it should ignore the call like > > before, afaiu. > > I think so as well. Could you please raise this issue upstream at > https://github.com/systemd/systemd/issues/new ok, upstream ticket is: https://github.com/systemd/systemd/issues/2015 Hth, S
Bug#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)
Am 23.10.2015 um 17:43 schrieb Stephan Sürken: > So yes, for a non-existing script, that's (changed behaviour) but > correct. > > For the example wicd service however, it should ignore the call like > before, afaiu. I think so as well. Could you please raise this issue upstream at https://github.com/systemd/systemd/issues/new Thanks, Michael -- 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#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)
Hi Martin, On Fr, 2015-10-23 at 17:10 +0200, Martin Pitt wrote: (..) > > 227-2, sid: Fails, retval 6: > > # root? systemctl restart non-existing.service > > Failed to restart non-existing.service: Unit non-existing.service failed > > to load: No such file or directory. > > # root? systemctl restart non-existing.service > > Failed to restart non-existing.service: Unit non-existing.service failed > > to load: No such file or directory. > > That looks right -- systemctl is supposed to fail for a nonexisting > script. I don't even consider that a bug, but a fix. hmm, sorry, seems I did a cut-and-paste error here; the last two lines should have been root@manwe:~# systemctl restart wicd.service Failed to restart wicd.service: Unit wicd.service failed to load: No such file or directory. So yes, for a non-existing script, that's (changed behaviour) but correct. For the example wicd service however, it should ignore the call like before, afaiu. (...) > Starting/stopping services in a schroot has never been defined > behaviour, as in general you can't do that. chroots should have a > policy-rc.d (see /usr/share/doc/sysv-rc/README.policy-rc.d.gz) which > disables service starting/stopping from package maintainer scripts. Ahh, ok. Will have a look at that. > Also, package maintainer scripts certainly shouldn't call invoke-rc.d > on a nonexisting service? Well, the "nonexisting" example should only serve to simply demonstrate that systemd actually _has_ changed behaviour. I am concerned about actual packages failing to install or remove in a plain chroot. Hth! S
Bug#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)
Package: systemd Version: 227-2 Severity: normal Dear Maintainers, with 227-2 (not found in 226-2), systemctl behaves differently in chroots for (at least) services that only provide a sysv init script, breaking package install or removal: 226-2, jessie: Ignored, retval 0: # root? systemctl restart non-existing.service Running in chroot, ignoring request. # root? systemctl restart wicd.service Running in chroot, ignoring request. 227-2, sid: Fails, retval 6: # root? systemctl restart non-existing.service Failed to restart non-existing.service: Unit non-existing.service failed to load: No such file or directory. # root? systemctl restart non-existing.service Failed to restart non-existing.service: Unit non-existing.service failed to load: No such file or directory. As systemctl is also run implicitely via invoke.rc.d on postinst etc., this actually breaks package installation/removal on such systems (one current example is the wicd package). Fwiw, calling systemctl as /sbin/runlevel still works fine: # root? /sbin/runlevel Running in chroot, ignoring request. Hth! S -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages systemd depends on: ii adduser 3.113+nmu3 ii libacl1 2.2.52-2 ii libapparmor12.10-2+b1 ii libaudit1 1:2.4.4-4 ii libblkid1 2.27-3 ii libc6 2.19-22 ii libcap2 1:2.24-12 ii libcap2-bin 1:2.24-12 ii libcryptsetup4 2:1.6.6-5 ii libgcrypt20 1.6.4-3 ii libkmod221-1 ii liblzma55.1.1alpha+20120614-2.1 ii libmount1 2.27-3 ii libpam0g1.1.8-3.1 ii libseccomp2 2.2.3-2 ii libselinux1 2.3-2+b1 ii libsystemd0 227-2 ii mount 2.27-3 ii sysv-rc 2.88dsf-59.2 ii udev227-2 ii util-linux 2.27-3 Versions of packages systemd recommends: ii dbus1.10.0-3 ii libpam-systemd 227-2 Versions of packages systemd suggests: pn systemd-container pn systemd-ui -- no debconf information
Bug#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)
Control: severity -1 important Control: tags -1 confirmed Am 23.10.2015 um 15:32 schrieb Stephan Suerken: > Package: systemd > Version: 227-2 > Severity: normal > > Dear Maintainers, > > with 227-2 (not found in 226-2), systemctl behaves differently > in chroots for (at least) services that only provide a sysv init > script, breaking package install or removal: > > 226-2, jessie: Ignored, retval 0: > # root? systemctl restart non-existing.service > Running in chroot, ignoring request. > # root? systemctl restart wicd.service > Running in chroot, ignoring request. > > 227-2, sid: Fails, retval 6: > # root? systemctl restart non-existing.service > Failed to restart non-existing.service: Unit non-existing.service failed to > load: No such file or directory. > # root? systemctl restart non-existing.service > Failed to restart non-existing.service: Unit non-existing.service failed to > load: No such file or directory. > > As systemctl is also run implicitely via invoke.rc.d on postinst > etc., this actually breaks package installation/removal on such > systems (one current example is the wicd package). > > Fwiw, calling systemctl as /sbin/runlevel still works fine: > > # root? /sbin/runlevel > Running in chroot, ignoring request. I can confirm this behaviour. Bumped the severity to important, but I'm inclined to make it RC. Martin? -- 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#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)
Am 23.10.2015 um 17:10 schrieb Martin Pitt: > Hello Stephan, > > Stephan Suerken [2015-10-23 13:32 +]: >> with 227-2 (not found in 226-2), systemctl behaves differently >> in chroots for (at least) services that only provide a sysv init >> script, breaking package install or removal: > >> 226-2, jessie: Ignored, retval 0: >> # root? systemctl restart non-existing.service >> Running in chroot, ignoring request. >> # root? systemctl restart wicd.service >> Running in chroot, ignoring request. >> >> 227-2, sid: Fails, retval 6: >> # root? systemctl restart non-existing.service >> Failed to restart non-existing.service: Unit non-existing.service failed to >> load: No such file or directory. >> # root? systemctl restart non-existing.service >> Failed to restart non-existing.service: Unit non-existing.service failed to >> load: No such file or directory. > > That looks right -- systemctl is supposed to fail for a nonexisting > script. I don't even consider that a bug, but a fix. Well, but it also fails for real services now: v227 # systemctl status systemd-timesyncd.service Failed to connect to bus: No such file or directory # echo $? 1 v215 (jessie) # systemctl status systemd-timesyncd.service Running in chroot, ignoring request. # echo $? 0 -- 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#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)
Hello Stephan, Stephan Suerken [2015-10-23 13:32 +]: > with 227-2 (not found in 226-2), systemctl behaves differently > in chroots for (at least) services that only provide a sysv init > script, breaking package install or removal: > 226-2, jessie: Ignored, retval 0: > # root? systemctl restart non-existing.service > Running in chroot, ignoring request. > # root? systemctl restart wicd.service > Running in chroot, ignoring request. > > 227-2, sid: Fails, retval 6: > # root? systemctl restart non-existing.service > Failed to restart non-existing.service: Unit non-existing.service failed to > load: No such file or directory. > # root? systemctl restart non-existing.service > Failed to restart non-existing.service: Unit non-existing.service failed to > load: No such file or directory. That looks right -- systemctl is supposed to fail for a nonexisting script. I don't even consider that a bug, but a fix. > As systemctl is also run implicitely via invoke.rc.d on postinst > etc., this actually breaks package installation/removal on such > systems (one current example is the wicd package). Starting/stopping services in a schroot has never been defined behaviour, as in general you can't do that. chroots should have a policy-rc.d (see /usr/share/doc/sysv-rc/README.policy-rc.d.gz) which disables service starting/stopping from package maintainer scripts. mk-sbuild, pbuilder, and related utilities create such a policy-rc.d by default. Also, package maintainer scripts certainly shouldn't call invoke-rc.d on a nonexisting service? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
