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

Kai Hendry hendry at webconverger.com
Thu Mar 26 19:32:00 PDT 2015

First, thanks for trying to help me Kai. Awesome name btw.

On Fri, 27 Mar 2015, at 03:26 AM, Kai Krakow wrote:
> 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].

It's still getting stuck with Type=simple.


Isn't there a better way to debug than running journalctl -u <service>
-f in parallel?

The frustrating thing is that the SAME service file works fine on
another rpi2.

> 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 

You mean systemctl --user right?

I don't like that since it seems like a lot of extra crud. What's the
big deal about passing in the DISPLAY environment?

I don't see the point of having a non-root user. Trying to keep things
as simple as possible to achieve my use case. Which is to start a
browser once online.

> - 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.

Well, if X wasn't up up, I was hoping Restart=always would do the rest.

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

Timers seem like a kluge, just to know when X is ready.


More information about the systemd-devel mailing list