Kai Hendry <hen...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel