[systemd-devel] horrible outout - failed at step NAMESPACE spawning

[Lennart Poettering]

On Mon, 03.07.17 16:28, Reindl Harald (h.reindl at thelounge.net) wrote:

> 
> 
> Am 03.07.2017 um 16:20 schrieb Lennart Poettering:
> > On Mon, 03.07.17 16:12, Reindl Harald (h.reindl at thelounge.net) wrote:
> > 
> > > Am 03.07.2017 um 15:59 schrieb Lennart Poettering:
> > > > On Mon, 03.07.17 15:53, Reindl Harald (h.reindl at thelounge.net) wrote:
> > > > 
> > > > > Jul 3 15:48:01 backup-arrakis systemd: named.service: Failed at step
> > > > > NAMESPACE spawning /usr/libexec/setup-named-chroot.sh: No such file or
> > > > > directory
> > > > > 
> > > > > by all repsect, this output is completly nonsense when the reason is some
> > > > > "InaccessibleDirectories" no longer exists and is not prefixed with a dash
> > > > > because it's not helpful to mention the binary with a "no such file"
> > > > 
> > > > Yes, we can certainly improve the log message in this case, please
> > > > file an RFE bug for that.
> > > > 
> > > > Do note though, that fixing this specific issue is not as trivial as
> > > > it sounds, as the namespacing operations happen very shortly before we
> > > > actually execve() the service binary, at a time where the usual
> > > > logging channels are already gone... Or to say this differently: that
> > > > late in the game the only obvious way to report an error back to PID 1
> > > > is through process exit codes, which you see, and everything else is
> > > > not entirely trivial.
> > > 
> > > but how do you handle the "InaccessibleDirectories=-/non-exists" case which
> > > don't fail the service for *only* that specific line?
> > 
> > Well, if a line is configured to to ignore errors, then we do just
> > that, and proceed, and don't log about it.
> > 
> > I mean, the issue is that logging is hard at that point...
> 
> but if *one* out of many lines is prefixed by a dash you still know which
> one to ignore and not ignore anything which fails and so at that point -
> well - you know what failed

The code that sets up the namespace gets a list of paths to make
innaccessible plus a boolean for each, that tells it whether it shall
propagate ENOENT up or just eat it up immediately, proceeding with the
next item in the list.

Lennart

-- 
Lennart Poettering, Red Hat