A transcript of today's session:
x@yz:~$ shutdown now
User nobody is logged in on ???.
Please retry operation after closing inhibitors and logging out other users.
Alternatively, ignore inhibitors and users with 'systemctl poweroff -i'.
I've used shutdown now
all the time and never seen anything like this. What is this? What's nobody
's business on ???
? I'm the sole user of my sys and have never messed w/ nobody
there
EDIT (per comments):
x@yz:~$ ps -aux | grep nobody
nobody 2666 0.0 0.0 45408 132 ? Ss May 09 0:00 /lib/systemd/systemd --user
nobody 2667 0.0 0.0 163956 8 ? S May 09 0:00 (sd-pam)
x 11189 0.0 0.0 24480 1004 pts/0 S+ 02:50 0:00 grep --color=auto nobody
x@yz:~$ ps -U 65534
PID TTY TIME CMD
2666 ? 00:00:00 systemd
2667 ? 00:00:00 (sd-pam)
Best Answer
To clarify it all :-
1. How nobody user came in your system?
Nobody user is a pseudo user created by default on a fresh install in many Linux and Unixes distributions
2. Who is nobody user ?
"Nobody" user has the least permissions on the system. It owns no files, is in no privileged groups, and has no abilities except those which every other user has. Nobody user has no shell assigned to it.
3. What is the purpose of nobody user ?
In early Unix and Linux Distributions, it was common to run daemons (for example a webserver) under nobody user to limit the damage to the rest of the system, so that If a malicious user gained control over such a daemon, he do not have access to any file or privileged rights.
But the problem is, when there are multiple daemons running with the nobody user, this has no sense anymore. That's why today such daemons have their own user.
4. How nobody user logged in on your system ?
You might have some service/daemon running which runs under nobody user. Some examples of services can be: httpd, nfs, postfix , etc
5. What are the two processes running on your system under nobody user ?
6. Why are the processes ( systemd and sd-pam ) still there , even when the service that ran under nobody user is not running anymore ?
Well this has been reported as a bug where
Systemd is not able to close pam session properly because sd-pam subprocess drops privileges after pam_open_session(). So pam_close_session() runs as the user rather than as root which breaks PAM modules that need to do privileged tasks to clean up the session.
For more information on this:
https://github.com/systemd/systemd/issues/8598
https://github.com/systemd/systemd/issues/1350
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803907;msg=5
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749268