[systemd-devel] How to debug blocking service start?

[Kai Krakow]

Kai Hendry <hendry at webconverger.com> schrieb:

> Hi there,
> 
> How do I figure out why or where something is stuck?
> http://s.natalian.org/2015-03-25/systemd-start-issue.png
> 
> `journalctl -u surf -f` prints nothing.
> 
> Binary surf runs fine when I run it manually.

It probably is not stuck, it's systemd waiting for the command to return. 
Try Type=simple to not let it wait. That is telling systemd, that the binary 
will not daemonize - athough it should be default according to [1].

However, I'm not sure whether the rest of the setup will work. You should 
probably make it a user service, so that you won't have to pass DISPLAY. 
Your special setup may be part of the problem. Also keep in mind that 
After=graphical.target doesn't imply that X11 is ready to accept connections 
- even "worse": it doesn't imply that it is started late in the boot 
process. Your service may start as early as graphical.target becomes 
scheduled to start [3] - and that may be well before even basic system setup 
is finished. Instead, I suggest using a DM with autologin, and then spawn a 
user service from there. As an alternative, you may want to try working with 
timer units [2] to activate surf.service a few seconds after X11 is 
guarenteed to be up, but that would just be a bandaid.

[1]: man systemd.service
[2]: man systemd.timer

[3]: A target is, AFAIK, reached as soon as all services making up the 
target are scheduled to start - so you can rely on sockets being ready but 
nothing more. Targets are sets of functionality to offer, not points in time 
of the boot process - this is different to what you know of sysvinit. 
Multiple targets can be active at the same time, e.g. printer.target pulls 
in cups and becomes activated by udev if you plug in your printer.

-- 
Replies to list only preferred.