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 <graw...@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.t...@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@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/systemd-devel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
