4 ms·

> NOTE: Systemd has a nasty habit of delaying logins for 25 - 100 seconds while it waits for some service you never asked for to time out and fail, before it le

> NOTE: Systemd has a nasty habit of delaying logins for 25 - 100 seconds while it waits for some service you never asked for to time out and fail, before it lets you have a prompt. If you experience this when logging in to a host via SSH, the delays are almost certainly due to either missing or non-functional forward/reverse DNS (the SSH server will perform these lookups when connections are received). You've got at least three options (in order of preference): - Add the appropriate (A/PTR) resource records to DNS so that the queries get a valid response - Add entries to /etc/hosts file - Set "UseDNS no" in the /etc/ssh/sshd_config file and add "-u 0" to the parameters passed to `sshd` when it's started (how to do this will vary by distribution/operating system)

ncmncm 6y ago
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?
- corrigible 6y ago
  Could your issue be related to this SF post? https://serverfault.com/questions/954844/chroot-gpg-agent-and-ubuntu-18-04 https://serverfault.com/questions/954844/chroot-gpg-agent-an...
- zaarn 6y ago
  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'.
  - ncmncm 6y ago
    Thank you. 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.

ncmncm 6y ago

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?

corrigible 6y ago
Could your issue be related to this SF post? https://serverfault.com/questions/954844/chroot-gpg-agent-and-ubuntu-18-04 https://serverfault.com/questions/954844/chroot-gpg-agent-an...
zaarn 6y ago
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'.
- ncmncm 6y ago
  Thank you. 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.