Bug 737264

Created attachment 522518 [details]
cvs socket

Created attachment 522519 [details]
cvs service

Once package and shipped your package should no longer have to depend on xinetd

https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd

The socket file has 

[Install]
WantedBy=sockets.target

Does it mean the socket becomes listing automatically and hence the service available by default? I don't think this is good idea. Moreover <https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd#Socket_activation> writes automatic activation requires FESCo exception.

That happens only if you enable it at install time and afaik service are supposed to be not enabled by default without granted permission from fesco so installing it but not enable it should suffice.

Users would have to run systemctl start $foo.socket and systemctl enable $foo.socket for the service to start/enable the service/socket

You are right.

I found another issue. If socket-activated cvs process exits with failure, systemd keeps service records (systemctl --all --full adds new line). Is it intentional from point of view of systemd? I just ask because PID=1 process then allocates about 9.9 KB for each terminated service, so this looks like attack vector. Is there any way how to shrink the list of failed services?

(In reply to comment #6)
> I found another issue. If socket-activated cvs process exits with failure,
> systemd keeps service records (systemctl --all --full adds new line). Is it
> intentional from point of view of systemd? I just ask because PID=1 process
> then allocates about 9.9 KB for each terminated service, so this looks like
> attack vector. Is there any way how to shrink the list of failed services?

See bug #739538.

Petr,

I've just done (bug #884641) a very similar (xinetd -> socket activatable systemd service) migration with cups-lpd. I've been out of curiosity looking for similar services and found this and I *think* the scriptlets you've used in cvs.spec are not good.

cvs.spec has had for example:

%preun
%systemd_preun cvs@.service

where [1] %systemd_preun macro is:
if [ $1 -eq 0 ] ; then \
        # Package removal, not upgrade \
        @rootbindir@/systemctl --no-reload disable %{?*} > /dev/null 2>&1 || : \
        @rootbindir@/systemctl stop %{?*} > /dev/null 2>&1 || : \
fi \

The 'systemctl --no-reload disable cvs@.service' or 'systemctl stop cvs@.service' result in 'Failed to issue method call:'.

So I think there should be
%systemd_post cvs.socket
%systemd_preun cvs.socket
%systemd_postun_with_restart cvs.socket
instead of
%systemd_post cvs@.service
%systemd_preun cvs@.service
%systemd_postun_with_restart cvs@.service
because you need to enable/disable/start/stop the cvs.socket and not the cvs@.service

What do you think ?

[1] http://cgit.freedesktop.org/systemd/systemd/tree/src/core/macros.systemd.in

I bet when I were developing the code it was working. Now I get the same results as you. Moreover stopping cvs.socket closes listening TCP socket, but keeps connected servers running.

CVS process terminates only when stopping exact instance of cvs@.service (e.g. cvs@1-::1:2401-::1:35341.service) however the TCP connection remains connected to PID 1.

I asked systemd developers how to stop all instances <http://lists.freedesktop.org/archives/systemd-devel/2012-December/007817.html>.

I fixed stopping socket in cvs-1.11.23-29.fc19. I also added cvs.target which can be used to stop the socket and all server instances.

cvs-1.11.23-29.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/cvs-1.11.23-29.fc18

cvs-1.11.23-26.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/cvs-1.11.23-26.fc17

cvs-1.11.23-26.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

cvs-1.11.23-29.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.