[systemd-devel] Troubleshooting Failed Nspawn Starts

[Lennart Poettering]

On Fri, 14.08.15 14:23, Rich Freeman (r-systemd at thefreemanclan.net) wrote:

> On Fri, Aug 14, 2015 at 1:30 PM, Lennart Poettering
> <mzerqung at 0pointer.de> wrote:
> > On Mon, 10.08.15 08:03, Rich Freeman (r-systemd at thefreemanclan.net) wrote:
> >
> > We have watchdog (see WatchdogSec= documentation in
> > systemd.service(5)) support in all our long-running daemons, and PID 1
> > will kill the service and generate a backtrace for them if they don't
> > send a watchdog message often enough. So actually we should be pretty
> > good here...
> 
> Thanks.  In this case I'm not sure if it is needed more for nspawn
> itself, or for systemd (which probably won't work unless nspawn
> supports watchdog), or for journald/etc.

journald supports the sd_notify() watchdog logic.

systemd itself currently does not. Adding this would make a lot of
sense, both for the case where "systemd --user" is run, and where
systemd is invoked by nspawn. 

nspawn doesn't support this either. It cannot send out watchdog
keep-alive messages to its invoking program, nor can it receive
watchdog keep-alive messages from the init system. Adding both would
make sense.

Could you file a github RFE issue, asking for support for watchdog
keep-alive message send stuff in PID 1 and nspawn, and watchdog
keep-alive message receive stuff in nspawn? I think it would make a
lot of sense to add this!

> > journalctl --flush actually pretty much only sends SIGUSR1 to
> > journald, but does this through PID1's bus APIs... It then waits for a
> > file in /run/systemd/journal/flushed to appear... For some reason that
> > doesn't work here... Weird...
> 
> I'm actually wondering if it is some kind of dbus api issue.  I don't
> have anything in this email but I seem to recall seeing some error in
> a situation like this that mentioned dbus.

Could be. The kill request is done via PID1's bus APIs after all...

Lennart

-- 
Lennart Poettering, Red Hat