[systemd-devel] user unit blocking login shell from popping out because wanted by default target?

[Andrei Borzenkov]

10.01.2016 17:25, Tom Yan пишет:
> So I am recently experiencing some issue with pulseaudio (which I
> already filed a bug report:
> https://bugs.freedesktop.org/show_bug.cgi?id=93651) that it takes a
> long time to start.
> 
> The thing is, I am thinking whether it exposed a problem of systemd as
> well. For example:
> 
> Jan 10 21:31:33 localhost systemd[257]: Starting Sound Service...
> Jan 10 21:31:33 localhost systemd[257]: Started D-Bus User Message Bus.
> Jan 10 21:31:39 localhost systemd[257]: Started Sound Service.
> Jan 10 21:31:39 localhost systemd[257]: Reached target Default.
> Jan 10 21:31:39 localhost systemd[257]: Startup finished in 5.830s.
> 
> As you can see, because of pulseaudio, it takes about 6 seconds to
> reach the default target.
> 
> The reason I realise that pulseaudio is having this issue, is because
> I can actually "experience" the 6 seconds after I entered my password
> in the tty, if I have pulseaudio.service enabled. The login shell only
> pops up after the default target has been reached.
> 
> But isn't the very first goal of systemd avoiding delay like this? Is

Bot really.

> it considered normal that the login shell only pops up after it
> reached the default target? 

systemd is unaware of "login shell". It knows about units and their
dependencies. If one unit declares it must wait on another unit, systemd
obeys it.

>                             In that case, isn't it bad to have
> pulseaudio.service wanted by the default target (instead of some
> target that will not block the login shell)?
> 

I fail to find pulseaudio.service in systemd sources. You probably
should address this question to whoever provided it.

> Ironically even if I put `pulseaudio &` in ~/.bash_profile to start
> it, I wouldn't "experience" such delay.
> 
> Please don't tell me that pulseaudio.socket is the solution, coz it's
> irrelevant to the issue I am talking about. The whole point of
> enabling the service instead of just the socket is to avoid
> "experiencing" the startup of pulse.

So you admit yourself that you will always have delay. In this case you
can only chose at which point you will have delay.

And next someone will complain about missing sound on login because
pulseaudio is not running ...