Thank you. I haven't seen any apparent DNS problems; I fixed it, on a Debian host, by deleting the gnupg packages; probably deleting just gpgconf would have sufficed. That said, the IP addresses I used really would not show up in a DNS lookup. If I see it again, I will look for DNS lookup attempts.
Dec 15 22:23:14 ip-99-99-99-100 sshd[1995]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Dec 15 22:23:14 ip-99-99-99-100 systemd[1]: Created slice User Slice of UID 1000.
Dec 15 22:23:14 ip-99-99-99-100 systemd[1]: Starting User Runtime Directory /run/user/1000...
Dec 15 22:23:14 ip-99-99-99-100 systemd-logind[510]: New session 34 of user admin.
Dec 15 22:23:14 ip-99-99-99-100 systemd[1]: Finished User Runtime Directory /run/user/1000.
Dec 15 22:23:14 ip-99-99-99-100 systemd[1]: Starting User Manager for UID 1000...
Dec 15 22:23:14 ip-99-99-99-100 systemd[2001]: pam_unix(systemd-user:session): session opened for user admin by (uid=0)
Dec 15 22:24:44 ip-99-99-99-100 systemd[2003]: pam_unix(systemd-user:session): session closed for user admin
Dec 15 22:24:44 ip-99-99-99-100 systemd[1]: user@1000.service: Main process exited, code=exited, status=1/FAILURE
Dec 15 22:24:44 ip-99-99-99-100 systemd[1]: user@1000.service: Killing process 2007 (gpgconf) with signal SIGKILL.
Dec 15 22:24:44 ip-99-99-99-100 systemd[1]: user@1000.service: Killing process 2008 (awk) with signal SIGKILL.
Dec 15 22:24:44 ip-99-99-99-100 systemd[1]: user@1000.service: Killing process 2013 (dirmngr) with signal SIGKILL.
Dec 15 22:24:44 ip-99-99-99-100 systemd[1]: user@1000.service: Failed with result 'exit-code'.
Dec 15 22:24:44 ip-99-99-99-100 systemd[1]: Failed to start User Manager for UID 1000.
Dec 15 22:24:44 ip-99-99-99-100 systemd[1]: Started Session 34 of user admin.
But what are these evidently unnecessary session and User Manager things? What controls starting them? What are they supposed to do for me, if they ever work right? Why did starting them fail?
The user manager directs things like user services. That can be things like starting pulseaudio on a desktop machine, for example, or gnupg on general systems so the user has a gnupg daemon available in their own UID space. This alleviates putting them into .rc or .profile files and making them hard to manage in case they fail.
In this case, GNUPG is trying and failing to start (likely misconfigured), this in turn means system failed to start the likely only user service configured, hence it fails the session setup. The session is still created (managed via logind) to provide a shell and PAM environment.
On a non-systemd this stuff would be managed by other scripts and tools that do essentially the same thing (minus being able to start user services).
It also creates a slice for the session, which enables systemd to kill all processes created in a session when the session ends (logout), minus some exceptions that can manage themselves (like Tmux). Helps against people who forget that they backgrounded and nohup'd a script (which isn't a good way to do things that are supposed to keep running).
If you want to see what services are available in your user session run 'systemctl --user'.
In this case, gnupg was, both for that user and for that host, wholly unconfigured -- evidently it was just roped in by some package dependency. So, trying to run something that depended on the system or user having gnupg configured correctly (or at all) was wholly wrong.
Systemd killing my nohups does not seem like doing me a favor. If I had wanted the process killed when my connection dropped, I would not have nohup'd it. (Later in the article, I use nohup as intended.) How do I turn that off, without breaking other things? Or, failing that, what is the right way to get that behavior, without nohup?
And, what controls which services the session manager will try to run on behalf of a user who has not tried to customize anything? It would probably have been better to turn pushy gpg-agent off, in some sysyem-wide way, than to have entirely deleted it.
Systemd doesn't kill nohups as long as the session exists. Hence your nohup works if you opened tmux or a graphical terminal and close it. But logging out terminates all processes belonging to that session that don't properly disassociate from the session.
You can run 'loginctl enable-linger' to disable this behaviour or set 'KillUserProcesses=no' in /etc/systemd/logind.conf
You can also use 'systemd-run --scope --user /usr/bin/yourscript.sh', this will explicitly keep the process running even when the session closes, even if lingering processes are killed. It'll also keep track of all processes created by that script, so if the script exits, it'll kill all processes that are left over and cleanup. It also meshes with other parts of systemd so `systemd-run --scope --user --on-calendar=daily /usr/bin/script' will run the script daily until you tell it to stop or the machine restarts (since it's not configured on disk). You can even keep the service if the script dies with '--remain-after-exit', which tells systemd to keep the service alive as long as processes for it exist or you terminate it manually.
If whatever your running in the background needs forking, you can create a service and start it under your user, that properly keeps it up and running.
Systemd understands a nohup as "don't terminate the process when the terminal closes", not as "don't terminate the process when the session ends" which can be different events depending on the setup (ie, graphical terminal or tmux).
The session manager will start any user services that are activated, your distro usually configures that in '/usr/lib/systemd/user'. Manually activated units are in '/etc/systemd/user' if they are system-wide and user config is in '$XDG_CONFIG_HOME/systemd/user' or '$HOME/.local/share/systemd/user'.
To turn it off you can deactivate it via 'systemctl --user disable gpg-agent' for the current user or 'systemctl --global disable gpg-agent' for all users. If it activates via socket activation you can either disable the socket 'systemctl --global disable gpg-agent.socket' or mask the service 'systemctl --global mask gpg-agent'. Masking the service prevents it from being started for any reason.
