On Tue, Jun 18, 2013 at 3:04 AM, Łukasz Stelmach <l.stelm...@samsung.com> wrote: > It was <2013-06-17 pon 20:51>, when Lennart Poettering wrote: >> On Fri, 14.06.13 14:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) >> wrote: >> >>> On Fri, Jun 14, 2013 at 10:03:00AM +0200, Łukasz Stelmach wrote: >>>> We are converting some daemons to socket activation. Most of them >>>> open unix sockets and manage incoming connections in a main-loop, so >>>> the easiest way to convert it is to create Accept=false socket with >>>> systemd. >>>> >>>> Now, it is quite well described how to start such daemon, however, >>>> there is little about shutting it down. Should the daemon close(2) >>>> the received sockets? Should it unlink(2) them from a filesystem? >>> close() yes, unlink() no. >> >> Strictly speaking you don't even have to do that. The kernel will >> clean up left-over fds when your process exits, hence you don't have >> to close it explicitly. >> >> But you certainly should not unlink() the socket in the fs, because >> then the socket will not be accessible anymore. > > Maybe I've asked the wrong question. I should rather have asked: Can I > close? Can I unlink? Because that's what the code does now and we wanted > to know which parts are common for standalone and > systemd-socket-activated paths.
The way I think about it is that if you are socket activated, you have a .socket unit and a .service unit. The .socket unit controls the socket. The .service unit does NOT control the socket. Therefore, the .service daemon should NOT unlink the socket. Auke _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
