unable to suspend after upgrade to Karmic (/usr/bin/pacmd)

I had same on my box after upgraded to karmic.

the fix is to remove/purge pm-utils and reinstall it. specificaly, i did this and it helped:

$ sudo aptitude purge pm-utils

it will complain that it needs to remove acpi-support. i accept it.

then i also removed remaining scripts in pm-utils directory:

$ sudo rm -rf /usr/lib/pm-utils/*

and then reinstall acpi-support which will install also pm-utils:

$ sudo aptitude install acpi-support

now it works like charm.
i have no idea what was the problem. didn't backed up the scripts dir or something, so i don't know the diff. if somebody with the same will try the above, backup first /usr/lib/pm-utils/* and when reinstalled make a diff. then post the diff here...

SOLVED FOR ME: short version: edit /etc/pam.d/* and remove '@include common-pammount' lines from all files. pammount will STILL WORK - the line is no longer required, and breaks things.
This might not work for you.

Long version:

Similar problem here, except pm-suspend.log shows a segfault when suspending PA:

/usr/lib/pm-utils/sleep.d/01PulseAudio suspend suspend: Segmentation fault
Segmentation fault
Segmentation fault
Returned exit code 139.
Tue Jan 19 14:28:33 EST 2010: Inhibit found, will not perform suspend

I've purged pm-utils, removed everything in /usr/lib/pm-utils, and reinstalled acpi-support (and thus pm-utils). There are some things missing, such as /usr/lib/pm-utils/sleep.d/01PulseAudio and others in the same dir - that's because they're installed by those OTHER packages, and they're probably required.

But sure enough, removing 01PulseAudio "fixes" suspending, putting it back breaks it again.

Tracing the problem down, it's quite simple: as root, i can't sudo as myself!. I checked all the local users:
root@quark:/var/log# for u in $(</etc/passwd awk -F : '{print $1; }'); do sudo -u $u ls >/dev/null || echo $u; done
Erreur de segmentation
esj

I'm the only user root can't sudo to. I don't know why. /home is on an encrypted partition but that also homes other users.

So i traced it further down: i'm also the only user with a pammount hook to make sure /home is decrypted. If i disable /etc/pam.d/common-pammount i can suspend at will (and root can sudo to me).

Well it turns out that since libpam-mount upstream 1.27, you shouldn't have the @include common-pammount line in your /etc/pam.d/* files. If you've setup any type of automounting volumes (not just encrypted) before, relying on pammount, then you'd have those lines, and that will break sudo, and that will break pulseaudio suspend, and that will break your system's suspend.

I removed the line. Automount of /home when i login still works fine. Suspend now works fine.
w00t.

Is there anything that should be done in this package to prevent this from happening?

Not really. It was already documented in the NEWS.Debian for the version of libpam-mount in karmic that you should not be including /etc/pam.d/common-pammount anymore. libpam-mount can't edit this config file automatically on upgrade (and didn't add it automatically in the first place, either).

after last update on karmic, this bug is back.

and i don't even have /etc/pam.d/common-pammount

yes, w00t?

Nova deViator,

Is the error message exactly the same as before?

Can you run this command as root from the command line, and paste the full output?:
# sudo -H -u random pacmd list-sinks

This is at least partly a bug in pulseaudio for using sudo (it should be using 'su' instead), but we should also figure out why libpam-mount is breaking sudo.

Steve,
yes the message is exactly as before:

/usr/lib/pm-utils/sleep.d/01PulseAudio suspend suspend: Sorry, user root is not allowed to execute '/usr/bin/pacmd' as random on wonko.
Sorry, user root is not allowed to execute '/usr/bin/pacmd' as random on wonko.
Returned exit code 1.
Thu Jan 28 18:15:46 CET 2010: Inhibit found, will not perform suspend

if i remove 01PulseAudio, suspend works.
but then it seems there's a problem with firefox(flash) loosing audio after resume.

running
root@wonko:/home/random# sudo -H -u random pacmd list-sinks
Sorry, user random is not allowed to execute '/usr/bin/pacmd list-sinks' as random on wonko.

l.

Please attach the contents of /etc/pam.d/sudo, /etc/pam.d/common-auth, and /etc/security/pam_mount.conf.xml.

/etc/pam.d/common-auth

/etc/security/pam_mount.conf.xml doesn't exist.

Do you have the libpam-mount package installed? Maybe the report that /etc/pam.d/common-pammount fixes it was a red herring - you don't have any mention of pam_mount in /etc/pam.d/common-auth, either. The other explanation is simply that sudo is not configured to allow root to use it. Can you post your /etc/sudoers?

my /etc/sudoers

sorry, here's the attached sudoers,

This file differs from the stock Ubuntu sudoers on a key point. You have:

root ALL=NOPASSWD: ALL

where the Ubuntu default has:

root ALL=(ALL) ALL

The difference is that you've dropped the '(ALL)' Runas_Spec. As the
manpage says,

        If no Runas_Spec is specified the command may be run as root and
        no group may be specified.

So, in fact, you have configured sudo to not allow root to run commands as other users, which is precisely the error message you're given. Nothing to do with libpam-mount at all; re-closing that task as invalid.

Now, it's valid to configure sudo not to allow root to use it, and it's a bug in pulseaudio to require sudo to work; but this is such an unlikely configuration that I don't think this warrants fixing for karmic. I recommend you add the missing '(ALL)' back to your sudoers instead, which will fix the problem for you.

Yes,
this completely fixes the problem.
Now it appears an edit of /etc/sudoers has caused all these trouble. My own configuration.
My appologies.
Anyway, it might still be helpfull to know not to mess with /etc/sudoers

Thank you for your time, I appreciate the community effort.

This bug was fixed in the package pulseaudio - 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu2

---------------
pulseaudio (1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu2) lucid; urgency=low

  * debian/01PulseAudio: Use su(1) instead of sudo(8)
    (LP: #489144, #498980).
  * debian/patches/series: To trim the startup time, don't lazy-load
    sounds by not applying 0005-load-sample-dir-lazy.patch.
  * 0091-dont-load-cork-music-on-phone.patch: Refresh.
  * 0057-load-module-x11-bell.patch: Don't explicitly load the daemon
    since it will autospawn if necessary, and if the system or user
    configuration has autospawn disabled it breaks that semantics
    (LP: #513120).
 -- Daniel T Chen <email address hidden> Fri, 29 Jan 2010 14:37:52 -0500

I was having the exact same issue described here, but my solution was not quite the same so I thought I would add my comments.

After upgrading to 9.10 my suspend stopped working. Looking in the logs pointed the finger at Pulse Audio and removing the pulseaudio package fixed the problem as others noted. I finally decided to look for a proper fix and found this thread, which described my exact setup and issue (encrypted home directory, pusleaudio failing on suspend).

I confirmed that I had the same issue of sudo getting a Segmentation Fault when it was executed in the /usr/lib/pm-utils/sleep.d/01PulseAudio file, exactly as described above. I saw the confirmed fix of changing the /etc/sudoers file and thought 'Great, this should fix my problem.' However, my sudoers file had not been altered at all so no luck.

I went back to the comments about /etc/pam.d/common-*' and removing the line @include common-pammount' which was thought to be a red herring. I commented out the include line in the file /etc/pam.d/common-auth and tested sudo again and it worked! I confirmed that the sudo lines from 01PusleAudio will Seg Fault when this line is included and work when it is not. (sudo -H -u \#$i pacmd) i.e. when root tries to sudo to me. Suspend worked fine after that.

So, to summarize my fix: Comment out the line '@include common-parmmount' from the file /etc/pam.d/common-auth.

I know Pulse Audio has already been changed to use su instead of sudo, but there are two questions that still seem to remain: 1. Why does sudo seg fault at all when I assume it did not in the previous version of Ubuntu (my suspend worked fine before the upgrade)? 2. Should these include lines be removed since they seem to no longer be needed and actually do cause errors. Patching Pulse Audio might just gloss over the problem until is shows up somewhere else.

/etc/pam.d/common-pammount was a red herring for the bug submitter, who was not seeing a segfault.

For others who saw a segfault, having pam_mount called twice in the stack could account for this behavior, which I believe is what will happen if you've left references to /etc/pam.d/common-pammount in the config. Yes, you are supposed to remove these lines on upgrade, which is precisely what the NEWS file advises you to do.

Thanks Steve. I see now where you mentioned the NEWS file above. Sorry I missed it before.