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>