So you are saying that systemd user services don’t work under XFCE? I thought pipewire was running as a systemd user service?
What is the output of systemctl --user status pipewire.service on your system? Does it show it as enabled and running?
Yes, but we are going in circles. In running mode everything works but when I put the same thing in a unit it does not. That’s why I searched for other solutions and came across the above mentioned problem. I don’t believe if Systemd is blocked that I will outsmart it with a Unit. Poettering is not that stupid.
So I plan to ask in the XFCE forum how it is.
I have the assumption that it is still at LightDM and/or GTK3 and the porting is not yet completely gone through. In the very first mentioned thread in the XFCE forum was spoken of a patch. I have not checked for execution or fixed!
Here your query:
~> systemctl --user status pipewire.service
○ pipewire.service - PipeWire Multimedia Service
Loaded: loaded (/usr/lib/systemd/user/pipewire.service; disabled; vendor preset: disabled)
Active: inactive (dead)
TriggeredBy: ● pipewire.socket
I understand that the script (sh -c 'play ...') works properly. I’m just not sure that the unit is defined properly. Actually, I just noticed a problem with the ExecStop=... line in your service definition. Systemd services require that the full path to the executable be specified on the Exec lines. So ExecStart=/bin/true is right. But ExecStop=sh ... needs to be ExecStop=/bin/sh ....
There are other things that can be different between running things on the command line and running them in a service unit as well. A big gotcha is that the selinux context is different and selinux may block things from running when run from a service file that it does not when run from the command line. But it isn’t a bug in the service manager. The developers just expect that people who are writing systemd service units should know what selinux context things are supposed to be in.
P.S. Another thing you might try just to debug that your service unit is starting and stopping when you expect is to temporarily substitute something like ExecStop=/bin/date >> /tmp/it-ran.txt.
That is probably the best next step. I don’t know how user services are supposed to work in XFCE.
I’m not going to give up that easily. We’ll get the baby rocked yet. Smile. 
I still have to work the rest of the week, but I’ll be in touch by the weekend at the latest.
I’ll have another look at Units and maybe ask XFCE what the state of affairs is. Just to make sure. So no deliberate crossposting.
I’m just wondering that the propagated solution doesn’t work so something has changed again. The main task here is in Fedora to find a solution to release it. So just sleep on it and then maybe.
Trying to do this sort of thing and going down all the rabbit holes is also how people tend to learn a lot of things in Linux. I wouldn’t consider trying to work out this sort of puzzle a waste of time at all because the skills and knowledge you gain in the process can end up being quite useful in the workplace. So end in the end, you get the award of having solved the puzzle and you gain potentially valuable knowledge for survival in this ever increasingly technical world! 
Just try not to get discouraged as I know some tend to do.
1 Like
pipewire.service is socket activated, thus it is starter when and if something needs the service. Check pipewire.socket.
This is the same fore any display environment. All the sytemd --user services works pretty much independent of xfce. xfce itself only starts the program listed in /etc/xdg/autostart, which is the old pre-systemd way of auto-starting aps in a gui session.
As pipewire is run as part of a user session, it will not be available from outside that user session.
Well, my pipewire.service showed that it had been running continuously the whole 7 hours that I had been logged in (output was in previous post). But yeah, it would be better to confirm the pipewire.socket is (or isn’t) running. Perhaps even better yet would be to just run systemctl --user status and see if any user services are running under XFCE.
Which just mean that in got triggered by pipewire.socket, as it says when running systemctl --user status pipewire.service. On my xfce the trigger comes from running the xfce4-pulseaudio-plugin program in the system tray.
Oh, so you use xfce and know for a fact that user services do run then. From your response, it sounds like it might be common for pipewire not to be running after a user has logged in on xfce. If that is the case, that might be why he doesn’t get any sound when he logs out – the pipewire service isn’t (was never) running and his shutdown service wouldn’t trigger it on shutdown. (I wonder if socket activation would be blocked at that point?) Maybe adding Requires=pipewire.service to his service unit would cause pipewire to start when he logs on? But would it still be running when he logs out?
Which would only work if the service is --user service because pipewire.service itself is a --user service.
You should be able to check if the sound is working by manually stopping your service.
If it plays when manually stop the service then it is likely the timing of when it is trying to play during the shutdown sequence.
I ask for postponement because I have to coordinate a few people in my real life and find solutions to problems for new construction sites including acquisition.
I am still on it!
1 Like