[systemd-devel] Failed to determine supported controllers: No such process

Reindl Harald h.reindl at thelounge.net
Tue Jan 21 16:51:19 UTC 2020



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.reindl at 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


More information about the systemd-devel mailing list