[systemd-devel] Possible confusion with socket activation and daemon own configuration

[Francis Moreau]

On 09/08/2015 12:09 PM, Richard Maw wrote:
> On Tue, Sep 08, 2015 at 10:05:05AM +0200, Francis Moreau wrote:
>> On 09/07/2015 11:28 AM, Richard Maw wrote:
>>> On Sun, Sep 06, 2015 at 12:43:51PM +0200, Francis Moreau wrote:
>>>> How is this handled ? Should we put a big warning in sshd_config to hint
>>>> user to configure ListenAddress in sshd.socket in the case socket
>>>> activation is used ?
>>>
>>>> Or should sshd simply ignore all listening addresses defined in sshd_config
>>>> when in socket activation mode ?
>>>
>>> That would be my preferred solution. I may be missing something important here,
>>> but I'd always assumed that sshd wouldn't need to worry about the listen
>>> address if something else was accepting the connections on the socket.
>>>
>>
>> The downside of this would be that starting the service directly (ie not
>> the socket unit) won't work anymore
> 
> Does it?
> 
> 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 at .service and sshd.socket.
> 
> The former runs with -D, and the latter runs with -i.
> 

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 at .service and sshd.service.

I suppose that was done because sshd wasn't modified to use systemd's
native socket passing interface (sd_listen_fds). If it was the case then
only one service unit file would be used I think. And in this case, the
service unit would start sshd in 'OnDemand' mode always. In this case we
can't start directly sshd.service, but have to use socket activation.

> Presumably this would be sufficient information that sshd could be made to
> ignore the listen address in the sshd_config if it's being run with -i.
> 

I'm not sure I'm understanding...

[...]
> 
> For parsing config files of other configuration systems, no, sysvinit and
> /etc/fstab are mostly the only foreign configuration formats systemd cares
> about.
> 
> These are also split out into the generator mechanism rather than parsed by
> systemd directly.
> 
> Systemd tends not to carry service configuration for other software,
> though the openssh upstream, or their distribution downstreams could
> carry the code for a listen address configuration generator.
> 
> See http://www.freedesktop.org/software/systemd/man/systemd.generator.html for
> how generators work and
> https://github.com/systemd/systemd/blob/master/src/debug-generator/debug-generator.c
> for an example.
> 

Thanks for the pointer. That makes sense although I'm not sure that
service projects are willing to include a systemd generator in their repo.