In my case the LUKS stuff was unrelated and I was experiencing shutdown
hangs because I had daemonizing processes started by /etc/rc.local:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1656237
I managed to discover that by pre-killing a bunch of processes before
shutting down, which
Public bug reported:
If an autossh process is started by /etc/rc.local, a xenial system is no
longer able to shut down. It seems to hang forever, not just for a few
minutes.
Repro steps:
As root:
# Set up an autossh tunnel (in this example, from localhost to localhost):
apt-get install
It works fine with the new test package in your PPA. I ran an SSH login
flood for 10 minutes and didn't see systemd-logind fall over. I then
purged the PPA and confirmed it was still broken without the test
package (it dies after about 2 minutes / 5000 logins).
--
You received this bug
I don't think there's any change with the dbus from
https://launchpad.net/~sil2100/+archive/ubuntu/ppa. I tried it twice
(across reboots) and systemd-logind still breaks after a few minutes of
flooding the system with SSH logins.
`loginctl list-sessions` also still seems to grow without cleaning
Some hints for using Ubuntu 16.04 machines that can't be rebooted to
work around this bug:
1) You can keep your SSH logins a secret from systemd-logind by adding
`UsePAM no` to /etc/ssh/sshd_config; this will avoid the ~25 second
delay.
2) `UsePAM no` requires unlocked accounts (passwd -u) with
https://github.com/netblue30/firejail/issues/69
** Summary changed:
- pulseaudio 8.0 drops connections after using foobar2000
+ pulseaudio 8.0 drops connections after playing audio in a firejail
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
Oh, duh, this happens only because I have wine running in firejail. Not
sure why pulseaudio 8 decides to break so spectacularly in this
scenario, though.
I think this can be closed. I'll file a better bug upstream if this
warrants a bug.
--
You received this bug notification because you are a
Attaching a pulseaudio log wherein foobar2000 1.3.9/wine-staging somehow
breaks pulseaudio 8, even though foobar2000 never has problems playing
through it, even after restarting foobar2000.
** Attachment added: "pulseverbose.log"
> Are there any files in /dev/shm related to pulseaudio and your user?
They should be owned by your user, even though your user ID or name is
not in the file names.
The /dev/shm/pulse-shm-* files seem to be removed immediately after
foobar2000 starts playing music. (Not when wine-staging is
I think I have narrowed this down: pulseaudio 8 goes into its degraded
connection-dropping state after playing some audio in foobar2000 in
wine-staging 1.9.8. I will try to make this fully reproducible.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
After it goes into a bad state, connections from Chrome also die
immediately:
(2264.888| 0.801) I: [pulseaudio] client.c: Created 208 "Native client (UNIX
socket client)"
(2264.888| 0.000) I: [pulseaudio] client.c: Freed 208 "Native client (UNIX
socket client)"
(2264.888| 0.000) I:
I have no idea what's going on now: pulseaudio doesn't actually hang and
keeps playing audio, but pavucontrol fails to connect.
# pavucontrol
shm_open() failed: No such file or directory
shm_open() failed: No such file or directory
shm_open() failed: No such file or directory
shm_open()
Thanks, I am now logging and will hopefully see a hang.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1572493
Title:
pulseaudio 8.0 server frequently hangs
Status in
Public bug reported:
After upgrading from Ubuntu 15.10 to 16.04 (pulseaudio 6 -> 8), I notice
that my audio output stops working every few hours. When this happens,
if I run pavucontrol, it seems to wait forever trying to connect to
pulseaudio. Killing pulseaudio and starting it again fixes the
14 matches
Mail list logo
