On Wed, Mar 6, 2024 at 2:01 PM Lennart Poettering <lenn...@poettering.net> wrote:
> On Mi, 06.03.24 11:11, Shreenidhi Shedi (shreenidhi.sh...@broadcom.com) > wrote: > > > Hi All, > > > > What is the rationale behind using sshd.socket other than not keeping > sshd > > daemon running always and reducing memory consumption? > > Note that there are two distinct modes to running sshd via socket > activation: the per-connection mode (using sshd's native inetd mode), > where there's a separate instance forked off by systemd for each > connection, and the a mode where systemd just binds the socket, but > it's served by a single instance. The latter is only supported via an > out-of-tree patch afaik though, which at least debian/ubuntu ship: > > > https://salsa.debian.org/ssh-team/openssh/-/commit/7fa10262be3c7d9fd2fca9c9710ac4ef3f788b08 > > Unless you have a gazillion of connections coming in every second I'd > probably just use the per-connection inetd mode, simply because it's > supported upstream. Would be great of course if openssh would just add > support for the single-instance mode in upstream too, but as I > understand ssh upstream is a bit special, and doesn't want to play > ball on this. > > To summarize the benefits of each mode: > > 1. Traditional mode (i.e. no socket activation) > + connections are served immediately, minimal latency during > connection setup > - takes up resources all the time, even if not used > > 2. Per-connection socket activation mode > + takes up almost no resources when not used > + zero state shared between connections > + robust updates: socket stays connectible throughout updates > + robust towards failures in sshd: the bad instance dies, but sshd > stays connectible in general > + resource accounting/enforcement separate for each connection > - slightly bigger latency for each connection coming in > - slightly more resources being used if many connections are > established in parallel, since each will get a whole sshd > instance of its own. > > 3. Single-instance socket activation mode > + takes up almost no resources when not used > + robust updates: socket stays connectible throughout updates > > > With sshd.socket, systemd does a fork/exec on each connection which is > > expensive and with the sshd.service approach server will just connect > with > > the client which is less expensive and faster compared to > > sshd.socket. > > The question of course is how many SSH instances you serve every > minute. My educated guess is that most SSH installations have a use > pattern that's more on the "sporadic use" side of things. There are > certainly heavy use scenarios though (e.g. let's say you are github > and server git via sshd). I'd suggests to distros to default to mode > 2, and alternatively support mode 3 if possible (and mode 1 if they > don#t want to patch the support for mode 3 in) > > > And if there are issues in unit files like in > > https://github.com/systemd/systemd/issues/29897 it will make the system > > unusable. > > Did any distro ship a unit file like that? That was clearly a buggy > (local?) unit file, I am not aware of any big distro shipping such a > unit file. > > Lennart > > -- > Lennart Poettering, Berlin > Thanks a lot for the responses Andrei, Poettering . We took it from blfs in PhotonOS. https://www.linuxfromscratch.org/blfs/view/11.3-systemd/introduction/systemd-units.html We need to do some more work on these unit files. -- Shedi
