[systemd-devel] Service unit issue: starts manually but doesn't start on boot
Colin Guthrie
gmane at colin.guthr.ie
Fri Apr 19 04:16:02 PDT 2013
'Twas brillig, and Peter Li at 19/04/13 07:06 did gyre and gimble:
> Greetings, I hope this issue is familiar to someone here. I wrote a
> unit file for a service called "wsgw". It starts fine with `systemctl
> start wsgw`, and `systemctl enable wsgw` goes smoothly, but the service
> doesn't start on boot.
>
> My only diagnostic so far has been running `systemctl status wsgw`.
> When I do this after a boot, I get the following:
When you say "after a boot", it would appear to be at least 1 hour after
you booted (or perhaps this is some quirk due to system clocks)
> wsgw.service - WebSockets Gateway for pianod
> Loaded: loaded (/usr/lib/systemd/system/wsgw.service; enabled)
> Active: inactive (dead) since Thu, 18 Apr 2013 21:06:37 -0700;
> 1h 0min ago
See 1h ago :)
The fact that this is listed here with a time means that systemd *did*
start it but it exited...
> Process: 874 ExecStart=/usr/sbin/wsgw $PORT $LOGGING $SERVICES
> (code=exited, status=0/SUCCESS)
And here you can see that it exited with code 0 (which generally means
"No error").
> When I then run `systemctl start wsgw; systemctl status wsgw` I get:
>
> wsgw.service - WebSockets Gateway for pianod
> Loaded: loaded (/usr/lib/systemd/system/wsgw.service; enabled)
> Active: active (running) since Thu, 18 Apr 2013 22:09:40
> -0700; 7ms ago
> Main PID: 2565 (wsgw)
> CGroup: name=systemd:/system/wsgw.service
> └ 2565 /usr/sbin/wsgw -p 8000 pianod,localhost,4445,text
I suspect that on boot the network or name resolution is not available
and your service is started "too soon".
> One thing I notice between the failed-on-boot and
> succeeded-on-manual-start cases is that the environment variables appear
> to be unsubstituted in the failed-on-boot case. But of course, one
> looks like it is reprinting the ExecStart line, and one looks like it's
> listing the actual command for the successfully running process, so this
> difference may be expected.
Yes, that's why they are different.
> I have confirmed that executing the wsgw with no arguments or blank
> arguments does cause an exit with status 0. It seems like lots of
> invalid arguments all produce exits with status 0 actually, so probably
> I should talk to the main developer about making these exit codes more
> helpful.
I suspect it will also exit if there is no network ready or similar, but
don't know for sure.
> Also the timestamp on the failed status is wrong; it's an hour earlier
> than it should be.
Ahhh :) Ignore my earlier comment then. I suspect this is just related
to the clock configuration and time "jumps" at some point in early boot
when those settings are loaded.
> I have another service with a very similar setup that doesn't have this
> issue. Links to the two unit files and the EnvironmentFile for each
> (wsgw is the one with the issue, pianod is very similar but works on boot):
> http://svn.deviousfish.com/wsgw/contrib/wsgw.service
In this case there is no dependency on network. So unless the binary is
able to "do the right thing" with network devices coming and going (it
should as that's the correct behaviour in these dynamic days, but it's
highly unlikely it does because very few applications are doing it right!)
You should likely have a After=network.target in your unit
(After=syslog.target is not needed in recent systemd's but F17 is quite
old now so it may still need it). You may also need to do some kind of
"wait online" thing to delay network.target until you have a working
network - Network manager ships such a unit which just needs to be enabled.
> I've run `systemd --test --system --unit=multi-user.target` and compared
> the wsgw and pianod sections of output and no significant differences
> jump out at me.
Perhaps pianod doesn't need the network?
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
More information about the systemd-devel
mailing list