Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

systemd failed to create user.slice

619 views
Skip to first unread message

Jochen Spieker

unread,
Apr 22, 2021, 7:10:07 PM4/22/21
to
Hi,

the short version of my problem is this, happening on a fairly fresh
stable system:

# systemctl start us...@1000.service
Job for us...@1000.service failed because the service did not take the steps required by its unit configuration.
See "systemctl status us...@1000.service" and "journalctl -xe" for details.
# systemctl status us...@1000.service
● us...@1000.service - User Manager for UID 1000
Loaded: loaded (/lib/systemd/system/user@.service; static; vendor preset: enabled)
Active: failed (Result: protocol) since Fri 2021-04-23 00:38:59 CEST; 9s ago
Docs: man:user@.service(5)
Process: 20895 ExecStart=/lib/systemd/systemd --user (code=exited, status=1/FAILURE)
Main PID: 20895 (code=exited, status=1/FAILURE)

Apr 23 00:38:59 example.com systemd[1]: Starting User Manager for UID 1000...
Apr 23 00:38:59 example.com systemd[20895]: pam_unix(systemd-user:session): session opened for user jrspieker by (uid=0)
Apr 23 00:38:59 example.com systemd[20895]: Failed to create /user.slice/user-1000.slice/us...@1000.service/init.scope control group: Permission denied
Apr 23 00:38:59 example.com systemd[20895]: Failed to allocate manager object: Permission denied
Apr 23 00:38:59 example.com systemd[1]: us...@1000.service: Failed with result 'protocol'.
Apr 23 00:38:59 example.com systemd[1]: Failed to start User Manager for UID 1000.


This happens during login via SSH for UID 1000 as well as other user
IDs. I do not see any bad effect except the log spam. I straced this and
think here is the root of the problem:

16971 stat("/sys/fs/cgroup/systemd/user.slice/user-112.slice/us...@112.service", 0x7ffd5f215640) = -1 EACCES (Permission denied)

This is due to:

# ls -ld /sys/fs/cgroup/systemd/
drwx------ 5 root root 0 Mar 21 23:58 /sys/fs/cgroup/systemd/


I have a different buster system where this directory is mode 555 (yes,
not writable by anybody) and that systemd does bot exhibit the behavior
above.

It appears to be working if I just chmod the directory. What/who is
responsible for the proper permissions of that sysfs directory?

J.
--
I wear a lot of leather but would never wear fur.
[Agree] [Disagree]
<http://archive.slowlydownward.com/NODATA/data_enter2.html>
signature.asc
0 new messages