Andrey Borzenkov wrote:
В Wed, 02 Jan 2013 04:02:27 -0700
JB <gene...@itpsg.com> пишет:
Andrey Borzenkov wrote:
В Wed, 02 Jan 2013 02:28:19 -0700
JB <gene...@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.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
