[Solved by a Workaround]Why is pacman starting GnuPG sockets on boot ?

Lone_Wolf · 2024-02-12 17:26:34

WARNING:
This thread deals with low level changes that can easily break your system.

Recently I noticed more lines than usual on startup & shutdown.
(it appears they have been around for atleast 2 months)

I looked at the log and found these :

feb 12 17:54:19 silverbolt systemd[900]: Listening on GnuPG network certificate management daemon.
feb 12 17:54:19 silverbolt systemd[900]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
feb 12 17:54:19 silverbolt systemd[900]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
feb 12 17:54:19 silverbolt systemd[900]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
feb 12 17:54:19 silverbolt systemd[900]: Listening on GnuPG cryptographic agent and passphrase cache.
feb 12 17:54:19 silverbolt systemd[900]: Listening on GnuPG public key management service.

Full journal at http://0x0.st/Hd4u.txt

$ find /etc/systemd -type l -exec test -f {} \; -print | sort
/etc/systemd/system/default.target
/etc/systemd/system/getty.target.wants/getty@tty1.service
/etc/systemd/system/multi-user.target.wants/dhcpcd.service
/etc/systemd/system/multi-user.target.wants/nftables.service
/etc/systemd/system/multi-user.target.wants/ntpd.service
/etc/systemd/system/multi-user.target.wants/syslog-ng@default.service
$

Any idea what starts / shuts down the GnuPG services and what good it brings to have them active ?

ADDED

$ systemctl status --user
● silverbolt
    State: running
    Units: 194 loaded (incl. loaded aliases)
     Jobs: 0 queued
   Failed: 0 units
    Since: Mon 2024-02-12 17:54:19 CET; 34min ago
  systemd: 255.3-1-arch
   CGroup: /user.slice/user-1000.slice/user@1000.service
           ├─init.scope
           │ ├─900 /usr/lib/systemd/systemd --user
           │ └─905 "(sd-pam)"
           └─session.slice
             ├─at-spi-dbus-bus.service
             │ └─1155 /usr/lib/at-spi-bus-launcher
             └─dbus.service
               └─962 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
$ systemctl list-timers
NEXT                            LEFT LAST                           PASSED UNIT                         ACTIVATES                  >
Tue 2024-02-13 00:00:00 CET 5h 31min Mon 2024-02-12 00:00:04 CET         - logrotate.timer              logrotate.service
Tue 2024-02-13 18:09:02 CET      23h Mon 2024-02-12 18:09:02 CET 19min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.serv>

2 timers listed.

Last edited by Lone_Wolf (2024-02-17 17:06:09)

loqs · 2024-02-12 19:09:14

https://gitlab.archlinux.org/archlinux/ … 2584219b25 ?

Lone_Wolf · 2024-02-12 23:46:06

That commit is definitely related and shows where the service & socket files come from, but there's more going on .

$ ls -l /usr/lib/systemd/user/sockets.target.wants/ /usr/lib/systemd/system/sockets.target.wants/
/usr/lib/systemd/system/sockets.target.wants/:
total 0
lrwxrwxrwx 1 root root 14  5 jan 16:13 dbus.socket -> ../dbus.socket
lrwxrwxrwx 1 root root 18  6 feb 20:11 dirmngr@etc-pacman.d-gnupg.socket -> ../dirmngr@.socket
lrwxrwxrwx 1 root root 18 10 jan 12:46 dm-event.socket -> ../dm-event.socket
lrwxrwxrwx 1 root root 28  6 feb 20:11 gpg-agent-browser@etc-pacman.d-gnupg.socket -> ../gpg-agent-browser@.socket
lrwxrwxrwx 1 root root 20  6 feb 20:11 gpg-agent@etc-pacman.d-gnupg.socket -> ../gpg-agent@.socket
lrwxrwxrwx 1 root root 26  6 feb 20:11 gpg-agent-extra@etc-pacman.d-gnupg.socket -> ../gpg-agent-extra@.socket
lrwxrwxrwx 1 root root 24  6 feb 20:11 gpg-agent-ssh@etc-pacman.d-gnupg.socket -> ../gpg-agent-ssh@.socket
lrwxrwxrwx 1 root root 18  6 feb 20:11 keyboxd@etc-pacman.d-gnupg.socket -> ../keyboxd@.socket
lrwxrwxrwx 1 root root 26 24 jan 16:38 systemd-coredump.socket -> ../systemd-coredump.socket
lrwxrwxrwx 1 root root 34 24 jan 16:38 systemd-journald-dev-log.socket -> ../systemd-journald-dev-log.socket
lrwxrwxrwx 1 root root 26 24 jan 16:38 systemd-journald.socket -> ../systemd-journald.socket
lrwxrwxrwx 1 root root 27 24 jan 16:38 systemd-pcrextend.socket -> ../systemd-pcrextend.socket
lrwxrwxrwx 1 root root 24 24 jan 16:38 systemd-sysext.socket -> ../systemd-sysext.socket
lrwxrwxrwx 1 root root 31 24 jan 16:38 systemd-udevd-control.socket -> ../systemd-udevd-control.socket
lrwxrwxrwx 1 root root 30 24 jan 16:38 systemd-udevd-kernel.socket -> ../systemd-udevd-kernel.socket

