Re: [systemd-devel] delayed reply to sd-bus method invocation

[Jason Litzinger]

On Mon, Jul 03, 2017 at 12:31:14PM +, Umut Tezduyar Lindskog wrote:
> Hello Jason,
> 
> Just wanted to remind you that clients set a timeout for the method reply.
> Don't remember off the top of my head but different implementations have
> different default timeouts. Consider this when delaying the reply.
Thanks!  I did run into that today, so this saved me some debugging.
The ultimate client in use is txdbus (I was testing with busctl today), so I'll
see how to change its timeout.

-Jason
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

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

> 
> 
> Am 03.07.2017 um 16:20 schrieb Lennart Poettering:
> > On Mon, 03.07.17 16:12, Reindl Harald (h.rei...@thelounge.net) wrote:
> > 
> > > Am 03.07.2017 um 15:59 schrieb Lennart Poettering:
> > > > On Mon, 03.07.17 15:53, Reindl Harald (h.rei...@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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Mon, 03.07.17 16:12, Reindl Harald (h.rei...@thelounge.net) wrote:

> Am 03.07.2017 um 15:59 schrieb Lennart Poettering:
> > On Mon, 03.07.17 15:53, Reindl Harald (h.rei...@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...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Reindl Harald]

Am 03.07.2017 um 16:20 schrieb Lennart Poettering:

On Mon, 03.07.17 16:12, Reindl Harald (h.rei...@thelounge.net) wrote:


Am 03.07.2017 um 15:59 schrieb Lennart Poettering:

On Mon, 03.07.17 15:53, Reindl Harald (h.rei...@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

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Reindl Harald]

Am 03.07.2017 um 15:59 schrieb Lennart Poettering:

On Mon, 03.07.17 15:53, Reindl Harald (h.rei...@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?

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Mon, 03.07.17 15:53, Reindl Harald (h.rei...@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.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[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"

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] delayed reply to sd-bus method invocation

[Umut Tezduyar Lindskog]

Hello Jason,

Just wanted to remind you that clients set a timeout for the method reply.
Don't remember off the top of my head but different implementations have
different default timeouts. Consider this when delaying the reply.

Umut

On Mon, Jul 3, 2017 at 10:36 AM Lennart Poettering 
wrote:

> On Thu, 29.06.17 21:55, Jason Litzinger (jlitzinger...@gmail.com) wrote:
>
> > > machined has easier-to-follow uses of this, as it does some operations
> > > that might take a bit longer, such as cloning or removing images.
> > Thanks!
> >
> > Since I'll be going through this to come up with something for my
> > own use case, it wouldn't be much to write up a self-contained example.
> > Is there an examples repo/folder/etc where this kind of thing would fit?
>
> Not right now, no. We do have some terse examples in man pages though,
> and maybe we can build on that. But to be included in a man page the
> example needs to be reduced to the minimum, which isn't always easy.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] delayed reply to sd-bus method invocation

[Lennart Poettering]

On Thu, 29.06.17 21:55, Jason Litzinger (jlitzinger...@gmail.com) wrote:

> > machined has easier-to-follow uses of this, as it does some operations
> > that might take a bit longer, such as cloning or removing images.
> Thanks!
> 
> Since I'll be going through this to come up with something for my
> own use case, it wouldn't be much to write up a self-contained example.
> Is there an examples repo/folder/etc where this kind of thing would fit?

Not right now, no. We do have some terse examples in man pages though,
and maybe we can build on that. But to be included in a man page the
example needs to be reduced to the minimum, which isn't always easy.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] 回复： 回复： [systemd-de vel] systemctl can't execute stop actually,whenservice is started by other way

[Lennart Poettering]

On Thu, 29.06.17 11:51, Oliver Neukum (oneu...@suse.com) wrote:

> Am Donnerstag, den 29.06.2017, 11:45 +0200 schrieb Reindl Harald:
> > 
> > Am 29.06.2017 um 10:05 schrieb Oliver Neukum:
> > > 
> > > Am Mittwoch, den 28.06.2017, 13:29 +0200 schrieb Lennart Poettering:
> > > > 
> > > > Well, it's a service manager. As such it keeps track of services,
> > > > knows when they are started and when they aren't. Why would it stop
> > > > services that aren't started?
> > > 
> > > Because you command it to do so.
> > > The check systemd does adds no value. There is a reason to not start
> > > something that is running. The reverse does not apply
> > 
> > this is nonsense - how in the world should systemmd know what to stop 
> > when it has no clue about the involved processes because it did not 
> > start the service and hence has no tracking at all
> 
> So try and fail. That is still no excuse for ruling out that you can
> stop a service you have not started. That is pure politics.

Note that stopping services is more than just invoking an ExecStop=
script, as systemd will kill everything remaining after that, and
waits for all processes being gone before considering the service
properly down. All that falls apart if systemd never tracked the
service, as we neither know what to kill nor what to wait for.

In fact, a major chunk of services don't even have ExecStop= anymore,
as it is mostly redundant with this scheme, as just sending SIGTERM covers
80% of how common system services are shut down.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel