[systemd-devel] How to control socket activation when it run respawn infinitely.

Tony Seo tonyseo7 at gmail.com
Mon Jan 6 08:56:46 PST 2014


Yeah, I got the process what you explain, thanks.
But, I suspect that systemd has room not to get ACK from the server process
executed by service unit.
I concentrated on 3-way handshaking when I studied to analyze this problem.

Isn't it right when we consider the systemd?


2014/1/1 David Timothy Strauss <david at davidstrauss.net>

> On Tue, Dec 31, 2013 at 9:20 AM, Tony Seo <tonyseo7 at gmail.com> wrote:
> > But What I really want to know is why the server process always waited in
> > the accept stage, when I executed client process for the first after
> system
> > boot.
>
> It may hang in accept() if the service is Accept=true and the daemon
> still tries to accept(). It may also hang on accept() if it's simply
> blocking until the next connection.
>
> > As you know that socket activation makes a service related with socket
> unit
> > executed with connection of client process.
> > If the procedure for socket activation would run like that, the server
> > process executed for the first may not prepare the passive connection
> which
> > should be set beforehand because of client connection.
> > In my view, this waiting problem will be continue as far as the server
> > process is simultaneously executed with the client process.
> >
> > what do you think about it?
>
> There is no race condition, if that's what you mean. systemd waits
> using epoll for the appropriate event for starting a child daemon (for
> Accept=false) or child processes (for Accept=true). For Accept=false,
> it's the same effect as if a daemon used epoll on the listener socket
> and only ran accept() in a callback, just possibly with a bit more
> delay.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140107/352f4f31/attachment.html>


More information about the systemd-devel mailing list