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 <da...@davidstrauss.net> > On Tue, Dec 31, 2013 at 9:20 AM, Tony Seo <tonys...@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. >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
