Re: [systemd-devel] Should long-running child processes clear INVOCATION_ID?
On Fr, 02.03.18 15:16, Simon McVittie (s...@collabora.com) wrote: > When dbus-daemon carries out a mixture of systemd and traditional > (non-systemd) activation, we get a process tree like this: > > systemd --user (init.scope) > |- dbus-daemon --session (dbus.service) > | |- (babysitter process) > | | \- gnome-shell-calendar-server [t] > | \- (babysitter process) > | \- dleyna-renderer-service [t] > |- gnome-terminal-server (g-t-s.service) [s] > \- xdg-document-portal (x-d-p.service) [s] > > [s]: systemd activation; [t]: traditional activation > > or the equivalent for the system bus. > > As of current git master, the dbus-daemon removes some of its environment > variables from the environment passed to traditional D-Bus services > like gnome-shell-calendar-server, because they are applicable to to the > dbus-daemon but not the child. In particular JOURNAL_STREAM, LISTEN_* > and NOTIFY_SOCKET get this treatment. > > However, it wasn't clear to me what this code should do with the > INVOCATION_ID. Would it be better (less misleading) to say that > gnome-shell-calendar-server is part of the same INVOCATION_ID as its > dbus-daemon parent, or to say that it has no invocation ID? So the idea was that INVOCATION_ID would be specific to each invoked "instance" of a service, regardless of how many individual processes it is put together. If dbus-daemon acts as its own "super-server" for some daemons it probably woule be smart to unset that env var for the service children it spawns, since in that case the concept doesn't really apply that much anymore. I figure crond is similar. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Should long-running child processes clear INVOCATION_ID?
When dbus-daemon carries out a mixture of systemd and traditional (non-systemd) activation, we get a process tree like this: systemd --user (init.scope) |- dbus-daemon --session (dbus.service) | |- (babysitter process) | | \- gnome-shell-calendar-server [t] | \- (babysitter process) | \- dleyna-renderer-service [t] |- gnome-terminal-server (g-t-s.service) [s] \- xdg-document-portal (x-d-p.service) [s] [s]: systemd activation; [t]: traditional activation or the equivalent for the system bus. As of current git master, the dbus-daemon removes some of its environment variables from the environment passed to traditional D-Bus services like gnome-shell-calendar-server, because they are applicable to to the dbus-daemon but not the child. In particular JOURNAL_STREAM, LISTEN_* and NOTIFY_SOCKET get this treatment. However, it wasn't clear to me what this code should do with the INVOCATION_ID. Would it be better (less misleading) to say that gnome-shell-calendar-server is part of the same INVOCATION_ID as its dbus-daemon parent, or to say that it has no invocation ID? Thanks, smcv ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: enable suspend to idle
On Do, 01.03.18 16:13, Thomas Blume (thomas.bl...@suse.com) wrote: > On Thu, 1 Mar 2018, Lennart Poettering wrote: > > > > The kernel must not set policy on what is a source of wake ups. Setting > > > this up so that we do not get a regression in functionality compared > > > to old style S3 (whose policy is in firmware) falls to user space, > > > more specifically udev. > > > > And where would udev have that information from? I mean, if it turns > > this on for all devices, then why can't the kernel do that on its own? > > We don't want all devices for which the kernel is supporting wake on idle, to > act as wakeup device. But for which ones would you want that? > Ideally this will be a config option with reasonable defaults. But why wouldn't that be a kernel option? I mean, so far the goal was to encode "reasonable defaults" in the kernel itself, so that userspace is only used when those "reasonable defaults" do not apply onto one local case. Really, already for compatibility reasons the kernel should just carry the "reasonable defaults", so that it's not necessary to match it up with a udev version that carries the right policy for it. 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] Why did you set MountFlags=slave in systemd-udevd.service.in
On Fr, 02.03.18 10:22, Hongzhi, Song (hongzhi.s...@windriver.com) wrote: > On 2018年03月01日 17:50, Lennart Poettering wrote: > > On Do, 01.03.18 14:44, Hongzhi, Song (hongzhi.s...@windriver.com) wrote: > > > > > Thank you very much. It dose work. > > > > > > Would you tell me that how the '--no-block' works, > > "systemd-mount" talks to systemd (i.e. PID 1) to issue mount/automount > > operations. By default it will do so synchronously, thus blocking > > until the mount is established. If you specify "--no-block" then you > > turn off this synchronous behaviour, and instead request asynchronous > > behaviour, where the rule will just request the operation to be > > executed, but won't wait for it to finish. When you invoke > > "systemd-mount" from a udev rule then using "--no-block" is a > > necessity to avoid a deadlock. That's because PID 1 won't operate on a > > device to mount before udev reported it to be fully availabled and > > probed. > Do you mean that udev doesn't report device to be fully availabled > and probed until systemd-mount returns? Yes. All programs configured in udev rules files need to finish before udev reports the device to its clients to be fullyprobed and ready. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