/usr/lib/systemd/user/sockets.target.wants/:
total 0
lrwxrwxrwx 1 root root 14  5 jan 16:13 dbus.socket -> ../dbus.socket
lrwxrwxrwx 1 root root 17 25 jan 15:51 dirmngr.socket -> ../dirmngr.socket
lrwxrwxrwx 1 root root 27 25 jan 15:51 gpg-agent-browser.socket -> ../gpg-agent-browser.socket
lrwxrwxrwx 1 root root 25 25 jan 15:51 gpg-agent-extra.socket -> ../gpg-agent-extra.socket
lrwxrwxrwx 1 root root 19 25 jan 15:51 gpg-agent.socket -> ../gpg-agent.socket
lrwxrwxrwx 1 root root 23 25 jan 15:51 gpg-agent-ssh.socket -> ../gpg-agent-ssh.socket
lrwxrwxrwx 1 root root 17 25 jan 15:51 keyboxd.socket -> ../keyboxd.socket
$

$ pacman -Qo /usr/lib/systemd/system/sockets.target.wants/dirmngr@etc-pacman.d-gnupg.socket 
/usr/lib/systemd/system/sockets.target.wants/dirmngr@etc-pacman.d-gnupg.socket is owned by pacman 6.0.2-9
$

Looks like the user sockets come from gnupg , but the system sockets from pacman .

These lines from pacman PKGBUILD are related :

  local wantsdir="$pkgdir/usr/lib/systemd/system/sockets.target.wants"
  install -dm755 "$wantsdir"

  local unit
  for unit in dirmngr gpg-agent gpg-agent-{browser,extra,ssh} keyboxd; do
    ln -s "../${unit}@.socket" "$wantsdir/${unit}@etc-pacman.d-gnupg.socket"
  done

They were added in https://gitlab.archlinux.org/archlinux/ … eaeeb9a1c6

Looks like it's related to archlinux-keyring and since I have masked that permanently, maybe I can mask the system sockets also ?

Thread title changed.

Last edited by Lone_Wolf (2024-02-12 23:47:22)

Lone_Wolf · 2024-02-13 12:04:31

The sockets under /usr/lib/systemd/system/sockets.target.wants/ can be masked succesfully with systemctl mask (as root).

6 sockets are involved

dirmngr@etc-pacman.d-gnupg.socket
gpg-agent-browser@etc-pacman.d-gnupg.socket -> /dev/null
gpg-agent@etc-pacman.d-gnupg.socket -> /dev/null
gpg-agent-extra@etc-pacman.d-gnupg.socket -> /dev/null
gpg-agent-ssh@etc-pacman.d-gnupg.socket -> /dev/null
keyboxd@etc-pacman.d-gnupg.socket -> /dev/null

The symlinks in /usr/lib/systemd/user/sockets.target.wants can be masked per user with systemctl mask --user but unfortunately there doesn't seem to be a way to disbale them for all users.

Using brute force by deleting the symlinks and adding NoExtract entries for them to pacman.conf does get rid of them.

I have done both and am now running with those 12 sockets made unusable. Sofar no issues.

NOTE:
I have not removed the services or sockets, just the parts that started them at boot.

Last edited by Lone_Wolf (2024-02-14 12:53:33)

V1del · 2024-02-13 12:27:18

Moving to System Administration, by request.

Raynman · 2024-02-13 14:03:44

Lone_Wolf wrote:

The symlinks in /usr/lib/systemd/user/sockets.target.wants can be masked per user with systemctl mask --user but unfortunately there doesn't seem to be a way to disbale them for all users.

--global ?

Lone_Wolf · 2024-02-14 13:03:26

The systemd manpage states that --global only works with enable & disable, but it also worked with mask --user.

There now 6 symlinks to /dev/null in my /etc/systemd/user folder , so I removed the realted NoExtract statements from pacman.conf.
(The amount of /dev/null symlinks in /etc/systemd/system grew from 5 to 11.)

Still no bad consequences.

Lone_Wolf · 2024-02-17 16:56:27

Several days has passed and still no issues.

The description of the commit that added the autostarting sockets at boot gives some idea why it does that

This makes use of [gnupg!2] and results in GnuPG's daemons being
supervised instead of getting spawned into random cgroups.
For example, when `archlinux-keyring` is updated, `gpg-agent` is
activated. The agent does not shut down by itself, keeping the user
session in `closing` state forever. This unclosed session then prevents
another local user from shutting down the system without admin rights.

Marking as workedaround .

Last edited by Lone_Wolf (2024-02-17 17:05:05)

Arch Linux

#1 2024-02-12 17:26:34

[Solved by a Workaround]Why is pacman starting GnuPG sockets on boot ?

#2 2024-02-12 19:09:14

Re: [Solved by a Workaround]Why is pacman starting GnuPG sockets on boot ?

#3 2024-02-12 23:46:06

Re: [Solved by a Workaround]Why is pacman starting GnuPG sockets on boot ?

#4 2024-02-13 12:04:31

Re: [Solved by a Workaround]Why is pacman starting GnuPG sockets on boot ?

#5 2024-02-13 12:27:18

Re: [Solved by a Workaround]Why is pacman starting GnuPG sockets on boot ?

#6 2024-02-13 14:03:44

Re: [Solved by a Workaround]Why is pacman starting GnuPG sockets on boot ?

#7 2024-02-14 13:03:26

Re: [Solved by a Workaround]Why is pacman starting GnuPG sockets on boot ?

#8 2024-02-17 16:56:27

Re: [Solved by a Workaround]Why is pacman starting GnuPG sockets on boot ?

Board footer