On Thu, 25 Apr 2024 at 07:58, Rasmus Villemoes <r...@rasmusvillemoes.dk> wrote: > > On 23/04/2024 13.23, Colin Watson wrote: > > On Tue, Apr 23, 2024 at 09:32:00AM +0200, Rasmus Villemoes wrote: > >> According to systemd.special(7) > >> > >> nss-user-lookup.target > >> > >> A target that should be used as synchronization point for all > >> regular UNIX user/group name service lookups. [...] All > >> services for which the availability of the full user/group > >> database is essential should be ordered after this target, but > >> not pull it in. All services which provide parts of the > >> user/group database should be ordered before this target, and > >> pull it in. > >> > >> I have a custom .service that does exactly as described in the second > >> part, i.e. provides part of the user/group database and says > >> Before=nss-user-lookup.target, Wants=nss-user-lookup.target > >> (concretely, it modifies /etc/shadow to update a default password, but > >> that's not really important). I believe sshd definitely belongs in the > >> former category, i.e. sshd should not be started until any such > >> service that updates the user/group database, such as updating > >> /etc/shadow, have run. > >> > >> Hence the ssh.service and ssh.socket files should add > >> > >> After=nss-user-lookup.target > >> > >> in their [Unit] sections. This is a no-op on systems that do not have > >> any service pulling in that target, but required for correctness on > >> systems that do. > >> > >> Of course, I could, and currently do, handle this via a drop-in config > >> fragment in some ssh.service.d/ directory. But this, and other similar > >> synchronization targets, exist so that one does not necessarily need > >> to know about every other service running on the system. > > > > This sounds like a reasonable proposal to me. I'm just CCing Debian's > > systemd maintainers for a quick review to make sure I'm not missing > > anything subtle. > > > > Thanks. > > I was a bit worried about not adding the After= to the socket, as I > assumed that when the sshd@foobar.service would be started "manually" > (i.e. activated by the socket unit), it would not form part of the whole > initial transaction and hence the sshd@.service's own After= > relationship would not be honored. > > But testing shows I was wrong, and indeed one can establish a connection > to port 22, but the sshd@foobar.service is then marked as waiting until > the appropriate target is reached. > > That said, I'm not sure there is that much value in enabling the socket > allowing connections to come in early, but it's not wrong wrt. > correctness. It's mostly a matter of what UX is better in case a > prerequisite for sshd takes a longish time to get up: not listening at > all on port 22, or accept connections but then just make it hang.
The reason is to avoid connections failing because there's nothing open, and instead let them queue waiting for the service for a bit longer, which is better than retrying
