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

[Tom Yan]

That's exactly what I meant. There should be a target for units that
"need to be waited" and "no need to be waited" respectively. One can
argue which one should a sound service fall into with whatever point,
but that's out of the scope of the issue I am talking about here.

I just thought systemd has implemented this at its very beginning,
seems like I was wrong. At I least I got my answer though. Thanks,
grawity <3

On 11 January 2016 at 01:15, Mantas Mikulėnas <grawity at gmail.com> wrote:
> 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