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

[JB]

Andrey Borzenkov wrote:
> В 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"?  
>   
Agreed, only other thing I could think of is if it is somehow 
immediately getting a SIGINT or SIGTERM somehow.
>   
>> 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.
>
>   
Thanks, I'll try that.