You are not logged in.
Hello,
systemd user daemon does not seem to start at boot:
#journalctl -u user@1000.service
lip 25 08:18:04 abc systemd[1]: Starting User Manager for UID 1000...
lip 25 08:18:04 abc systemd[2310]: pam_unix(systemd-user:session): session opened for user marcin by (uid=0)
lip 25 08:18:04 abc systemd[2310]: Failed to fully start up daemon: Permission denied
lip 25 08:18:04 abc systemd[1]: user@1000.service: Failed with result 'protocol'.
lip 25 08:18:04 abc systemd[1]: Failed to start User Manager for UID 1000.
#systemctl status user@1000.service
● user@1000.service - User Manager for UID 1000
Loaded: loaded (/usr/lib/systemd/system/user@.service; static; vendor preset: disabled)
Active: failed (Result: protocol) since Wed 2018-07-25 08:18:04 CEST; 7min ago
Process: 2310 ExecStart=/usr/lib/systemd/systemd --user (code=exited, status=1/FAILURE)
Main PID: 2310 (code=exited, status=1/FAILURE)
lip 25 08:18:04 abc systemd[1]: Starting User Manager for UID 1000...
lip 25 08:18:04 abc systemd[2310]: pam_unix(systemd-user:session): session opened for user marcin by (uid=0)
lip 25 08:18:04 abc systemd[2310]: Failed to fully start up daemon: Permission denied
lip 25 08:18:04 abc systemd[1]: user@1000.service: Failed with result 'protocol'.
lip 25 08:18:04 abc systemd[1]: Failed to start User Manager for UID 1000.
I use up to date system. Lightdm, xfce desktop, kernel 4.17.8-1-ARCH
I cannot decipher what "Failed to fully start up daemon: Permission denied" means. Is there a way to increase its verbosity to pinpoint where permission denied error is occurring?
Offline
Can you post the service file?
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
# 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
After=systemd-user-sessions.service
After=user-runtime-dir@%i.service
Requires=user-runtime-dir@%i.service
[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
I think I know where might be the problem: I mount /run/user/1000 in my development docker-compose file in order to access ssh-keyring at boot time. Docker being docker, creates mount directory when it is not present in the host filesystem, so I suspect race condition there.
Last edited by Czarnodziej (2018-07-26 05:52:42)
Offline
I have the same problem (at least it manifests in the same way). Did you manage to solve it?
This started with systemd 239 so I've been holding off on upgrading to it since it makes my machine unusable, but I can't hold it off any longer.
Offline
@dkasak I would suggest you start a new thread for your issue include the output for user@1000.service from a boot under systemd 238 and a boot under systemd 239.
Also try creating a new user and see if the issue affects the new user and include the result in the new thread.
Offline
Actually, I just solved this yesterday, but didn't have time to post yet.
I remembered that I set up my user@.service manually a long time ago, before it was distributed by Arch Linux, so I had a custom and slightly different version of the service file which apparently broke with systemd 239. Deleting the custom service file and re-enabling the service fixed it.
Offline