Bug 26207

Summary: pulseaudio doesn't start at login (Plasma desktop) for a session or user carried forward from Mageia 6
Product: Mageia Reporter: Stephen Usher <steve>
Component: RPM PackagesAssignee: All Packagers <pkg-bugs>
Status: RESOLVED WORKSFORME QA Contact:
Severity: normal    
Priority: Normal CC: geiger.david68210, marja11
Version: 7   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Source RPM: pulseaudio-12.2-5.mga7 CVE:
Status comment:

Description Stephen Usher 2020-02-17 13:25:04 CET
Description of problem:

The Pulseaudio process doesn't start at login for a user created pre-mga7.

Version-Release number of selected component (if applicable):

12.2-5.mga7

How reproducible:

Consistent.

Steps to Reproduce:
1. Log in with a session saved before mga7.
2.
3.
Comment 1 Lewis Smith 2020-02-18 21:36:06 CET
Is this after an upgrade from Mageia 6 to 7?

You say two different circumstances; or are they the same expressed in different ways? The idea of doing an upgrade across a saved session seems optimistic in the extreme:
> Pulseaudio process doesn't start at login for a user created pre-mga7
> Log in with a session saved before mga7
both presumed Plasma. Of course, on a correct system PulseAudio does start automatically:
 $ ps -ax | grep pulseaudio
 17583 ?        S<sl   0:00 /usr/bin/pulseaudio --daemonize=no

Can you do:
 $ ls /etc/xdg/autostart/pulseaudio.desktop
