Score:0

systemd-launched service exists in /var/lib/systemd but not visible in list-units, list-unit-files or status

bt flag

I'm seeing the following in /var/log/auth.log

Jun  1 06:32:49 [redacted] su: (to nobody) root on none
Jun  1 06:32:49 [redacted] su: pam_unix(su:session): session opened for user nobody(uid=65534) by (uid=0)
Jun  1 06:32:49 [redacted] systemd: pam_unix(systemd-user:session): session opened for user nobody(uid=65534) by (uid=0)
Jun  1 06:32:49 [redacted] su: pam_unix(su:session): session closed for user nobody

Matching entries in /var/log/daemon.log

Jun  1 06:32:49 [redacted] systemd[1]: Created slice User Slice of UID 65534.
Jun  1 06:32:49 [redacted] systemd[1]: Starting User Runtime Directory /run/user/65534...
Jun  1 06:32:49 [redacted] systemd[1]: Finished User Runtime Directory /run/user/65534.
Jun  1 06:32:49 [redacted] systemd[1]: Starting User Manager for UID 65534...
Jun  1 06:32:49 [redacted] systemd[39580]: Queued start job for default target Main User Target.
Jun  1 06:32:49 [redacted] systemd[39580]: Created slice User Application Slice.
Jun  1 06:32:49 [redacted] systemd[39580]: Reached target Paths.
Jun  1 06:32:49 [redacted] systemd[39580]: Reached target Timers.
Jun  1 06:32:49 [redacted] systemd[39580]: Listening on GnuPG network certificate management daemon.
Jun  1 06:32:49 [redacted] systemd[39580]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Jun  1 06:32:49 [redacted] systemd[39580]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Jun  1 06:32:49 [redacted] systemd[39580]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Jun  1 06:32:49 [redacted] systemd[39580]: Listening on GnuPG cryptographic agent and passphrase cache.
Jun  1 06:32:49 [redacted] systemd[39580]: Reached target Sockets.
Jun  1 06:32:49 [redacted] systemd[39580]: Reached target Basic System.

Looking in /usr/lib/systemd ...

$ sudo find /usr/lib/systemd -name gpg\* -o -name gnupg\*
/usr/lib/systemd/user/gpg-agent-ssh.socket
/usr/lib/systemd/user/gpg-agent.service
/usr/lib/systemd/user/gpg-agent-browser.socket
/usr/lib/systemd/user/gpg-agent-extra.socket
/usr/lib/systemd/user/gpg-agent.socket

However, there's no gpg-agent listed in list-units or list-unit-files, and the status command returns an error:

$ sudo systemctl status gpg-agent
Unit gpg-agent.service could not be found.

I also tried --user:

$ sudo systemctl status --user
Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)

Clearly I'm missing something here...

Where in systemd is the configuration file that is executing su to user nobody and launching gpg-agent?

Score:1
ng flag

systemctl status --user is what you want to use to show user-level services, as this is part of the "User Slice" (specifically one with UID 65534) indicated in your error messages.

bt flag
Tried that, result is `Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)`
walder avatar
ng flag
are you using `sudo`? if you ARE then you are doing it wrong and will receive this error message. use the command verbatim as i have typed it.
bt flag
OK, that works, but it doesn't answer my original question: Where in systemd is the configuration that is executing `su` to user `nobody` and launching gpg-agent? I'll update the question to be more specific.
walder avatar
ng flag
i guess i'm not sure what you are asking at this point. if you're wanting to know the specific unit file, type `systemctl status --user gpg-agent.service`. this has all the relevant information regarding the status of the service along with the location of the .service file. if you're wanting to see where and when it's being ran, the above command will provide this information. you can also access the cgroups tree by typing `systemd-cgls --user`. this provides a map of the control groups showing which group is responsible for starting the services being ran through systemd.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.