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

[Zbigniew Jędrzejewski-Szmek]

Hi,

there were some bugs introduced and fixed recently, with regards
to parsing env. files, that could be relevant. What version
of systemd are you running, and what do the logs say?

Zbyszek

On Thu, Apr 18, 2013 at 11:06:43PM -0700, Peter Li wrote:
> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel