Your message dated Tue, 14 Nov 2017 08:16:29 +0000
with message-id <[email protected]>
and subject line Re: Bug#881697: dpkg: start-stop-daemon uses systemctl, which
fails in a chroot
has caused the Debian Bug report #881697,
regarding dpkg: start-stop-daemon uses systemctl, which fails in a chroot
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
881697: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881697
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg
Version: 1.18.24
Severity: normal
Due to some external factors I'm using a Debian chroot in a Linux
appliance, to have more modern versions of the services available.
Sadly there's a regression -- the init scripts use "start-stop-daemon",
which calls "systemctl", but that rejects the request with
# /etc/init.d/cups status
Running in chroot, ignoring request.
Same for "start", of course.
I'm not entirely sure whether the bug should be filed against systemctl,
though - this one is actually rejecting the request.
OTOH, start-stop-daemon (or perhaps better the init script?) might detect
that it's running in a chroot, and then avoid using systemctl, but start
the requested service via fork() directly -- that's my preferred solution.
Basically, I believe that using a Debian chroot to provide services is
a legitimate use-case -- but it doesn't work right now.
What's the best place to fix that?
Thank you very much!
--- End Message ---
--- Begin Message ---
Sorry, please disregard.
I found out that the bind mount of /run (that I did to provide dbus
services in the chroot) also provided /run/systemd/system, and the
existence of that broke chroot detection.
Mounting an empty tmpfs on /run/systemd/ in the chroot fixed the
problem.
--- End Message ---
