Re: [systemd-devel] Failed to determine supported controllers: No such process
On 21.1.2020 18.11, Lennart Poettering wrote: On Di, 21.01.20 17:02, Reindl Harald (h.rei...@thelounge.net) wrote: i was already considering "hidepid" as the root cause systemd-243.5-1.fc31.x86_64 other than systemd-241-12.git323cdf4.fc30.x86_64 can no longer deal with hidepid= is broken. We don't support that, sorry. Various components can't deal with it. We'd like to support this, but the way it is defined now cannot work for general purpose OS. There was work on fixing it in the kernel: https://lwn.net/Articles/738597/ That patch set got discussed, then forgotten, picked up again and forgotten. it's a neverending story. If it eventualls gets merged we can happily support it in systemd. Alexey Gladkov submitted v6 of the patch series recently: https://lkml.org/lkml/2019/12/25/102 -Topi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to determine supported controllers: No such process
Am 21.01.20 um 18:39 schrieb Lennart Poettering: > On Di, 21.01.20 17:51, Reindl Harald (h.rei...@thelounge.net) wrote: > Either way, check if hidepid=0 makes things work for you >>> well, it's not that easy because after change it from 2 to 1 the newly >>> upgraed VM is *toast* meaing no network and even TTY login times out >>> >>> well, after hunt some food i will try to mount the system vdisk on a >>> differnt guest and comment out that block :-( >> >> yeah, set it to 0 works around broken systemd in F31 while 1 makes the >> system completly unuseable >> >> when something works for years and stops to by update a single component >> you should refrain from call everything else broken, it's fire for the >> systemd-haters everywhere > > This has been discussed so many times. > > Like here: > > https://github.com/systemd/systemd/issues/1 > > or here: > > https://github.com/systemd/systemd/issues/12955 > > or here: > > https://github.com/systemd/systemd/issues/11300#issuecomment-450857717 > > or here: > > https://github.com/systemd/systemd/issues/2941#issuecomment-211542313 > > I mean, I am sorry you didn't get the message about it, but this has > been discussed plenty times. It always was broken at various places, > and it continues to be. Maybe you didn't run into it, but it's nothing > we can support. https://github.com/systemd/systemd/issues/2941#issuecomment-211542313 perfect example # allow group 'proc_allow=4502' additionally to root [root@testserver:~]$ cat /etc/systemd/system/systemd-logind.service.d/hidepid.conf [Service] SupplementaryGroups=4502 [root@testserver:~]$ ls /etc/systemd/system/systemd-logind.service.d/hidepid.conf -rw-r--r-- 1 root root 35 2018-07-26 18:53 /etc/systemd/system/systemd-logind.service.d/hidepid.conf i am not that dumb as you may think but taht is no excuse the extend the problems and the to be frankly dumb "user manager" stuff introduces more problems than it ever solved it's not cool at reboot to have that crap hanging around and blocking shutdown when it's lingered to reduce the log garbage there is no sane reasosn that user X has any information of process Y from a differnt user until it's root and anything expecting that to be true is broken by design when we are at it: prefix the crap here with something unique so i can get rid of it from rsyslog as millions of other stuff nobody but upstream developers cares Jan 21 18:59:03 testserver systemd[1]: session-3.scope: Consumed 1h 15min 23.941s CPU time. don't get me wrong: i love systemd and it's capabilities for a lot of reasons but bullshit like that tempers me to understand the dumb haters ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to determine supported controllers: No such process
On Di, 21.01.20 17:51, Reindl Harald (h.rei...@thelounge.net) wrote: > >> Either way, check if hidepid=0 makes things work for you > > well, it's not that easy because after change it from 2 to 1 the newly > > upgraed VM is *toast* meaing no network and even TTY login times out > > > > well, after hunt some food i will try to mount the system vdisk on a > > differnt guest and comment out that block :-( > > yeah, set it to 0 works around broken systemd in F31 while 1 makes the > system completly unuseable > > when something works for years and stops to by update a single component > you should refrain from call everything else broken, it's fire for the > systemd-haters everywhere This has been discussed so many times. Like here: https://github.com/systemd/systemd/issues/1 or here: https://github.com/systemd/systemd/issues/12955 or here: https://github.com/systemd/systemd/issues/11300#issuecomment-450857717 or here: https://github.com/systemd/systemd/issues/2941#issuecomment-211542313 I mean, I am sorry you didn't get the message about it, but this has been discussed plenty times. It always was broken at various places, and it continues to be. Maybe you didn't run into it, but it's nothing we can support. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to determine supported controllers: No such process
Am 21.01.20 um 17:19 schrieb Reindl Harald: > > > Am 21.01.20 um 17:17 schrieb Lennart Poettering: >> On Di, 21.01.20 17:14, Reindl Harald (h.rei...@thelounge.net) wrote: >> > i was already considering "hidepid" as the root cause > systemd-243.5-1.fc31.x86_64 other than > systemd-241-12.git323cdf4.fc30.x86_64 can no longer deal with hidepid= is broken. We don't support that, sorry. Various components can't deal with it. We'd like to support this, but the way it is defined now cannot work for general purpose OS. There was work on fixing it in the kernel: https://lwn.net/Articles/738597/ That patch set got discussed, then forgotten, picked up again and forgotten. it's a neverending story. If it eventualls gets merged we can happily support it in systemd. >>> >>> don't get me wrong but after *years* using it on each and every machine >>> from Fedora desktops over Feodra servers as well as with CentOS6/7 you >>> can't come up with that when systemd got updated in F31 and point >>> somewhere else >> >> Well, maybe you didn't notice how broken it is, but I know it's >> broken. >> >> Either way, check if hidepid=0 makes things work for you > well, it's not that easy because after change it from 2 to 1 the newly > upgraed VM is *toast* meaing no network and even TTY login times out > > well, after hunt some food i will try to mount the system vdisk on a > differnt guest and comment out that block :-( yeah, set it to 0 works around broken systemd in F31 while 1 makes the system completly unuseable when something works for years and stops to by update a single component you should refrain from call everything else broken, it's fire for the systemd-haters everywhere ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DynamicUser in instantiated (and socket-activated) units
On Tue, Jan 21, 2020 at 05:08:14PM +0100, Lennart Poettering wrote: > if you speciy the same user name its going to have the same uid. > > use something like this: > > ... > [Service] > ... > User=foo-%i > DynamicUser=1 > ... > > That way you have a separate user for each instance, and the user is > called "foo-" suffixed with the instance ID. And each UID is > dynamically assigned. Great, it works, thanks! I see, so without a User= line, username is the same as the unit name (before @)... apparently I didn't read systemd.exec manpage carefully enough. Sincerely, L. -- Leonid Isaev ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to determine supported controllers: No such process
Am 21.01.20 um 17:17 schrieb Lennart Poettering: > On Di, 21.01.20 17:14, Reindl Harald (h.rei...@thelounge.net) wrote: > i was already considering "hidepid" as the root cause systemd-243.5-1.fc31.x86_64 other than systemd-241-12.git323cdf4.fc30.x86_64 can no longer deal with >>> >>> hidepid= is broken. We don't support that, sorry. Various components >>> can't deal with it. >>> >>> We'd like to support this, but the way it is defined now cannot work >>> for general purpose OS. >>> >>> There was work on fixing it in the kernel: >>> >>> https://lwn.net/Articles/738597/ >>> >>> That patch set got discussed, then forgotten, picked up again and >>> forgotten. it's a neverending story. If it eventualls gets merged we >>> can happily support it in systemd. >> >> don't get me wrong but after *years* using it on each and every machine >> from Fedora desktops over Feodra servers as well as with CentOS6/7 you >> can't come up with that when systemd got updated in F31 and point >> somewhere else > > Well, maybe you didn't notice how broken it is, but I know it's > broken. > > Either way, check if hidepid=0 makes things work for you well, it's not that easy because after change it from 2 to 1 the newly upgraed VM is *toast* meaing no network and even TTY login times out well, after hunt some food i will try to mount the system vdisk on a differnt guest and comment out that block :-( ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to determine supported controllers: No such process
On Di, 21.01.20 17:14, Reindl Harald (h.rei...@thelounge.net) wrote: > >> i was already considering "hidepid" as the root cause > >> systemd-243.5-1.fc31.x86_64 other than > >> systemd-241-12.git323cdf4.fc30.x86_64 can no longer deal with > > > > hidepid= is broken. We don't support that, sorry. Various components > > can't deal with it. > > > > We'd like to support this, but the way it is defined now cannot work > > for general purpose OS. > > > > There was work on fixing it in the kernel: > > > > https://lwn.net/Articles/738597/ > > > > That patch set got discussed, then forgotten, picked up again and > > forgotten. it's a neverending story. If it eventualls gets merged we > > can happily support it in systemd. > > don't get me wrong but after *years* using it on each and every machine > from Fedora desktops over Feodra servers as well as with CentOS6/7 you > can't come up with that when systemd got updated in F31 and point > somewhere else Well, maybe you didn't notice how broken it is, but I know it's broken. Either way, check if hidepid=0 makes things work for you. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to determine supported controllers: No such process
Am 21.01.20 um 17:11 schrieb Lennart Poettering: > On Di, 21.01.20 17:02, Reindl Harald (h.rei...@thelounge.net) wrote: > >> i was already considering "hidepid" as the root cause >> systemd-243.5-1.fc31.x86_64 other than >> systemd-241-12.git323cdf4.fc30.x86_64 can no longer deal with > > hidepid= is broken. We don't support that, sorry. Various components > can't deal with it. > > We'd like to support this, but the way it is defined now cannot work > for general purpose OS. > > There was work on fixing it in the kernel: > > https://lwn.net/Articles/738597/ > > That patch set got discussed, then forgotten, picked up again and > forgotten. it's a neverending story. If it eventualls gets merged we > can happily support it in systemd. don't get me wrong but after *years* using it on each and every machine from Fedora desktops over Feodra servers as well as with CentOS6/7 you can't come up with that when systemd got updated in F31 and point somewhere else ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] DynamicUser in instantiated (and socket-activated) units
Hi, I am trying to sandbox processes that run via instantiated units and the DynamicUser feature seems like a nice solution. However, when I start several such units simultaneously, the dynamic UID, while random, is the same for all instances (see below). Is this expected behavior and is there any way to make UID different for each instance? For example: -8<- [root@hyena ~]# systemctl cat sleep@.service # /etc/systemd/system/sleep@.service [Unit] Description=A test unit After=network.target [Service] Type=simple DynamicUser=yes ExecStart=/usr/bin/sleep 180 [root@hyena ~]# systemctl start sleep@1.service [root@hyena ~]# systemctl start sleep@2.service [root@hyena ~]# ps auxwwn ... 65086 154271 0.0 0.0 5292 704 ?Ss 15:45 0:00 /usr/bin/sleep 180 65086 154274 0.0 0.0 5292 704 ?Ss 15:45 0:00 /usr/bin/sleep 180 ^ [root@hyena ~]# journalctl | tail ... Jan 21 15:45:53 hyena systemd[1]: Started A test unit. Jan 21 15:45:55 hyena systemd[1]: Started A test unit. ->8- Same applies to socket-activated services whose .socket unit has Accept=true. For example: -8<- [root@hyena ~]# systemctl cat convert.socket # /etc/systemd/system/convert.socket [Unit] Description=Convert Socket Conflicts=convert.service [Socket] ListenStream=15000 Accept=true [Install] WantedBy=sockets.target [root@hyena ~]# systemctl cat convert@.service # /etc/systemd/system/convert@.service [Unit] Description=A conversion program After=network.target [Service] Type=simple DynamicUser=yes StandardInput=socket ExecStart=/etc/systemd/scripts/convert.sh ->8- Thanks in advance, L. -- Leonid Isaev ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to determine supported controllers: No such process
On Di, 21.01.20 17:02, Reindl Harald (h.rei...@thelounge.net) wrote: > i was already considering "hidepid" as the root cause > systemd-243.5-1.fc31.x86_64 other than > systemd-241-12.git323cdf4.fc30.x86_64 can no longer deal with hidepid= is broken. We don't support that, sorry. Various components can't deal with it. We'd like to support this, but the way it is defined now cannot work for general purpose OS. There was work on fixing it in the kernel: https://lwn.net/Articles/738597/ That patch set got discussed, then forgotten, picked up again and forgotten. it's a neverending story. If it eventualls gets merged we can happily support it in systemd. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DynamicUser in instantiated (and socket-activated) units
On Di, 21.01.20 16:02, Leonid Isaev (leonid.is...@ifax.com) wrote: > On Tue, Jan 21, 2020 at 03:53:10PM +, Leonid Isaev wrote: > > I am trying to sandbox processes that run via instantiated units and > > the DynamicUser feature seems like a nice solution. However, when I start > > several such units simultaneously, the dynamic UID, while random, is the > > same > > for all instances (see below). Is this expected behavior and is there any > > way > > to make UID different for each instance? > > Sorry, forgot to mention, it is systemd 244 on Arch Linux. if you speciy the same user name its going to have the same uid. use something like this: … [Service] … User=foo-%i DynamicUser=1 … That way you have a separate user for each instance, and the user is called "foo-" suffixed with the instance ID. And each UID is dynamically assigned. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to determine supported controllers: No such process
Am 21.01.20 um 16:58 schrieb Lennart Poettering: > On Di, 21.01.20 16:17, Reindl Harald (h.rei...@thelounge.net) wrote: > >> >> >> Am 21.01.20 um 16:13 schrieb Lennart Poettering: >>> On Di, 21.01.20 15:55, Reindl Harald (h.rei...@thelounge.net) wrote: >>> Hi about to upgrade prepare Fedora 31 upgrades -- Jan 21 15:30:01 testserver systemd[17664]: Failed to determine supported controllers: No such process Jan 21 15:30:01 testserver systemd[17664]: Failed to allocate manager object: No such process Jan 21 15:30:01 testserver systemd[1]: user@48.service: Failed with result 'protocol'. Jan 21 15:30:01 testserver systemd[1]: Failed to start User Manager for UID 48. >>> >>> How does user "user@48.service" and its drop-ins look like? >> >> as shipped as part of systemd which is the one starting full sessions >> just because of a cronjob > > Hmm, so for some reason the per-user instance of systemd cannot figure > out which cgroup cntrollers are available in its subtree. Something is > strange there. > > Do you have any non-standard mounts in the host mount namespace? how > does /etc/fstab look like for you? i was already considering "hidepid" as the root cause systemd-243.5-1.fc31.x86_64 other than systemd-241-12.git323cdf4.fc30.x86_64 can no longer deal with there are runnign a ton of batched compile jobs at the moment, i will play around with value 1 and 0 at that place and give feedback later if that's the case the non-privilged task has to be fixed in a way that it has no busienss to look into other processes and receive whatever information it needs from dbus or so # https://linux-audit.com/linux-system-hardening-adding-hidepid-to-proc/ # allow group 'proc_allow=4502' additionally to root proc /proc procrw,nosuid,nodev,noexec,relatime,hidepid=2,gid=4502 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DynamicUser in instantiated (and socket-activated) units
On Tue, Jan 21, 2020 at 03:53:10PM +, Leonid Isaev wrote: > I am trying to sandbox processes that run via instantiated units and > the DynamicUser feature seems like a nice solution. However, when I start > several such units simultaneously, the dynamic UID, while random, is the same > for all instances (see below). Is this expected behavior and is there any way > to make UID different for each instance? Sorry, forgot to mention, it is systemd 244 on Arch Linux. Thanks, L. -- Leonid Isaev ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to determine supported controllers: No such process
On Di, 21.01.20 16:17, Reindl Harald (h.rei...@thelounge.net) wrote: > > > Am 21.01.20 um 16:13 schrieb Lennart Poettering: > > On Di, 21.01.20 15:55, Reindl Harald (h.rei...@thelounge.net) wrote: > > > >> Hi > >> > >> about to upgrade prepare Fedora 31 upgrades > >> > >> -- > >> > >> Jan 21 15:30:01 testserver systemd[17664]: Failed to determine supported > >> controllers: No such process > >> Jan 21 15:30:01 testserver systemd[17664]: Failed to allocate manager > >> object: No such process > >> Jan 21 15:30:01 testserver systemd[1]: user@48.service: Failed with > >> result 'protocol'. > >> Jan 21 15:30:01 testserver systemd[1]: Failed to start User Manager for > >> UID 48. > > > > How does user "user@48.service" and its drop-ins look like? > > as shipped as part of systemd which is the one starting full sessions > just because of a cronjob Hmm, so for some reason the per-user instance of systemd cannot figure out which cgroup cntrollers are available in its subtree. Something is strange there. Do you have any non-standard mounts in the host mount namespace? how does /etc/fstab look like for you? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to determine supported controllers: No such process
Am 21.01.20 um 16:17 schrieb Reindl Harald: > > > Am 21.01.20 um 16:13 schrieb Lennart Poettering: >> On Di, 21.01.20 15:55, Reindl Harald (h.rei...@thelounge.net) wrote: >> >>> Hi >>> >>> about to upgrade prepare Fedora 31 upgrades >>> >>> -- >>> >>> Jan 21 15:30:01 testserver systemd[17664]: Failed to determine supported >>> controllers: No such process >>> Jan 21 15:30:01 testserver systemd[17664]: Failed to allocate manager >>> object: No such process >>> Jan 21 15:30:01 testserver systemd[1]: user@48.service: Failed with >>> result 'protocol'. >>> Jan 21 15:30:01 testserver systemd[1]: Failed to start User Manager for >>> UID 48. >> >> How does user "user@48.service" and its drop-ins look like? > > as shipped as part of systemd which is the one starting full sessions > just because of a cronjob and it happens with every session 5000 was the ssh login of my builduser luckily nothing cares about the failing usermanager service - the godd question is if that applies to graphical sessions too or upgrade to F31 would kill X11/KDE at the moment - [root@testserver:~]$ systemctl list-units | grep 5000 run-user-5000.mount loaded active mounted /run/user/5000 user-runtime-dir@5000.service loaded active exitedUser Runtime Directory /run/user/5000 ● user@5000.service loaded failed failedUser Manager for UID 5000 user-5000.slice loaded active activeUser Slice of UID 5000 - [root@testserver:~]$ systemctl status user@5000.service ● user@5000.service - User Manager for UID 5000 Loaded: loaded (/usr/lib/systemd/system/user@.service; static; vendor preset: disabled) Active: failed (Result: protocol) since Tue 2020-01-21 16:19:28 CET; 4min 33s ago Docs: man:user@.service(5) Process: 1268 ExecStart=/usr/lib/systemd/systemd --user (code=exited, status=1/FAILURE) Main PID: 1268 (code=exited, status=1/FAILURE) CPU: 22ms Jan 21 16:19:28 testserver.rhsoft.net systemd[1]: Starting User Manager for UID 5000... Jan 21 16:19:28 testserver.rhsoft.net systemd[1268]: pam_unix(systemd-user:session): session opened for user builduser by (uid=0) Jan 21 16:19:28 testserver.rhsoft.net systemd[1268]: Failed to determine supported controllers: No such process Jan 21 16:19:28 testserver.rhsoft.net systemd[1268]: Failed to allocate manager object: No such process Jan 21 16:19:28 testserver.rhsoft.net systemd[1273]: pam_unix(systemd-user:session): session closed for user builduser Jan 21 16:19:28 testserver.rhsoft.net systemd[1]: user@5000.service: Failed with result 'protocol'. Jan 21 16:19:28 testserver.rhsoft.net systemd[1]: Failed to start User Manager for UID 5000. > [root@testserver:~]$ systemctl status user@48.service > ● user@48.service - User Manager for UID 48 >Loaded: loaded (/usr/lib/systemd/system/user@.service; static; vendor > preset: disabled) >Active: failed (Result: protocol) since Tue 2020-01-21 16:00:02 CET; > 16min ago > Docs: man:user@.service(5) > Process: 34694 ExecStart=/usr/lib/systemd/systemd --user (code=exited, > status=1/FAILURE) > Main PID: 34694 (code=exited, status=1/FAILURE) > CPU: 35ms > > Jan 21 16:00:01 testserver.rhsoft.net systemd[1]: Starting User Manager > for UID 48... > Jan 21 16:00:01 testserver.rhsoft.net systemd[34694]: > pam_unix(systemd-user:session): session opened for user apache by (uid=0) > Jan 21 16:00:02 testserver.rhsoft.net systemd[34694]: Failed to > determine supported controllers: No such process > Jan 21 16:00:02 testserver.rhsoft.net systemd[34694]: Failed to allocate > manager object: No such process > Jan 21 16:00:02 testserver.rhsoft.net systemd[34709]: > pam_unix(systemd-user:session): session closed for user apache > Jan 21 16:00:02 testserver.rhsoft.net systemd[1]: user@48.service: > Failed with result 'protocol'. > Jan 21 16:00:02 testserver.rhsoft.net systemd[1]: Failed to start User > Manager for UID 48. > > [root@testserver:~]$ cat /usr/lib/systemd/system/user@.service > # SPDX-License-Identifier: LGPL-2.1+ > # > # This file is part of systemd. > # > # systemd is free software; you can redistribute it and/or modify it > # under the terms of the GNU Lesser General Public License as published by > # the Free Software Foundation; either version 2.1 of the License, or > # (at your option) any later version. > > [Unit] > Description=User Manager for UID %i > Documentation=man:user@.service(5) > After=systemd-user-sessions.service user-runtime-dir@%i.service dbus.service > Requires=user-runtime-dir@%i.service > IgnoreOnIsolate=yes > > [Service] > User=%i > PAMName=systemd-user > Type=notify > ExecStart=-/usr/lib/systemd/systemd --user > Slice=user-%i.slice > KillMode=mixed > Delegate=pids memory > TasksMax=infinity > TimeoutStopSec=120s > KeyringMode=inherit
Re: [systemd-devel] Failed to determine supported controllers: No such process
Am 21.01.20 um 16:13 schrieb Lennart Poettering: > On Di, 21.01.20 15:55, Reindl Harald (h.rei...@thelounge.net) wrote: > >> Hi >> >> about to upgrade prepare Fedora 31 upgrades >> >> -- >> >> Jan 21 15:30:01 testserver systemd[17664]: Failed to determine supported >> controllers: No such process >> Jan 21 15:30:01 testserver systemd[17664]: Failed to allocate manager >> object: No such process >> Jan 21 15:30:01 testserver systemd[1]: user@48.service: Failed with >> result 'protocol'. >> Jan 21 15:30:01 testserver systemd[1]: Failed to start User Manager for >> UID 48. > > How does user "user@48.service" and its drop-ins look like? as shipped as part of systemd which is the one starting full sessions just because of a cronjob [root@testserver:~]$ systemctl status user@48.service ● user@48.service - User Manager for UID 48 Loaded: loaded (/usr/lib/systemd/system/user@.service; static; vendor preset: disabled) Active: failed (Result: protocol) since Tue 2020-01-21 16:00:02 CET; 16min ago Docs: man:user@.service(5) Process: 34694 ExecStart=/usr/lib/systemd/systemd --user (code=exited, status=1/FAILURE) Main PID: 34694 (code=exited, status=1/FAILURE) CPU: 35ms Jan 21 16:00:01 testserver.rhsoft.net systemd[1]: Starting User Manager for UID 48... Jan 21 16:00:01 testserver.rhsoft.net systemd[34694]: pam_unix(systemd-user:session): session opened for user apache by (uid=0) Jan 21 16:00:02 testserver.rhsoft.net systemd[34694]: Failed to determine supported controllers: No such process Jan 21 16:00:02 testserver.rhsoft.net systemd[34694]: Failed to allocate manager object: No such process Jan 21 16:00:02 testserver.rhsoft.net systemd[34709]: pam_unix(systemd-user:session): session closed for user apache Jan 21 16:00:02 testserver.rhsoft.net systemd[1]: user@48.service: Failed with result 'protocol'. Jan 21 16:00:02 testserver.rhsoft.net systemd[1]: Failed to start User Manager for UID 48. [root@testserver:~]$ cat /usr/lib/systemd/system/user@.service # SPDX-License-Identifier: LGPL-2.1+ # # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=User Manager for UID %i Documentation=man:user@.service(5) After=systemd-user-sessions.service user-runtime-dir@%i.service dbus.service Requires=user-runtime-dir@%i.service IgnoreOnIsolate=yes [Service] User=%i PAMName=systemd-user Type=notify ExecStart=-/usr/lib/systemd/systemd --user Slice=user-%i.slice KillMode=mixed Delegate=pids memory TasksMax=infinity TimeoutStopSec=120s KeyringMode=inherit ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to determine supported controllers: No such process
On Di, 21.01.20 15:55, Reindl Harald (h.rei...@thelounge.net) wrote: > Hi > > about to upgrade prepare Fedora 31 upgrades > > -- > > Jan 21 15:30:01 testserver systemd[17664]: Failed to determine supported > controllers: No such process > Jan 21 15:30:01 testserver systemd[17664]: Failed to allocate manager > object: No such process > Jan 21 15:30:01 testserver systemd[1]: user@48.service: Failed with > result 'protocol'. > Jan 21 15:30:01 testserver systemd[1]: Failed to start User Manager for > UID 48. How does user "user@48.service" and its drop-ins look like? Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Failed to determine supported controllers: No such process
Hi about to upgrade prepare Fedora 31 upgrades -- Jan 21 15:30:01 testserver systemd[17664]: Failed to determine supported controllers: No such process Jan 21 15:30:01 testserver systemd[17664]: Failed to allocate manager object: No such process Jan 21 15:30:01 testserver systemd[1]: user@48.service: Failed with result 'protocol'. Jan 21 15:30:01 testserver systemd[1]: Failed to start User Manager for UID 48. -- this is pretty sure a classical cronjob running as "apache" we do we need to lower security with never ssystemd versions in case i am right about "ProtectControlGroups=yes" is the problem? -- [root@testserver:~]$ cat /etc/systemd/system/crond.service.d/security.conf [Service] # global restrictions ProtectControlGroups=yes ProtectKernelModules=yes ProtectKernelTunables=yes RestrictAddressFamilies=AF_INET AF_INET6 AF_LOCAL AF_UNIX AF_NETLINK SystemCallFilter=~@clock @cpu-emulation @debug @module @mount @reboot @swap # allow raid-check with 'ProtectKernelTunables' enabled ReadWritePaths=-/sys/block/md0 ReadWritePaths=-/sys/block/md1 ReadWritePaths=-/sys/block/md2 # protect root-account ReadOnlyPaths=-/root/.bash_logout ReadOnlyPaths=-/root/.bash_profile ReadOnlyPaths=-/root/.bashrc ReadOnlyPaths=-/root/.cshrc ReadOnlyPaths=-/root/.local/bin ReadOnlyPaths=-/root/.local/sbin ReadOnlyPaths=-/root/.local/share ReadOnlyPaths=-/root/.tcshrc ReadOnlyPaths=-/root/.ssh/authorized_keys ReadOnlyPaths=-/root/.ssh/authorized_keys2 # write-protect boot-partition and rpm-database ReadOnlyPaths=-/boot ReadOnlyPaths=-/var/lib/rpm # write-protect system-folders ReadOnlyPaths=-/usr/bin ReadOnlyPaths=-/usr/include ReadOnlyPaths=-/usr/lib ReadOnlyPaths=-/usr/lib64 ReadOnlyPaths=-/usr/libexec ReadOnlyPaths=-/usr/local/bin ReadOnlyPaths=-/usr/local/sbin ReadOnlyPaths=-/usr/sbin ReadOnlyPaths=-/usr/share ReadOnlyPaths=-/usr/src # prohibit change system-users/groups from root-cronjobs ReadOnlyPaths=-/etc/group ReadOnlyPaths=-/etc/group- ReadOnlyPaths=-/etc/gshadow ReadOnlyPaths=-/etc/gshadow- ReadOnlyPaths=-/etc/passwd ReadOnlyPaths=-/etc/passwd- ReadOnlyPaths=-/etc/shadow ReadOnlyPaths=-/etc/shadow- ReadOnlyPaths=-/etc/subgid ReadOnlyPaths=-/etc/subgid- ReadOnlyPaths=-/etc/subuid ReadOnlyPaths=-/etc/subuid- # write-protect critical config-files ReadOnlyPaths=-/etc/aliases ReadOnlyPaths=-/etc/anacrontab ReadOnlyPaths=-/etc/bashrc ReadOnlyPaths=-/etc/cron.allow ReadOnlyPaths=-/etc/cron.deny ReadOnlyPaths=-/etc/crontab ReadOnlyPaths=-/etc/crypttab ReadOnlyPaths=-/etc/dracut.conf ReadOnlyPaths=-/etc/e2fsck.conf ReadOnlyPaths=-/etc/ethertypes ReadOnlyPaths=-/etc/filesystems ReadOnlyPaths=-/etc/fstab ReadOnlyPaths=-/etc/host.conf ReadOnlyPaths=-/etc/hostname ReadOnlyPaths=-/etc/hosts ReadOnlyPaths=-/etc/hosts.allow ReadOnlyPaths=-/etc/hosts.deny ReadOnlyPaths=-/etc/inittab ReadOnlyPaths=-/etc/ld.so.cache ReadOnlyPaths=-/etc/ld.so.conf ReadOnlyPaths=-/etc/libuser.conf ReadOnlyPaths=-/etc/locale.conf ReadOnlyPaths=-/etc/login.defs ReadOnlyPaths=-/etc/mdadm.conf ReadOnlyPaths=-/etc/mke2fs.conf ReadOnlyPaths=-/etc/my.cnf ReadOnlyPaths=-/etc/netconfig ReadOnlyPaths=-/etc/networks ReadOnlyPaths=-/etc/nsswitch.conf ReadOnlyPaths=-/etc/ntp.conf ReadOnlyPaths=-/etc/php.ini ReadOnlyPaths=-/etc/profile ReadOnlyPaths=-/etc/protocols ReadOnlyPaths=-/etc/resolv.conf ReadOnlyPaths=-/etc/rkhunter.conf ReadOnlyPaths=-/etc/rkhunter.conf.local ReadOnlyPaths=-/etc/rsyslog.conf ReadOnlyPaths=-/etc/shells ReadOnlyPaths=-/etc/sudoers ReadOnlyPaths=-/etc/sysctl.conf ReadOnlyPaths=-/etc/xattr.conf # write-protect critical config-folders ReadOnlyPaths=-/etc/alternatives ReadOnlyPaths=-/etc/bash_completion.d ReadOnlyPaths=-/etc/binfmt.d ReadOnlyPaths=-/etc/chkconfig.d ReadOnlyPaths=-/etc/cron.d ReadOnlyPaths=-/etc/cron.daily ReadOnlyPaths=-/etc/cron.hourly ReadOnlyPaths=-/etc/cron.monthly ReadOnlyPaths=-/etc/cron.weekly ReadOnlyPaths=-/etc/depmod.d ReadOnlyPaths=-/etc/dnf ReadOnlyPaths=-/etc/dracut.conf.d ReadOnlyPaths=-/etc/exports.d ReadOnlyPaths=-/etc/grub.d ReadOnlyPaths=-/etc/iproute2 ReadOnlyPaths=-/etc/krb5.conf.d ReadOnlyPaths=-/etc/ld.so.conf.d ReadOnlyPaths=-/etc/logrotate.d ReadOnlyPaths=-/etc/logwatch ReadOnlyPaths=-/etc/lynis ReadOnlyPaths=-/etc/modprobe.d ReadOnlyPaths=-/etc/modules-load.d ReadOnlyPaths=-/etc/openvpn ReadOnlyPaths=-/etc/pam.d ReadOnlyPaths=-/etc/php ReadOnlyPaths=-/etc/php.d ReadOnlyPaths=-/etc/php.lounge.d ReadOnlyPaths=-/etc/popt.d ReadOnlyPaths=-/etc/prelink.conf.d ReadOnlyPaths=-/etc/profile.d ReadOnlyPaths=-/etc/rc.d ReadOnlyPaths=-/etc/request-key.d ReadOnlyPaths=-/etc/rpm ReadOnlyPaths=-/etc/rsyslog.d ReadOnlyPaths=-/etc/security ReadOnlyPaths=-/etc/selinux ReadOnlyPaths=-/etc/sensors.d ReadOnlyPaths=-/etc/skel ReadOnlyPaths=-/etc/sudoers.d ReadOnlyPaths=-/etc/sysctl.d ReadOnlyPaths=-/etc/tmpfiles.d ReadOnlyPaths=-/etc/udev ReadOnlyPaths=-/etc/xdg ReadOnlyPaths=-/etc/xinetd.d ReadOnlyPaths=-/etc/yum.repos.d
Re: [systemd-devel] systemd-detect-virt API
On Tue, Jan 21, 2020 at 1:34 PM Pavla Kratochvilova wrote: > Hi, > > Is there any API for systemd-detect-virt that would provide a way to call > it from a c++ code? > > I need to detect if running in container and "systemd-detect-virt -c" gets > the job done, but I don't want to call the shell command. I haven't found > any good way, but maybe I am missing something. > I think the only other option is to make a DBus call to systemd – read the "org.freedesktop.systemd1.Manager.Virtualization" property at /org/freedesktop/systemd1. (This would also avoid permission problems in case any detection methods require root.) -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-detect-virt API
Hi, Is there any API for systemd-detect-virt that would provide a way to call it from a c++ code? I need to detect if running in container and "systemd-detect-virt -c" gets the job done, but I don't want to call the shell command. I haven't found any good way, but maybe I am missing something. Thanks, -- Pavla Kratochvílová Software Engineer Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
