[systemd-devel] How to debug blocking service start?
hurikhan77 at gmail.com
Thu Mar 26 12:26:10 PDT 2015
Kai Hendry <hendry at webconverger.com> schrieb:
> Hi there,
> How do I figure out why or where something is stuck?
> `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 .
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  - 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  to activate surf.service a few seconds after X11 is
guarenteed to be up, but that would just be a bandaid.
: man systemd.service
: man systemd.timer
: 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.
More information about the systemd-devel