## PulseAudio Restart Bug – Solved

I enjoy my Linux computers, and one reason is the fact that many technical issues can be resolved, without having to reboot endlessly. However, in my past usage, there has been an irritating exception to this pattern. It’s common under Linux, that we can simply restart the PulseAudio Server from the command-line, using one out of several methods, and that the subject should be done with. But alas, every time I have ever restarted PulseAudio in this way, or, if the server restarted on its own, afterwards, when looking up the Plasma 5 -generated status display (which is actually referred to as “Phonon”), I’d be missing a Devices List, like so:

This type of display can be interpreted to mean several things, such as, that the PulseAudio server did restart, but that perhaps, it simply failed to connect to the inter-process, session-unique, message-bus. Therefore, in the past, whenever I had such a display, I eventually did what I thought I had to do, which was, to log out and back in again, or, to reboot. On my system, PulseAudio is configured such, that it runs as one user-name, and not as root.

In fact, a peculiar side effect of this bug was, that the list of available output devices was still being displayed, within ‘pavucontrol‘.

But this ordeal has now become even more inconvenient than it ever was because on the computer which I name ‘Phosphene’, the need may recur more frequently, ‘just to restart the PulseAudio server’.

However, I have finally found the true cause for this malfunction, which was, that when PulseAudio is restarted from within an existing session, it simply fails to load one module, which is also the module that it needs, in order to be able to list the available devices:

module-device-manager

In fact, there exists a script in ‘/usr/bin‘, that loads a series of X11-related modules.

Therefore, after a restart of this service, I can simply give the following command now:

/usr/bin/start-pulseaudio-x11

And Eureka! I can now obtain a list of available devices, without ever having to log out and back in, or, without ever having to reboot:

In fact, I have created a shell-script, which I can click on as user, and which carries out this task, safely.

I’ve also discovered that the ‘ProjectM’ music visualization application still works, and detects the beat of the playing music as before. What this means is that theoretically, after ‘ProjectM’ was installed, instead of rebooting, I could have just restarted the PulseAudio server as described here, to get that working.

( Edited 2019/10/29, 23h35 … )

I know that there exists an unrelated problem, that just happens to give the same appearance within ‘Phonon’, but that cannot be resolved in this way…

The behavior of Linux, after we have installed updates, is much better, in my opinion, that Windows behavior. Under Windows, virtually any system-wide update will require a reboot. But under Linux, often we can install library updates, without requiring this. However, there is some specific knowledge which users should have about this, which none of my Linux-using friends were actually able to reflect.

When we update a library, which is in-use by a running program, the old version of that library stays loaded in RAM and remains in use. The following is a Linux command, based on ‘lsof‘, which will report all the Processes still using libraries Deleted from the hard drive:

lsof | grep 'DEL.*lib' | cut -f 1 -d ' ' | sort -u

In order to minimize the consequences, Linux will generally compute the dependencies of updates, and restart services automatically if they are affected. However, this automatic restart of services will only take place for system-wide services, and not for services which run in user-land.

If the reader has a system service which has been configured to run under a system user-name, as opposed to a user-name belonging to a real user, then those will also get restarted automatically.

I.e., if I have received an update to my MySQL server, the globally-running MySQL server will also be restarted automatically, which actually runs as system user ‘mysql‘. But I know that ‘Akonadi‘, a PIM service running as user ‘dirk‘, runs its own, localized instance of a ‘mysqld‘ process, and that this instance will not be restarted.

Therefore, since I want my running processes up to date, and if all that was affected by the update was this running MySQL instance as user ‘dirk‘, one thing I can do is just log out my session and log back in again…

Further, if the update causes kernel-headers and kernel-images to be updated, my KDE desktop actually tells me that a restart is required… But the absence of any messages is not a better sign, under Linux, than my own knowledge is, of what I need to do. Under Linux, there could be no messages shown, just because there is no corresponding software installed, with the responsibility of showing me messages.

dirk@Phoenix:~$cd ~/tmp dirk@Phoenix:~/tmp$ find . | grep 'cat.s'
./cat.so
dirk@Phoenix:~/tmp$find . | grep 'cat*s' dirk@Phoenix:~/tmp$ find . | grep 'cat.*s'
./cat.so
dirk@Phoenix:~/tmp$find . | grep 'cats' dirk@Phoenix:~/tmp$ find . | grep 'ca.*t'
./ca.crt
./cat.so
dirk@Phoenix:~/tmp$find . | grep 'ca.*t.s' ./cat.so dirk@Phoenix:~/tmp$

lsof‘ does stand for ‘List Open Files’. But what they forgot to mention in my Comp-Sci Courses as well, is that ‘Open Files’ can include ‘Files Deleted by Other Processes’. The file handle is only closed, when the process that opened it, closes it.  And, .SO Files loaded as dependencies also seem to have handles, as portrayed by the kernel…

When deleted, their handles go into a failed state but continue to exist, which is necessary, because otherwise, the process would have no way to query the kernel, about what happened to the file. Because handles are only numbers – the use of which date back to the beginnings of Computing – code needs to rely on this number always referring to the same object, even without receiving any notifications of external events that could affect the object. It must keep its meaning, until the process dismisses it.