Discussion:
horrible outout - failed at step NAMESPACE spawning
Add Reply
Reindl Harald
2017-07-03 13:53:52 UTC
Reply
Permalink
Raw Message
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"
Lennart Poettering
2017-07-03 13:59:03 UTC
Reply
Permalink
Raw Message
Post by Reindl Harald
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.

Lennart
--
Lennart Poettering, Red Hat
Reindl Harald
2017-07-03 14:12:45 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
Post by Reindl Harald
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?
Lennart Poettering
2017-07-03 14:20:56 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
Post by Reindl Harald
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...

Lennart
--
Lennart Poettering, Red Hat
Reindl Harald
2017-07-03 14:28:31 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
Post by Lennart Poettering
Post by Reindl Harald
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
Lennart Poettering
2017-07-03 14:43:17 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
Post by Lennart Poettering
Post by Reindl Harald
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
Loading...