<html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> 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: <blockquote> <tt>wsgw.service - WebSockets Gateway for pianod</tt><tt> </tt><tt> Loaded: loaded (/usr/lib/systemd/system/wsgw.service; enabled)</tt><tt> </tt><tt> Active: inactive (dead) since Thu, 18 Apr 2013 21:06:37 -0700; 1h 0min ago</tt><tt> </tt><tt> Process: 874 ExecStart=/usr/sbin/wsgw $PORT $LOGGING $SERVICES (code=exited, status=0/SUCCESS)</tt><tt> </tt><tt> CGroup: name=systemd:/system/wsgw.service</tt><tt> </tt></blockquote> When I then run `systemctl start wsgw; systemctl status wsgw` I get: <blockquote><tt>wsgw.service - WebSockets Gateway for pianod</tt><tt> </tt><tt> Loaded: loaded (/usr/lib/systemd/system/wsgw.service; enabled)</tt><tt> </tt><tt> Active: active (running) since Thu, 18 Apr 2013 22:09:40 -0700; 7ms ago</tt><tt> </tt><tt> Main PID: 2565 (wsgw)</tt><tt> </tt><tt> CGroup: name=systemd:/system/wsgw.service</tt><tt> </tt><tt> └ 2565 /usr/sbin/wsgw -p 8000 pianod,localhost,4445,text</tt> </blockquote> 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): <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a href="http://svn.deviousfish.com/wsgw/contrib/wsgw.service">http://svn.deviousfish.com/wsgw/contrib/wsgw.service</a> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a href="http://svn.deviousfish.com/wsgw/contrib/wsgw.env">http://svn.deviousfish.com/wsgw/contrib/wsgw.env</a> <a href="http://svn.deviousfish.com/pianod/pianod/contrib/pianod.service">http://svn.deviousfish.com/pianod/pianod/contrib/pianod.service</a> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a href="http://svn.deviousfish.com/pianod/pianod/contrib/pianod.env">http://svn.deviousfish.com/pianod/pianod/contrib/pianod.env</a> 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 <blockquote><tt> </tt></blockquote> </body> </html>