Page MenuHome GnuPG
Create Task
Maniphest T5942

scdaemon is blocking system shutdown
Open, LowPublic
Actions

Description

When I reboot my computer, systemd waits for its default 90 seconds for scdaemon to shut down but eventually it kills it afterwards.

I have gpg-agent running but I don't have any smart card (including Yubikey) inserted into my computer.

Logs from systemd:

systemd[1]: session-1.scope: Stopping timed out. Killing.
systemd[1]: session-1.scope: Killing process 2209 (scdaemon) with signal SIGKILL.
systemd[1]: session-1.scope: Killing process 2336 (libusb_event) with signal SIGKILL.
systemd[1]: session-1.scope: Killing process 2344 (n/a) with signal SIGKILL.
systemd[1]: session-1.scope: Failed with result 'timeout'.
systemd[1]: session-1.scope: Stopping timed out. Killing.
systemd[1]: session-1.scope: Killing process 2023 (scdaemon) with signal SIGKILL.
systemd[1]: session-1.scope: Killing process 2024 (pipe-connection) with signal SIGKILL.
systemd[1]: session-1.scope: Killing process 2230 (libusb_event) with signal SIGKILL.
systemd[1]: session-1.scope: Failed with result 'timeout'.
systemd[1]: session-1.scope: Stopping timed out. Killing.
systemd[1]: session-1.scope: Killing process 2058 (scdaemon) with signal SIGKILL.
systemd[1]: session-1.scope: Killing process 2258 (libusb_event) with signal SIGKILL.
systemd[1]: session-1.scope: Killing process 2262 (conn fd=12) with signal SIGKILL.
systemd[1]: session-1.scope: Failed with result 'timeout'.
systemd[1]: session-1.scope: Stopping timed out. Killing.
systemd[1]: session-1.scope: Killing process 12979 (scdaemon) with signal SIGKILL.
systemd[1]: session-1.scope: Killing process 12980 (pipe-connection) with signal SIGKILL.
systemd[1]: session-1.scope: Killing process 13163 (n/a) with signal SIGKILL.
systemd[1]: session-1.scope: Failed with result 'timeout'.

When I disabled it in gpg-agent.conf and restarted the agent, the system could reboot immediately.

OS: openSUSE Linux 5.17.1
GPG version: 2.3.4

Details

Version
2.3.4

Related Objects

Event Timeline

szotsaki created this task.Apr 25 2022, 8:15 AM
szotsaki created this object in space S1 Public.
• werner closed this task as Wontfix.Apr 25 2022, 11:53 AM
• werner claimed this task.
• werner added a subscriber: • werner.

Please contact the Debian developers for any systemd/gnupg issues. We don't suggest the use of the --supervised option because it causes more problems than it claims to solve.

szotsaki added a comment.Apr 27 2022, 6:06 PM

I see the following GPG-related commands running currently (with disable-scdaemon in config file):

1853 ?        Ss     0:00 /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display /usr/libexec/xinit/xinitrc
1857 ?        Ssl  1827:45 /usr/bin/gpg-agent --sh --daemon --keep-display /usr/libexec/xinit/xinitrc
2118 ?        Sl     0:56 /usr/bin/kgpg -session 10c2c5b8b3000159674768700000019420008_1649842916_330951

None of them contain --supervised. Are you sure this bug is related to this gpg-agent mode?

• gniibe reopened this task as Open.Apr 28 2022, 4:03 AM
• gniibe added a subscriber: • gniibe.

Thank you for the explanation. (It's not related to --supervised, I suppose.)

In a usual case, gpg-agent is a child process of a session. Then, gpg-agent is terminated at shutdown/reboot (or closing the session). When gpg-agent is terminated, scdaemon is also terminated.

In your setup, gpg-agent is the parent process of the session (of xinitrc). scdaemon remains because gpg-agent is still there. IIUC, your systemd also waits for gpg-agent.

szotsaki added a comment.Apr 28 2022, 8:24 AM

Thank you for the hints!

In this case I think I can provide a reproducer (that's in my KDE environment, but I suppose it should work in other DEs):

~/.config/old-autostart-scripts/start-gpg-agent.sh
#!/bin/bash
/usr/bin/gpg-agent --daemon --use-standard-socket
~/.config/autostart/start-gpg-agent.sh.desktop
[Desktop Entry]
Exec=/home/NNNNN/.config/old-autostart-scripts/start-gpg-agent.sh
Icon=dialog-scripts
Name=start-gpg-agent.sh
Path=
Type=Application
X-KDE-AutostartScript=true

There's no more information there, but I found some other forum comments claiming they have similar issue.

• werner triaged this task as Low priority.Apr 28 2022, 8:48 AM
• werner added a project: Support.
• ikloecker added a subscriber: • ikloecker.Apr 28 2022, 10:01 AM

If you add an autostart script then you may have to add a corresponding shutdown script as well, e.g. a script running gpgconf --kill all. You cannot expect that daemons, that you start via an autostart script, magically know when they should terminate.

• ikloecker added a comment.Apr 28 2022, 10:12 AM

FWIW, your comments about the autostart script do not match with the running processes. Obviously, the autostart script starts gpg-agent with different command line options than the running process. My conclusion is that the autostart script isn't used. Or maybe it is started, but gpg-agent immediately terminates because it notices that another instance is already running.

The gpg-agent running with /usr/bin/gpg-agent --sh --daemon --keep-display /usr/libexec/xinit/xinitrc should terminate "within a few seconds" (according to the man page) after /usr/libexec/xinit/xinitrc has terminated. So, maybe your problem is that some other process stops /usr/libexec/xinit/xinitrc from terminating.

yescallop added a subscriber: yescallop.May 7 2023, 7:51 PM

I also experienced hang on shutdown with GPG 2.4.1 and bisecting reveals that the first bad commit is rG2ccbcfec121f.

The root cause might be that the "DEVINFO --watch" command causes the connection handling thread in scdaemon to block forever and thus not signalling a disconnection afterwards. When scdaemon receives the first SIGTERM it incorrectly thinks that there are still active connections so it won't shut down immediately.

Will anyone tell me if this is the case? Thanks!

• gniibe added a comment.May 8 2023, 1:55 AM

The root cause might be that the "DEVINFO --watch" command causes ...

If it were the case, I think that graceful shutdown of the system would need to terminate the client of scdaemon at first.

yescallop added a comment.May 8 2023, 3:13 AM

If it were the case, I think that graceful shutdown of the system would need to terminate the client of scdaemon at first.

This seems to have been the case on my Arch Linux with systemd.

I provide simple steps to reproduce the problem:

  1. Run scdaemon --server in shell
  2. Run DEVINFO --watch in scdaemon
  3. Press Ctrl+D and watch it not exit

If the DEVINFO --watch is not run, scdaemon exits immediately on Ctrl+D and outputs these lines in the log:

2023-05-08 09:06:42 scdaemon[20318] DBG: chan_6 <- [eof]
2023-05-08 09:06:42 scdaemon[20318] handler for fd -1 terminated
2023-05-08 09:06:42 scdaemon[20318] scdaemon (GnuPG) 2.4.1 stopped

Otherwise it just hangs and doesn't output anything in the log.

yescallop added a comment.Nov 5 2024, 5:45 AM

This seems to have been resolved in 2.4.6 by T7151 or T7160. I don't really remember the details, but at least I don't see anything blocking system shutdown now.