On 09/08/2015 07:48 PM, Simon McVittie wrote: > On 08/09/15 13:55, Francis Moreau wrote: >> On 09/08/2015 12:09 PM, Richard Maw wrote: >>> I understood that the common configuration for socket activated sshd was to >>> have a sshd.service for if you want it to always be running, and a pair of >>> sshd@.service and sshd.socket. >> >> Ah no, with this design starting sshd.service should do the right thing >> but that's because there're 2 different service unit files: >> sshd@.service and sshd.service. > > As far as I understand it, this duplication is present to give the > sysadmin a choice between two ways to run sshd, depending on this > particular ssh server's requirements. > > If ssh access is frequently used or needs to work quickly (for instance > as the primary way to log in and fix things), enabling sshd.service > means it will start "eagerly", on boot. Debian and its derivatives > enable this by default (if sshd is installed). > > If ssh access is infrequently used, a sysadmin can disable sshd.service > and enable sshd.socket instead. That means sshd will be started > on-demand, which will take a bit longer (particularly if the reason to > log in is that the server has hit performance problems), but reduces > resource consumption until then. This would be appropriate if the reason > for providing ssh access is as a rarely-used "developer console" > analogous to Android's adb, for instance. >
Yes that's my understanding too. But I guess that some services can't be instanciated for each request and in this case, there can be only one service unit, I think. And if it's the case starting the service in on-demand mode will prevent to start the service unit file by its own (ie. not using the socket unit file). Thanks. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
