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:
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
Process: 874 ExecStart=/usr/sbin/wsgw $PORT $LOGGING $SERVICES
(code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/wsgw.service
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
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.
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.
Also the timestamp on the failed status is wrong; it's an hour earlier
than it should be.
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
http://svn.deviousfish.com/wsgw/contrib/wsgw.env
http://svn.deviousfish.com/pianod/pianod/contrib/pianod.service
http://svn.deviousfish.com/pianod/pianod/contrib/pianod.env
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.
I have this issue on both a RaspberryPi running ArchLinuxARM, and an
x86_64 running FedoraCore17.
Thanks for reading,
Peter
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
