Re: systemd user@###.service failure causing 90 sec delays during boot, login
On Mon, Feb 28, 2022 at 10:28:49PM +0000, KCB Leigh wrote:
> This operating system has worked excellently for months, but for the last 2 days has suddenly been taking a very long time to boot. The cause of the delay can be seen from the syslog:
Obvious question 1: what changed 2 days ago?
> Feb 28 10:11:01 cpe-67-241-65-193 systemd[1]: user@119.service: Main process exited, code=exited, status=1/FAILURE
> Feb 28 10:11:01 cpe-67-241-65-193 systemd[1]: user@119.service: Killing process 1144 (gpgconf) with signal SIGKILL.
That UID is extremely low. Do you intentionally use users with UIDs in
the 119 range, perhaps because of interoperability with some other system
on your network? Or because of a /home file system that has been migrated
from a different OS?
I would check to see which user(s) are defined with this UID. Maybe there's
a collision.
awk -F: '$3 == 119' /etc/passwd
That should show them all, if they're all defined in /etc/passwd. If you've
got NIS or LDAP or something like that, then you may want to check there
as well. I could easily see a new package being installed, which creates
a new user, which grabs the first unused UID from the users in /etc/passwd,
but doesn't realize that UID 119 is actually used in your network password
database.
> Feb 28 10:11:01 cpe-67-241-65-193 systemd[1]: user@119.service: Killing process 1145 (awk) with signal SIGKILL.
> Feb 28 10:11:01 cpe-67-241-65-193 systemd[1]: user@119.service: Killing process 1174 (dirmngr) with signal SIGKILL.
Certainly looks like you're actually logging in with this UID.
Another thing I'd check, just based on past messages that I've seen here,
is the ownership/permissions of the / directory.
ls -ld /
It should be owned by root, group root, and have 755 perms. If that
ownership gets changed for some reason, it causes all kinds of mess.
Reply to: