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

[Mantas Mikulėnas]

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.

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.

On Sun, Jan 10, 2016, 16:25 Tom Yan <tom.ty89 at gmail.com> wrote:

> 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
> it considered normal that the login shell only pops up after it
> reached the default target? 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)?
>
> 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.
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20160110/33472fe8/attachment.html>