Description of problem: Let's get the ball rolling on this one... http://fedoraproject.org/wiki/Features/SysVtoSystemd Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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.