Re: [systemd-devel] systemd tries to terminate a process that seems to have exited
On 05.05.2022 04:41, Yuri Kanivetsky wrote: > Hi, > > This might be not a systemd issue. But the behavior is weird, and I'm not > sure. > > I'm trying to run GNOME in a docker container. And gnome-keyring fails to > start: > > https://gist.github.com/x-yuri/c3c715ea6355633de4546ae957a66410 > > I added debug statements, and in the log I see: > > May 02 05:09:02 ab6aaba04124 systemd[109]: Starting Start > gnome-keyring for the Secrets Service, and PKCS #11... > May 02 05:09:02 ab6aaba04124 gnome-keyring-d[309]: -- main: 1046 > May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]: > gnome-keyring-daemon: no process capabilities, insecure memory might > get used > May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]: -- > fork_and_print_environment: fork(), parent, 653 > May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[321]: -- > fork_and_print_environment: fork(), child, 684 > May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[321]: couldn't > access control socket: /run/user/1000/keyring/control: No such file or > directory > May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]: -- > fork_and_print_environment: exit(0), 680 > May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[321]: -- main: > return 0, 1210 > May 02 05:10:32 ab6aaba04124 systemd[109]: gnome-keyring.service: > State 'stop-sigterm' timed out. Killing. > May 02 05:10:32 ab6aaba04124 systemd[109]: gnome-keyring.service: > Failed with result 'timeout'. > May 02 05:10:32 ab6aaba04124 systemd[109]: Failed to start Start > gnome-keyring for the Secrets Service, and PKCS #11. > ... > > I can only reproduce it on Debian 8. Which kind of makes it > unimportant. But the behavior is so weird (either gnome-keyring is > blocked in/after exit(), or systemd tries to kill a process that > exited), that I can't help but think about what is really going on > there. > So run systemd user instance with debug level logging to see which process are still left.
[systemd-devel] systemd tries to terminate a process that seems to have exited
Hi, This might be not a systemd issue. But the behavior is weird, and I'm not sure. I'm trying to run GNOME in a docker container. And gnome-keyring fails to start: https://gist.github.com/x-yuri/c3c715ea6355633de4546ae957a66410 I added debug statements, and in the log I see: May 02 05:09:02 ab6aaba04124 systemd[109]: Starting Start gnome-keyring for the Secrets Service, and PKCS #11... May 02 05:09:02 ab6aaba04124 gnome-keyring-d[309]: -- main: 1046 May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]: gnome-keyring-daemon: no process capabilities, insecure memory might get used May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]: -- fork_and_print_environment: fork(), parent, 653 May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[321]: -- fork_and_print_environment: fork(), child, 684 May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[321]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]: -- fork_and_print_environment: exit(0), 680 May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[321]: -- main: return 0, 1210 May 02 05:10:32 ab6aaba04124 systemd[109]: gnome-keyring.service: State 'stop-sigterm' timed out. Killing. May 02 05:10:32 ab6aaba04124 systemd[109]: gnome-keyring.service: Failed with result 'timeout'. May 02 05:10:32 ab6aaba04124 systemd[109]: Failed to start Start gnome-keyring for the Secrets Service, and PKCS #11. A longer version (w/ lines about a service activation): May 02 05:09:02 ab6aaba04124 systemd[109]: Starting Start gnome-keyring for the Secrets Service, and PKCS #11... May 02 05:09:02 ab6aaba04124 gnome-keyring-d[309]: -- main: 1046 May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]: gnome-keyring-daemon: no process capabilities, insecure memory might get used May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]: -- fork_and_print_environment: fork(), parent, 653 May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[321]: -- fork_and_print_environment: fork(), child, 684 May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[321]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]: -- fork_and_print_environment: exit(0), 680 May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[321]: -- main: return 0, 1210 May 02 05:09:02 ab6aaba04124 dbus-daemon[124]: [session uid=1000 pid=124] Activating service name='org.freedesktop.secrets' requested by ':1.19' (uid=1000 pid=251 comm="/usr/libexec/xdg-desktop-portal ") May 02 05:09:02 ab6aaba04124 gnome-keyring-d[347]: -- main: 1046 May 02 05:09:02 ab6aaba04124 org.freedesktop.secrets[347]: gnome-keyring-daemon: no process capabilities, insecure memory might get used May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[347]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory May 02 05:09:02 ab6aaba04124 dbus-daemon[124]: [session uid=1000 pid=124] Successfully activated service 'org.freedesktop.secrets' May 02 05:10:32 ab6aaba04124 systemd[109]: gnome-keyring.service: State 'stop-sigterm' timed out. Killing. May 02 05:10:32 ab6aaba04124 systemd[109]: gnome-keyring.service: Failed with result 'timeout'. May 02 05:10:32 ab6aaba04124 systemd[109]: Failed to start Start gnome-keyring for the Secrets Service, and PKCS #11. And even longer version (with duplicate and intervening lines): May 02 05:09:02 ab6aaba04124 systemd[109]: Starting Start gnome-keyring for the Secrets Service, and PKCS #11... May 02 05:09:02 ab6aaba04124 systemd[109]: Starting GNOME Remote Desktop... May 02 05:09:02 ab6aaba04124 systemd[109]: Starting Monitor Session leader for GNOME Session... May 02 05:09:02 ab6aaba04124 systemd[109]: Starting Session Migration... May 02 05:09:02 ab6aaba04124 systemd[109]: Starting Rewrite dynamic launcher portal entries... May 02 05:09:02 ab6aaba04124 systemd[109]: Finished Start gnome-keyring as SSH agent. May 02 05:09:02 ab6aaba04124 systemd[109]: Started OpenSSH Agent. May 02 05:09:02 ab6aaba04124 systemd[109]: Started Monitor Session leader for GNOME Session. May 02 05:09:02 ab6aaba04124 gnome-keyring-d[309]: -- main: 1046 May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]: gnome-keyring-daemon: no process capabilities, insecure memory might get used May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[309]: -- fork_and_print_environment: fork(), parent, 653 May 02 05:09:02 ab6aaba04124 gnome-keyring-d[309]: -- fork_and_print_environment: fork(), parent, 653 May 02 05:09:02 ab6aaba04124 systemd[109]: Finished Rewrite dynamic launcher portal entries. May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[321]: -- fork_and_print_environment: fork(), child, 684 May 02 05:09:02 ab6aaba04124 gnome-keyring-daemon[321]: couldn't access control socket:
Re: [systemd-devel] Relationship between cgroup hierarchy and slice names
On Di, 03.05.22 20:16, Yeongjin Kwon (yeongjink...@gmail.com) wrote: > Hi, > > I'm trying to override the parent slice of a certain slice unit so I can > reorganize the cgroup hierarchy. I looked into overriding the "Slice" > property to set the containing slice of the unit, but it seems that > property does not do anything for slices because the location in the cgroup > hierarchy and parent are already set by the unit name. The documentation > says the unit name is composed of a series of words separated by dashes, > where each word represents a directory in the cgroup hierarchy. If the unit > name was independent from the location of the slice in the cgroup > hierarchy, then I would imagine that would make overriding the parent slice > possible. I tried to find the reason why the slice unit name must strictly > match the cgroup hierarchy, but I could not come up with an answer after > searching online and thinking about it myself. > One possibility for why the slice name must match the hierarchy could be > naming conflicts. If there are two slices with the same name but in > different cgroups, they could conflict with each other. But I decided this > could not be the case, since developers could just avoid the conflicts by > using the slice naming convention as a convention instead of following it > as a hard rule. Furthermore, there are several unit types like scopes and > services which can be organized in the cgroup hierarchy like slices, but > don't follow the same naming rule. If it was decided that naming conflicts > in relation to the cgroup hierarchy would not pose a problem for these > other units, then why was it decided for slices? Slices are the categorization, and the other unit types are what you put inside these categories. If we'd allow putting slices into random other slides without this being reflected in the name, then first of all you could create loops. (i.e. put foo.slice inside bar.slice and that back into foo.slice), and it would pretty much defeat the point of the logic, as they would suddenly not be purely categories anymore but stuff that can be put in categories. > Is there another way to override the location of a slice in the cgroup > hierarchy? And what is the reason why slice names have to correspond with > their location in the cgroup hierarchy? The slice names match 1:1 to the position in the cgroup tree, that's where they were designed. We enforce similar rules on naming things btw for .mount, .automount .swap and .device units: the are also named after paths in the file system. Basically our rule is: if the object unit types encapsulates already have a file system path as name then we don't allow you to make up a new name, but insist that the unit name is derived from that pre-existing file system path. Lennart -- Lennart Poettering, Berlin
