I remember this discussed before, I think one suggestion was to split into two targets, and only hold the login until the first target. Nobody implemented it though.<div><br></div><div>But yes, pulseaudio.socket would be a requirement of that. If you don't want to wait until it starts, *and* don't want to socket-activate it, the third option is to live in a world of race conditions.<br><br><div class="gmail_quote"><div dir="ltr">On Sun, Jan 10, 2016, 16:25 Tom Yan <<a href="mailto:tom.ty89@gmail.com">tom.ty89@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So I am recently experiencing some issue with pulseaudio (which I<br>
already filed a bug report:<br>
<a href="https://bugs.freedesktop.org/show_bug.cgi?id=93651" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=93651</a>) that it takes a<br>
long time to start.<br>
<br>
The thing is, I am thinking whether it exposed a problem of systemd as<br>
well. For example:<br>
<br>
Jan 10 21:31:33 localhost systemd[257]: Starting Sound Service...<br>
Jan 10 21:31:33 localhost systemd[257]: Started D-Bus User Message Bus.<br>
Jan 10 21:31:39 localhost systemd[257]: Started Sound Service.<br>
Jan 10 21:31:39 localhost systemd[257]: Reached target Default.<br>
Jan 10 21:31:39 localhost systemd[257]: Startup finished in 5.830s.<br>
<br>
As you can see, because of pulseaudio, it takes about 6 seconds to<br>
reach the default target.<br>
<br>
The reason I realise that pulseaudio is having this issue, is because<br>
I can actually "experience" the 6 seconds after I entered my password<br>
in the tty, if I have pulseaudio.service enabled. The login shell only<br>
pops up after the default target has been reached.<br>
<br>
But isn't the very first goal of systemd avoiding delay like this? Is<br>
it considered normal that the login shell only pops up after it<br>
reached the default target? In that case, isn't it bad to have<br>
pulseaudio.service wanted by the default target (instead of some<br>
target that will not block the login shell)?<br>
<br>
Ironically even if I put `pulseaudio &` in ~/.bash_profile to start<br>
it, I wouldn't "experience" such delay.<br>
<br>
Please don't tell me that pulseaudio.socket is the solution, coz it's<br>
irrelevant to the issue I am talking about. The whole point of<br>
enabling the service instead of just the socket is to avoid<br>
"experiencing" the startup of pulse.<br>
_______________________________________________<br>
systemd-devel mailing list<br>
<a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
</blockquote></div></div>