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

[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
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.