Bug#910512: pulseaudio: Pulseaudio takes longer to start than default systemd timeout
On Sat, Nov 10, 2018 at 5:39 AM Mr riaas mokiem wrote: > > If you issue a `systemctl --user restart pulseaudio`, does it take a > long time too? > This is how I originally verified that it took too long. I don't remember > exactly whether I tried this "restart" specifically or whether I just used > "stop" and then "start" but my best guess is that i tried it both ways. I > don't think it matters though as it should be pretty much equivalent. And > of course, I also verified that it took a long time during boot too. > Hmm. This is very strange. Could you get the logs of rtkit.service? -- Saludos, Felipe Sateler
Bug#910512: pulseaudio: Pulseaudio takes longer to start than default systemd timeout
On Sat, Nov 3, 2018 at 2:19 PM Mr riaas mokiem wrote: > Here's the output: > $ /usr/lib/rtkit/rtkit-test > Max realtime priority is: 20 > Min nice level is: -15 > Rttime limit is: 20 ns > before: > SCHED_RESET_ON_FORK: no > SCHED_OTHER with nice level: 0 > Successfully became high priority. > after high priority: > SCHED_RESET_ON_FORK: yes > SCHED_OTHER with nice level: -10 > Successfully became realtime. > after realtime: > SCHED_RESET_ON_FORK: yes > SCHED_RR with priority 10 > > I'm not sure where to find logs for rtkit during startup though. I also > don't know if any recent system updates have changed this rtkit-test output > since I reported this bug. > You can find the logs with `journalctl --unit rtkit-daemon.service`. But these show rtkit working OK. Maybe it has problems during boot. If you issue a `systemctl --user restart pulseaudio`, does it take a long time too? -- Saludos, Felipe Sateler
Bug#910512: pulseaudio: Pulseaudio takes longer to start than default systemd timeout
On Sat, Oct 13, 2018 at 3:09 AM Mr riaas mokiem wrote: > I think I've got the log. I had to edit the main pulseaudio.service file > because it was saying something about "bad unit" when I used the suggested > command. And I could only find the logs in the main journalctl output (not > with --user or --unit or --user-unit) so I just grepped on pulseaudio which > is why the logs also contain some other lines (like dbus for pulseaudio). > > I made one log with the default timeout of systemd, showing that it times > out, pulseaudio_system_log_timeout.txt > I made another one where I set the timeout to 5 minutes, > pulseaudio_system_log.txt > > I hope this helps. It seems that the startup time went from below 90 > seconds (default systemd timeout) to a bit more than 2 minutes. So I'm not > sure if there was something else slowing down this startup even before I > noticed this timeout. > I'm not sure what is going on. However, I see this: Failed to acquire real-time scheduling: Input/output error This suggests rtkit is for some reason not working properly. Could you run /usr/lib/rtkit/rtkit-test and copy the output? The logs for rtkit during startup could be useful too. -- Saludos, Felipe Sateler
Bug#910512: pulseaudio: Pulseaudio takes longer to start than default systemd timeout
Control: severity -1 important Control: tags -1 moreinfo Hi, On Sun, Oct 7, 2018 at 11:21 AM Riaas Mokiem wrote: > Package: pulseaudio > Version: 12.2-2 > Severity: grave > Justification: renders package unusable > > Lowering severity since it does not appear to affect everyone. > Dear Maintainer, > > Pulseaudio is taking longer to start up than the default 90 seconds that > systemd allows for a service. This means that Pulseaudio does not work on > startup and no matter how much you try to restart it (through systemd), > it won't start up correctly. > > Not sure if this is the cause, but this happened after a recent upgrade > that > removed consolekit and upgraded the linux kernel from 4.18.0-1 to 4.18.0-2 > I changed the timeout of pulseaudio.service to 5 minutes which allowed > Pulseaudio sufficient time to start up correctly. > > I have pretty decent hardware though, so I would have expected the default > timeout for Pulseaudio to be more than sufficient. It has been sufficient > on this hardware until now. I'm not sure what's relevant for Pulseaudio, > but > my system uses the motherboard's onboard sound chip (Realtek ALC S1220A) on > an AMD Ryzen system. > > I'm not sure why Pulseaudio is suddenly taking so much longer to start (or > maybe > systemd shortened the default timeout). But it's worth noting that for > some > reason I still had HDMI audio output, even with pulseaudio timed out. This > is > something that actually hadn't worked before and I haven't really tested it > since the kernel with amdgpu dc has been available. Not sure if that's > relevant. > Possibly. Could you attach a verbose log? $ systemctl --user --runtime edit pulseaudio Add the following lines to the file [Service] ExecStart=/usr/bin/pulseaudio --daemonize=no - Then restart pulseaudio, and get the log with `journalctl --user-unit pulseaudio --since "$when_you_restarted_pulseaudio"` -- Saludos, Felipe Sateler
Bug#910512: pulseaudio: Pulseaudio takes longer to start than default systemd timeout
Package: pulseaudio Version: 12.2-2 Severity: grave Justification: renders package unusable Dear Maintainer, Pulseaudio is taking longer to start up than the default 90 seconds that systemd allows for a service. This means that Pulseaudio does not work on startup and no matter how much you try to restart it (through systemd), it won't start up correctly. Not sure if this is the cause, but this happened after a recent upgrade that removed consolekit and upgraded the linux kernel from 4.18.0-1 to 4.18.0-2 I changed the timeout of pulseaudio.service to 5 minutes which allowed Pulseaudio sufficient time to start up correctly. I have pretty decent hardware though, so I would have expected the default timeout for Pulseaudio to be more than sufficient. It has been sufficient on this hardware until now. I'm not sure what's relevant for Pulseaudio, but my system uses the motherboard's onboard sound chip (Realtek ALC S1220A) on an AMD Ryzen system. I'm not sure why Pulseaudio is suddenly taking so much longer to start (or maybe systemd shortened the default timeout). But it's worth noting that for some reason I still had HDMI audio output, even with pulseaudio timed out. This is something that actually hadn't worked before and I haven't really tested it since the kernel with amdgpu dc has been available. Not sure if that's relevant. -- Package-specific info: File '/etc/default/pulseaudio' does not exist -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pulseaudio depends on: ii adduser 3.118 ii libasound2 1.1.6-1 ii libasound2-plugins 1.1.6-1+b1 ii libc62.27-6 ii libcap2 1:2.25-1.2 ii libdbus-1-3 1.12.10-1 ii libgcc1 1:8.2.0-7 ii libice6 2:1.0.9-2 ii libltdl7 2.4.6-4 ii liborc-0.4-0 1:0.4.28-3 ii libpulse012.2-2 ii libsm6 2:1.2.2-1+b3 ii libsndfile1 1.0.28-4 ii libsoxr0 0.1.2-3 ii libspeexdsp1 1.2~rc1.2-1+b2 ii libstdc++6 8.2.0-7 ii libsystemd0 239-10 ii libtdb1 1.3.16-1 ii libudev1 239-10 ii libwebrtc-audio-processing1 0.3-1 ii libx11-6 2:1.6.6-1 ii libx11-xcb1 2:1.6.6-1 ii libxcb1 1.13-3 ii libxtst6 2:1.2.3-1 ii lsb-base 9.20170808 ii pulseaudio-utils 12.2-2 Versions of packages pulseaudio recommends: ii dbus-user-session 1.12.10-1 ii libpam-systemd 239-10 ii rtkit 0.11-6 Versions of packages pulseaudio suggests: pn paman pn paprefs ii pavucontrol 3.0-4 pn pavumeter ii udev 239-10 -- Configuration Files: /etc/pulse/daemon.conf changed: ; daemonize = no ; fail = yes ; allow-module-loading = yes ; allow-exit = yes ; use-pid-file = yes ; system-instance = no ; local-server-type = user ; enable-shm = yes ; enable-memfd = yes ; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB ; lock-memory = no ; cpu-limit = no ; high-priority = yes ; nice-level = -11 ; realtime-scheduling = yes ; realtime-priority = 5 ; exit-idle-time = 20 ; scache-idle-time = 20 ; dl-search-path = (depends on architecture) ; load-default-script-file = yes ; default-script-file = /etc/pulse/default.pa ; log-target = auto ; log-level = notice ; log-meta = no ; log-time = no ; log-backtrace = 0 ; resample-method = speex-float-1 ; avoid-resampling = false ; enable-remixing = yes ; remixing-use-all-sink-channels = yes enable-lfe-remixing = yes lfe-crossover-freq = 120 flat-volumes = no ; rlimit-fsize = -1 ; rlimit-data = -1 ; rlimit-stack = -1 ; rlimit-core = -1 ; rlimit-as = -1 ; rlimit-rss = -1 ; rlimit-nproc = -1 ; rlimit-nofile = 256 ; rlimit-memlock = -1 ; rlimit-locks = -1 ; rlimit-sigpending = -1 ; rlimit-msgqueue = -1 ; rlimit-nice = 31 ; rlimit-rtprio = 9 ; rlimit-rttime = 20 ; default-sample-format = s16le ; default-sample-rate = 44100 ; alternate-sample-rate = 48000 default-sample-channels = 6 ; default-channel-map = front-left,front-right ; default-fragments = 4 ; default-fragment-size-msec = 25 ; enable-deferred-volume = yes ; deferred-volume-safety-margin-usec = 8000 ; deferred-volume-extra-delay-usec = 0 -- no debconf information # This file i
