[pulseaudio-discuss] [systemd-devel] user unit blocking login shell from popping out because wanted by default target?
grawity at gmail.com
Sun Jan 10 09:15:58 PST 2016
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: Starting Sound Service...
> Jan 10 21:31:33 localhost systemd: Started D-Bus User Message Bus.
> Jan 10 21:31:39 localhost systemd: Started Sound Service.
> Jan 10 21:31:39 localhost systemd: Reached target Default.
> Jan 10 21:31:39 localhost systemd: 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pulseaudio-discuss