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.
