Arch Linux

MickeyRat

Member

Registered: 2011-11-15

Posts: 128

[SOLVED] blueman-applet showing a conflict

I suspect I caused this problem.  Blueman-applet locked up for some reason.  It was showing a device that I turned off was connected and when I pulled up the devices screen, I could not select the device to disconnect.  I decided that I would just reboot to clear it.  It had been a couple days since I updated (I update 3 or 4 times a week.) so I decided to update the system before rebooting.  I don't think that the update is related to the problem but, it's possible.  Below I show that there is no blueman process running and what I get when I try to run blueman-applet:

[mickeyrat@groucho ~]$ ps -ef | grep blueman
mickeyr+    1011     896  0 11:46 pts/0    00:00:00 grep blueman

[mickeyrat@groucho ~]$ blueman-applet
blueman-applet version 2.1.3 starting
Stale PID, overwriting
blueman-applet 11.46.20 WARNING  PluginManager:147 __load_plugin: Not loading PPPSupport because its conflict has higher priority
blueman-tray version 2.1.3 starting
Stale PID, overwriting
blueman-tray version 2.1.3 starting
There is an instance already running
blueman-applet 11.46.20 WARNING  PluginManager:147 __load_plugin: Not loading DhcpClient because its conflict has higher priority

I suspect there's a file somewhere that is telling blueman-applet that bleuman-tray is running when it's not.  That said, there are some pulseaudio errors in the journal that may be related.  So, I'm posting them,

Nov 17 11:44:58 groucho systemd[1]: /etc/systemd/system/pulseaudio.service:6: Unknown key name 'Exec' in section 'Service', ignoring.
Nov 17 11:44:58 groucho systemd[1]: pulseaudio.service: Service has no ExecStart=, ExecStop=, or SuccessAction=. Refusing.
Nov 17 11:44:58 groucho systemd[1]: pulseaudio.service: Cannot add dependency job, ignoring: Unit pulseaudio.service has a bad unit file setting.

I have checked and the bluetooth daemon is running.  Thanks for any help.

Last edited by MickeyRat (2020-11-18 17:34:01)

---

Some cause happiness wherever they go; others whenever they go.
- Oscar Wilde

twelveeighty

Member

From: Alberta, Canada

Registered: 2011-09-04

Posts: 1,096

Re: [SOLVED] blueman-applet showing a conflict

How did you manage to have a system-wide /etc/systemd/system/pulseaudio.service? It should be a user-based /usr/lib/systemd/user/pulseaudio.service activated via socket.

Post the output of:

file /etc/systemd/system/pulseaudio.service
pacman -Qo /usr/lib/systemd/system/pulseaudio.service

MickeyRat

Member

Registered: 2011-11-15

Posts: 128

Re: [SOLVED] blueman-applet showing a conflict

Thanks for the reply.

How did you manage to have a system-wide /etc/systemd/system/pulseaudio.service? It should be a user-based /usr/lib/systemd/user/pulseaudio.service activated via socket.

What can I say? I'm a talented guy.  I think I did mean to run it as user based.  As I recall, I had some weird problems getting it set up with HDMI which is what I use when bluetooth isn't connected.   I probably accidentally left off the --user at some point when I was messing with that.  I disabled it at the system level and set it up at the user level and it now appears to be working.

Post the output of:

file /etc/systemd/system/pulseaudio.service
pacman -Qo /usr/lib/systemd/system/pulseaudio.service

I think this is moot now but, since you asked.

[mickeyrat@groucho ~]$ file /etc/systemd/system/pulseaudio.service
/etc/systemd/system/pulseaudio.service: ASCII text

[mickeyrat@groucho ~]$ pacman -Qo /usr/lib/systemd/system/pulseaudio.service
error: No package owns /usr/lib/systemd/system/pulseaudio.service

Blueman applet is still throwing the same error.

---

Some cause happiness wherever they go; others whenever they go.
- Oscar Wilde

MickeyRat

Member

Registered: 2011-11-15

Posts: 128

Re: [SOLVED] blueman-applet showing a conflict

When I posted my last post, I hadn't actually rebooted. I still have the error starting pulseaudio at the system level and I did disable it there.  Perhaps I need to start a new thread but, here's the system level unit file:

[Unit]
Description=PulseAudio system server

[Service]
Type=notify
Exec=pulseaudio --daemonize=no --system --realtime --log-target=journal

[Install]
WantedBy=multi-user.target

Pulse is not in /etc/systemd/system/multi-user.target.wants.  I'm beginning to wonder if that file should be there at all.

Last edited by MickeyRat (2020-11-17 23:44:02)

---

Some cause happiness wherever they go; others whenever they go.
- Oscar Wilde

qinohe

Member

From: Netherlands

Registered: 2012-06-20

Posts: 1,494

Re: [SOLVED] blueman-applet showing a conflict

[mickeyrat@groucho ~]$ pacman -Qo /usr/lib/systemd/system/pulseaudio.service
error: No package owns /usr/lib/systemd/system/pulseaudio.service

No it isn't. like twelveeighty said, it's a user service, the command is wrong too BTW, since it is a file..
The file is located at '/usr/lib/systemd/user/pulseaudio.service'

Pulse is not in /etc/systemd/system/multi-user.target.wants.  I'm beginning to wonder if that file should be there at all.

It shouldn't be there, that's right , it should be in your users systemd dir.;)

MickeyRat

Member

Registered: 2011-11-15

Posts: 128

Re: [SOLVED] blueman-applet showing a conflict

I could be wrong but, here's what I now think. I've been running pulseaudio as a user service all along.  However, somehow, probably through an inadvertent action on my part, /etc/systemd/system/pulseaudio.service was created and the WantedBy=multi-user.target in that file caused pulseaudio to attempt to start at the system wide level.  I renamed /etc/systemd/system/pulseaudio.service and rebooted. Pulseaudio did not try to start at the system level and is started at the user level pulseaudio and blueman-applet will start.  It does however still get the same error messages on start up that I noted in my original post. 

It's not really a problem at this point but, I'd be interested in knowing how to get rid of the error messages that are coming out of blueman-applet.  I'd also like to know if there's any reason not to get rid of the /etc/systemd/system/pulseaudio.service file that I renamed.

---

Some cause happiness wherever they go; others whenever they go.
- Oscar Wilde

qinohe

Member

From: Netherlands

Registered: 2012-06-20

Posts: 1,494

Re: [SOLVED] blueman-applet showing a conflict

...
I renamed /etc/systemd/system/pulseaudio.service
...
I'd also like to know if there's any reason not to get rid of the /etc/systemd/system/pulseaudio.service file that I renamed.

Why on earth would you want to do that? Systemd has a tool for that, 'systemctl' manage your services with it.
Stop and disable the 'old' root owned service. After that enable and start the user service, should be trivial;)

MickeyRat

Member

Registered: 2011-11-15

Posts: 128

Re: [SOLVED] blueman-applet showing a conflict

Why on earth would you want to do that? Systemd has a tool for that, 'systemctl' manage your services with it.
Stop and disable the 'old' root owned service. After that enable and start the user service, should be trivial;)

Very simple.  I had already stopped and disabled the pulseaudio service at the system level with systemctl and, on reboot, it was still attempting to start and failing.  At the same time, the user level service was starting and running normally.  That was causing blueman-applet not to start.  I'm fairly certain that the WantedBy=multi-user.target in the system level unit file is what was causing it to try to start so I renamed it to verify.  That worked.  So I know the unit file is what's causing the problem.  I don't know where the unit file came from or how it got there so I don't whether there's any reason to keep it around.  Things are working so now I have to decide what to do going forward.

I can either delete the unit file that I renamed or I can rename it back and remove the WantedBy line.  I haven't actually tried that but, it'll probably work.  I not certain which is the best course of action.

---

Some cause happiness wherever they go; others whenever they go.
- Oscar Wilde

qinohe

Member

From: Netherlands

Registered: 2012-06-20

Posts: 1,494

Re: [SOLVED] blueman-applet showing a conflict

I still think there's something off. You should disable all running pulseaudio root & user. After that polling it with systemctl (user&root) your status should be 'Unit pulseaudio.service could not be found.' Remember 'socket' can enable the service so stop and disable it first!
After that there should be nothing left in '/etc/systemd/ or in '$XDG_CONFIG_HOME/systemd/user' if there is remove it.
Enable & start your pulseaudio user service, now there should only be pulseaudio service/socket in '$XDG_CONFIG_HOME/systemd/user'
You may need to reboot but you don't need to tweak the service or socket, your music should play now.
After this blueman 'should' be back on track too and only be available if you start it by putting it's startup line(s) in the proper file!

edit:Before I get eaten alive  , the only thing that could be in '/etc/systemd'  is a symlink;

pulseaudio.socket -> /usr/lib/systemd/user/pulseaudio.socket

Last edited by qinohe (2020-11-18 15:30:18)

MickeyRat

Member

Registered: 2011-11-15

Posts: 128

Re: [SOLVED] blueman-applet showing a conflict

After all of this, I think I know what happened.  The unit file in /etc/systemd/system is not a symlink and it was created in December of 2018.  That's about when I set up this system and had all kinds of trouble getting HDMI audio to work.  I don't believe I ever had pulsesudio running system wide but, it's possible I put that file there at that time and forgot about it.  Since my last post I did try removing the WantedBy=multi-user.target in that unit file and when I rebooted, pulseaudio did not attempt to start at the system level.  That demonstrates that  the WantedBy=multi-user.target is the cause of the problem.  As part of the system update I performed, I suspect there was a change to systemd that caused it to pay attenttion to that WantedBy line when it didn't previously.

I actually had something similar happen on another (not Arch) system.  Among other things, that system uses NFS to provide network storage.  After an update there, a mountpoint that was set to noauto in /etc/fstab started mounting on boot.  The presence of that mountpoint in /etc/exports is what caused the disk to be mounted.  /etc/exports had not  been changed.

Things are running the way I want them now.   Pulseaudio is running at the user level and not at the system level.  The only change I intend to make is to delete that unit file in /etc/systemd/system. 

This looked like a newbie problem to me when I posted it but, it went in directions I really didn't expect.  You folks did zero in on the root cause of the issue.  So, thanks for your assistance.

---

Some cause happiness wherever they go; others whenever they go.
- Oscar Wilde