[systemd-devel] Service unit issue: starts manually but doesn't start on boot

[Peter Li]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20130418/40f81add/attachment.html>