Management of background services with systemd

David Joaquín Shourabi Porcel david at
Wed Mar 1 21:34:25 CET 2023

I am researching GnuPG for my employer. We will stick with the old release series 2.2 at first, because few Linux distributions package 2.3 or 2.4 yet. However, I'm studying newer versions and recent developments to ease our future upgrades. In doing so, a question has arisen: should background services like the agent not be managed with systemd?

Daniel Kahn Gillmor [introduced][1] and maintained systemd unit files and also implemented `--supervised` for the [agent][2] and [dirmngr][3] as part of version 2.1.16. However, `--supervised` has been [deprecated][4] since version 2.3.6 and Werner recently [removed the systemd unit files][5] altogether. In fact, he commented the following on [task T6336][6] about two months ago:

> Actually, the entire systemd based launching is deprecated and thus the logged warning [about `--supervised`] is on purpose.
> The problem with the systemd launched gpg-agent is that it creates a race: gpg launches gpg-agent as needed and to avoid concurrent launching by other gpg or gpgsm processes, it takes a file system lock during the launch process. systemd does not know about this and we end up with sometimes end up with two gpg-agent processes. Eventually one of those processes detects that it does not own the socket and terminates itself. No real harm here but you may see smart card lockups or a flushed password cache.

For what it's worth, the systemd setup (as packaged with series 2.2) works very well for me. In particular:

 - background services are managed through a common interface (that of systemd);
 - logs are centralized; and
 - the agent starts whenever OpenSSH needs it, thanks to socket activation.

I have experienced only one limitation: there is no convenient way for systemd to manage background processes for [ephemeral home directories][7], which I have been using extensively for my research & testing.


More information about the Gnupg-users mailing list