[SOLVED] systemd service not starting

Question

Hi,
Been using Arch for just over a week now moving from Ubuntu and loving it. Achieved so much more on Arch in this short time until this evening.
I am trying to run a shell script at startup. I added the service file under /etc/systemd/system/myapp.service
With the following content:
[Unit]
Description=Notification
[Service]
ExecStart=/usr/bin/myscript
[Install]
WantedBy=multi-user.target
As it is I can run "systemctl restart myapp.service" and the script execute flawlessly however on reboot it does nothing and I get this error when I run systemctl status myapp.service:
systemctl status myapp.service
myapp.service - Notification
   Loaded: loaded (/etc/systemd/system/myapp.service; enabled)
   Active: failed (Result: exit-code) since Thu 1970-01-01 10:00:08 EST; 14s ago
  Process: 116 ExecStart=/usr/bin/myscript (code=exited, status=6)
Other info:
Script starts with #!/bin/sh
Script permissions 755
Tried adding After=network.target under unit.
Tried Type=oneshot and forking
O yes /var/log/messages.log | grep myapp
Sep  6 14:25:56 alarm systemd[1]: [/etc/systemd/system/myapp.service:1] Unknown section 'unit'. Ignoring.
Sep  6 14:25:56 alarm systemd[1]: [/etc/systemd/system/myapp.service:2] Assignment outside of section. Ignoring.
Jan  1 01:00:11 alarm systemd[1]: myapp.service: main process exited, code=exited, status=6/NOTCONFIGURED
Jan  1 01:00:11 alarm systemd[1]: Unit myapp.service entered failed state.
Jan  1 01:00:11 alarm [    3.243318] systemd[1]: [/etc/systemd/system/myapp.service:1] Unknown section 'unit'. Ignoring.
Jan  1 01:00:11 alarm [    3.243490] systemd[1]: [/etc/systemd/system/myapp.service:2] Assignment outside of section. Ignoring.
Only thing I dont get is the date difference? I have set the timezone correctly..
Any suggestions?
thanks
Last edited by blueteq (2013-09-10 10:01:11)

Answer 1

Reaching the network.target does not necessarily mean that an active connection has been reached.  For example, if you use wicd or netctl-auto, it will report the stating of the service as successful after the daemon itself has started, but starting the daemon simply means that it is ready to start scanning for wireless networks and then connect.
If you want to be absolutely sure that there is a network connection before the service starts, you should use NetworkManager.service.  That will also pull in the NetworkManager-wait-online.service which will not complete until a full connection has been reached.  At that point the startup will have reached the network-online.target.  So you should order the service after that instead.  In reality, you should order it after that anyway, no matter what netowrk connection service you use, as that is a built in target to systemd.
Even though you have the RestartSec=35 and Restart=on-failure (which is a sane thing to do IMO), it is probably a good idea to order it After=netowrk-online.target anyway, as that will cause the service to start a bit later and at least attempt to order itself correctly.  That way it will also ensure that the service is stopped before the network is taken down as well, hopefully ensuring a clean disconnect as well.