to see if that file is present. Doing:
 $ grep -r  pulseaudio /etc/* 2>/dev/null
shows pulseaudio mentioned in many places. Please post that O/P here.

'PulseAudio Preferences' from menu seems to have no bearing; MCC-System-Manage Services does not include it.

Summary: pulseaudio doesn't start at login (Plasma desktop) => pulseaudio doesn't start at login (Plasma desktop) for a session or user carried forward from Mageia 6
CC: (none) => lewyssmith

Comment 2 Stephen Usher 2020-02-19 13:24:03 CET
In this bug report it's that the pulseaudio daemon isn't started at login (Plasma). I can start it later from the command line using "pulseaudio --start" however.

"ls /etc/xdg/autostart/pulseaudio.desktop" shows that it exists:

% ls -l /etc/xdg/autostart/pulseaudio.desktop
-rw-r--r-- 1 root root 4973 Mar  3  2019 /etc/xdg/autostart/pulseaudio.desktop

[root@vanguard ~]# grep -r  pulseaudio /etc/*
/etc/libvirt/qemu.conf:# QEMU audio output since directly talking to alsa/pulseaudio may not work
/etc/netprofile/profiles/default/urpmi/var/lib/urpmi/names.Main media:pulseaudio-module-gconf
/etc/netprofile/profiles/default/urpmi/var/lib/urpmi/names.Main media:lib64pulseaudio-devel
/etc/netprofile/profiles/default/urpmi/var/lib/urpmi/names.Main media:pulseaudio-esound-compat
/etc/netprofile/profiles/default/urpmi/var/lib/urpmi/names.Main media:lib64pulseaudio0
/etc/netprofile/profiles/default/urpmi/var/lib/urpmi/names.Main media:pulseaudio-module-zeroconf
/etc/netprofile/profiles/default/urpmi/var/lib/urpmi/names.Main media:task-pulseaudio
/etc/netprofile/profiles/default/urpmi/var/lib/urpmi/names.Main media:pulseaudio
/etc/netprofile/profiles/default/urpmi/var/lib/urpmi/names.Main media:lib64alsa-plugins-pulseaudio
/etc/netprofile/profiles/default/urpmi/var/lib/urpmi/names.Main media:pulseaudio-client-config
/etc/netprofile/profiles/default/urpmi/var/lib/urpmi/names.Main media:pulseaudio-utils
/etc/netprofile/profiles/default/urpmi/var/lib/urpmi/names.Main media:pulseaudio-module-x11
/etc/netprofile/profiles/default/urpmi/etc/urpmi/prefer.vendor.list:pulseaudio-esound-compat
/etc/pulse/default.pa:#!/usr/bin/pulseaudio -nF
/etc/pulse/client.conf:; daemon-binary = /usr/bin/pulseaudio
/etc/pulse/system.pa:#!/usr/bin/pulseaudio -nF
/etc/services:#pulseaudio is not registered in IANA
/etc/services:pulseaudio      4713/tcp                # Pulseaudio
/etc/sysconfig/pulseaudio:#   personal  Start a personal pulseaudio server per-user (recommended)
/etc/urpmi/prefer.vendor.list:pulseaudio-esound-compat
/etc/X11/xinit.d/50pulseaudio:if [ -f /etc/sysconfig/pulseaudio ]; then
/etc/X11/xinit.d/50pulseaudio:  . /etc/sysconfig/pulseaudio
/etc/X11/xinit.d/50pulseaudio:                  /usr/bin/start-pulseaudio-x11
/etc/X11/xinit.d/50pulseaudio:# sometimes for some reason start-pulseaudio-x11 fails, while pulseaudio --start just works
/etc/X11/xinit.d/50pulseaudio:                  PULSEPID=$(pidof pulseaudio)
/etc/X11/xinit.d/50pulseaudio:                          /usr/bin/pulseaudio --start
/etc/xdg/autostart/pulseaudio.desktop:Exec=start-pulseaudio-x11
Comment 3 Lewis Smith 2020-02-19 21:06:52 CET
> The Pulseaudio process doesn't start at login for a user created pre-mga7
This implies a difference in home directories, guessing in .bash_profile or .bashrc, although I can see nothing relevant in these files; nor find any reference to pulseaudio in $HOME.

Assuming you have users pre & post M7, after boot, at the first login screen, login as the *pre*M7 user, and do from a terminal:
 $ ps -ax | grep pulseaudio
which should (according to the bug) show it *not* running. Logout.
Login as the *post*M7 user, and do the same; which should show it running.
Just to illustrate the key point.
One would expect pulseaudio to be system-wide, not tied to a login. But...

Some man page extracts:
--start
              Start PulseAudio if it is not running yet. This is  different
              from  starting PulseAudio without --start which would fail if
              PA is already running. PulseAudio is guaranteed to  be  fully
              initialized when this call returns. Implies --daemonize.
-D | --daemonize[=BOOL]
              Daemonize after startup, i.e. detach from the terminal.  Note
              that  when running as a systemd service you should use --dae‐
              monize=no for systemd notification to work.
which explains my 'ps' output:
 6138 ?        S<sl   0:00 /usr/bin/pulseaudio --daemonize=no

Another look. The bug relates nominally to Plasma. If you have any different desktop available (there usually is one), can you try - fresh from booting - the pre & post M7 logins suggested above to that other desktop, 'ps' from a terminal. Tedious, apologies. This is to test whether the bug is desktop related before assigning it.
Comment 4 Stephen Usher 2020-02-20 10:40:03 CET
I have no-non-system accounts on the machine as it's fully networked and all user information is supplied by NIS and all home directories are automounted (with root not having access for security and legal reasons, e.g. GDPR). The majority run /bin/tcsh as their shell and not bash and are set up so that they work on many different operating systems.

However, I can clear out the .config, .kde, .gconf, .gconfd, .pulseaudio and .local directories on one test account though and try that and get back to you.

There are no pulseaudio processes running when I log in (account has been operational since 1992!).
Comment 5 Stephen Usher 2020-02-20 10:53:26 CET
I can confirm that after clearing out the user's configuration directories that pulseaudio doesn't start. Could this be something to do with my other bug report about pulseaudio not having permission to access /dev/snd? (In that case I can start pulseaudio with 'pulseaudio --start' but it only gives a dummy device.)
Comment 6 Lewis Smith 2020-02-20 20:23:47 CET
Thank you for the tests. I have no further ideas.
See also bug 26208, 26209.
Assigning globally, CC DavidG as main committer for 'pulseaudio'.

Assignee: bugsquad => pkg-bugs
CC: lewyssmith => geiger.david68210

Comment 7 Stephen Usher 2020-09-25 16:32:00 CEST
I've found the issue with pulseaudio not starting:

/etc/pam.d/sddm-greeter has pam_systemd.so as optional. If you make it required then it works.
Comment 8 Aurelien Oudelet 2021-07-06 13:17:45 CEST
Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.
Comment 9 Stephen Usher 2021-07-06 15:34:52 CEST
This issue was solved by running nscd if using network authentication as changes in systemd meant that non-local authentication wasn't able to get the correct privileges.
Comment 10 Marja Van Waes 2021-09-06 22:53:06 CEST
(In reply to Stephen Usher from comment #9)
> This issue was solved by running nscd if using network authentication as
> changes in systemd meant that non-local authentication wasn't able to get
> the correct privileges.

Thanks, closing

CC: (none) => marja11
Status: NEW => RESOLVED
Resolution: (none) => WORKSFORME