[systemd-devel] sometimes systemd takes a very long time to restart service

[Andrey Borzenkov]

В Wed, 02 Jan 2013 04:02:27 -0700
JB <general at itpsg.com> пишет:

> Andrey Borzenkov wrote:
> > В Wed, 02 Jan 2013 02:28:19 -0700
> > JB <general at itpsg.com> пишет:
> >
> >   
> >> Here's the service file:
> >> *******************************************
> >> [Unit]
> >> Description=Webrick Test Service
> >> After=network.target
> >>
> >> [Service]
> >> Type=forking
> >> ExecStart=/usr/bin/ruby /home/rtuser/test.rb
> >>
> >> [Install]
> >> WantedBy=multi-user.target
> >> *******************************************
> >>
> >> I put this in /etc/systemd/system/webrickd.service
> >> Then ran systemctl --system daemon-reload
> >> Then ran systemctl start webrickd.service
> >>
> >> Running it from the command line runs as it should.  Web server starts 
> >> and test.rb is running in the background as a daemon returning me back 
> >> to the shell.
> >>
> >> But as soon as I try to use systemd, it starts but as soon as the 
> >> WEBrick::Daemon.start call is made, everything is killed.
> >>     
> > That is because of ...
> >   
> >> webrickd.service - Webrick Test Service
> >>           Loaded: loaded (/etc/systemd/system/webrickd.service)
> >>           Active: inactive (dead) since Wed, 02 Jan 2013 01:23:01 -0700; 
> >> 9min ago
> >>          Process: 1605 ExecStart=/usr/bin/ruby /home/rtuser/test.rb 
> >> (code=exited, status=0/SUCCESS)
> >>         Main PID: 1607 (code=exited, status=0/SUCCESS)
> >>     
> >                                ^^^^^^
> >   
> >>           CGroup: name=systemd:/system/webrickd.service
> >>
> >>     
> >
> > You daemon forks too much. This would be a problem with some of
> > implementations of initscript as well. Even worse, it may sometimes
> > work due to race condition and sometimes it may fail.
> >   
> As far as I know, it forks once.  You sure it forks "too much?"

The only other explanation would be that daemon simply exits
immediately. But then it hardly can be called "daemon"?  

> Not interested in shooting anyone but I am interested in the 
> interpretation of "programming error."  Seems like you're assuming the 
> systemd assumptions and paradigm are perfect.  Pretty sure Unix never 
> dictated default forking limits, at least not until things like fork 
> bombs came about and security issues were considered.  Forking more than 
> once could hardly be considered a programming error.  I think systemd 
> folks came up with that one all by themselves :)  My point is that 
> assuming systemd's default allow one fork approach is "pure" and then 
> passing the rigid inflexibility off as design flaws and programming 
> errors on the part of daemon developers, IMHO goes too far.
> >   

systemd monitors service. Service is represented by process. If you
allow unlimited flexibility in how many times service can fork before
it finally starts its main process - how can systemd know which process
to monitor? When fork chain stops? I am sure if you suggest race free
way to do it that works in all cases, everyone will be happy to
integrate it in systemd.

If you do not really care whether systemd can monitor state of service
and are OK with "start it and forget about it", just add
RemainAfterExit=true. sytemd is flexible enough to support both ways.

> 
> So, if I proceed using "Simple" and then later as a result of one of the 
> web service calls made to the server either use fork/exec or system() to 
> launch another process that runs for anywhere from 30 seconds to several 
> hours, then that process exits but not the one that originally started, 
> will systemd have a problem with that?
> 

It should not. That is what many services do already.