You are not logged in.
Is there a reason why no one so far has a solution for a sysvinit script? Have there been attempts? And if so, what were the pitfalls?
Offline
Isn't pipwire something to be run by the (local desktop) user?
Offline
As steve_v already mentioned, no.
If Devuan is going to transition to pipewire following upstream Debian, we're going to need a better answer than "user finds random script / autostart / .xinitrc hints on the 'net" for starting and stopping its services.
IMO some kind of process supervisor (be it part of an init system or standalone) is the only realistic (and reliable) option, and I already mentioned one possibility. Another might be adapting supervise-daemon or runits runsvdir, or running dinit in a user-session context.
The pipewire package ships with a .service file for systemd[1]. And if PW is meant as replacement for pulseaudio it should be a systemwide daemon as well.
I have searched how other distros deal with that but so far I've only found a set of scripts for MX-Linux[2][3]. But AFAICS they try to cover both usecases (systemd OR sysvinit) which seems overkill for Devuan. I never had to create an init-script, is it really that complicated?
[1] https://packages.debian.org/bookworm/am … e/filelist
[2] https://github.com/MX-Linux/pipewire-setup-mx
[3] https://github.com/MX-Linux/pipewire-se … e/main/bin
Offline
Is there a reason why no one so far has a solution for a sysvinit script? Have there been attempts? And if so, what were the pitfalls?
This project has been around for years: https://www.chiark.greenend.org.uk/pipe … diversity/ Surprised you are not aware of it. Or perhaps that isn't the answer to the question you are asking . . .
Online
Is there a reason why no one so far has a solution for a sysvinit script?
...
is it really that complicated?
Because sysvinit doesn't have any notion of user daemons, so in this case it's not even "complicated", it's completely out-of-scope of what sysvinit is designed to do.
The "why someone not just write init script" comments (not only WRT pipewire) are getting rather tiresome. If it's so easy, go be that someone.
Isn't pipwire something to be run by the (local desktop) user?
Mostly. Pipewire is meant to be run per-user, with user permissions, in the background like a daemon... But it doesn't behave like a daemon (background/forking, rerdirecting stdout/logs etc.) or manage its own service dependencies, because systemd user units exist.
IOW, it's meant to be managed by systemd on behalf of the user.
steve_v already mentioned
...Nothing whatsoever about running pipewire as a single, system-wide service. I mentioned the need for some kind of process supervision, and gave examples that can do this per-user.
The pipewire package ships with a .service file for systemd[1]. And if PW is meant as replacement for pulseaudio it should be a systemwide daemon as well.
Pipewire ships a user .service, that is service(s) which are started (in the correct order) by systemd for each user login (with permissions for e.g. audio devices from the login/seat manager), are restarted by systemd if they die, and are terminated by systemd at user logout.
It is possible to run pipewire system-wide (i.e. as root), but that's not how it's intended to be used and causes another set of problems.
so far I've only found a set of scripts for MX-Linux
Which as you will note do not include a system-wide sysvinit script, rather the usual bunch of shell hackery called per-user from xdg-autostart.
This is what pretty much every non-systemd distro is doing currently (see also e.g. gentoo), and quite frankly, it sucks.
OpenRC now has (experimental) user services as of 0.60, and I expect that once it gets a bit of testing that's the way Gentoo will go. What we really need is comparable capability in Devuan.
perhaps that isn't the answer to the question you are asking
It isn't, because for pipewire a system-wide sysvinit script isn't the right answer. To work as intended it really needs to run per-user with user permissions and (e)logind integration.
Nor will it be the right answer when bigger things (like whole desktop environments) start letting their native session managers rot in favour of shipping a bunch of systemd user units.
This isn't going to go away, so which solution do we want?
* Extend sysvinit.
* Switch to an init system that isn't quite so crusty.
* Adopt something else to manage user daemons, such as the examples I mentioned earlier.
* Maintain fragile semi-functional shell hacks for each package that needs this, and deal with the inevitable bugs/jank as they arise.
* Bury our heads in the sand, and let the users figure it out. *status quo*
Last edited by steve_v (Yesterday 22:45:29)
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Offline
There are numerous of ways to run programs, including to run programs that keeps other programs running. If a person wants their machine to do that then they would set it up to do so. Or are we working on a premise that end users are stupid, or that end users should be controlled (by owner-administrator-vendor)?
Offline
Right... So the "bury head in sand" approach then.
There's a world of difference between giving users the freedom to do what they want, and shipping a core desktop component without an even remotely convenient way to start it, or any official guidance wrt setting that up yourself.
End users should be competent enough to follow instructions, but expecting them to grub through a forum thread and select between 10 different user-contributed options (most of which either don't work reliably and/or require out-of-repo software) to get a sound-server started is ridiculous.
Have you tried the pipewire-started-with-shell-hacks approach where multi-seat is involved? More than one concurrent user? Checked that a bunch of orphan processes aren't blocking the audio devices after a user logs out?
The current "IDGAS about this, user runs program how they want" simply does not work reliably. It will continue to not work reliably until we take an official position on the whole user services thing and start working on a robust solution.
The only reason we're getting a pass on this right now is because we're not shipping wayland-as-default right now. When that becomes necessary (and it will, sooner or later), pipewire also becomes necessary - not just for audio, but also for mundane tasks like taking a screenshot.
IOW, if Devuan has any intention of shipping with a KDE, GNOME, or wayland-in-general environment that works out of the box, it also needs a pipewire configuration that works out of the box...
Or we could keep ignoring the rest of the world, drop compatibility with major upstreams every time a challenge arises, and slide further into obscurity.
I was under the impression Devuan was "Debian without systemd", not "Debian like it's 1999, where large swathes of current software won't work properly and users have to spend hours on message boards to get working sound"... Perhaps I was mistaken?
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Offline
Or are we working on a premise that end users are stupid, or that end users should be controlled (by owner-administrator-vendor)?
Well it would be nice if the assumptions was we have clearly provided the user with the information needed to get it done. If they do not wish to avail themselves to using it, sorry about their luck. That includes those too god damn lazy to read the install notes that point out what is needed.
Offline
That includes those too god damn lazy to read the install notes that point out what is needed.
Feel free to point out the section in the release notes, wiki, manual page, or any other documentation that mentions running pipewire on Devuan, any time you like...
I mean pipewire has only been around for 7 years now, surely distibution developers aren't still neglecting any kind of sane default configuration and leaving their users totally in the dark with how to use it, right?
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Offline
Thank you steve_v for bringing light to the whole situation and my totally wrong assumptions. I had no idea this would be such a rabbit hole when I started looking into PW yesterday.
It was not the first time that users on IRC asked and talked about PW. So I thought I'll try it for myself and maybe then be able to share my experience on the wiki. Now I realize, once again, I went way over my head. Funny how all this automagic userfriendlyness created just another hell.
Last edited by debdog (Today 03:18:14)
Offline
Greenjeans<<using nothing but ALSA and eating popcorn watching people fret over PW and PA while I listen to music.
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded April 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do. Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
Funny how all this automagic userfriendlyness created just another hell.
The pipewire situation has little to do with "userfriendlyness", and much to do with it being rapidly adopted as a standard media server (audio and video) in major desktop environments. If you run wayland and want to do screen capture you'll need it, because wayland lacks the facilities we used for this on X11, by design.
That pipewire uses systemd for startup is not at all surprising, since there exists no other widely accepted way to handle multiple, order-dependent user daemons in a reliable fashion.
We should have had user daemons a long time ago. Not necessarily the way systemd does it, but there's got to be a better answer than a mess of shell scripts, cron jobs, .xinitrc, .profile, autostart links that some environments use and others don't, and major DEs doing their own thing with "service manager"s like kded.
For all its flaws, this is a problem systemd neatly solves. Upstreams have already started using it for clean startup/shutdown of user daemons, more are sure to follow. Pipewire is just a canary for a more general problem.
Either we decide on a general solution, or we get to deal with more of the inevitable upstream code-rot, deprecation, and special-case workarounds we're already seeing with e.g. the vanishing sysv init scripts for system services.
using nothing but ALSA and eating popcorn watching people fret over PW and PA while I listen to music.
Cool. Now stream your wayland desktop to a smart TV over wifi, and switch audio output to it without interrupting playback. Yes, that's something people do, and it's not unreasonable to expect such capability to work out-of-the-box on a current GNU/Linux distribution.
Hell, just try switching playback to some bluetooth headphones and back smoothly. That's a thing that most users have expected to "just work" for a decade now.
I too use pure ALSA, where it's appropriate. A modern desktop is not that, let alone a portable device with wireless audio peripherals, A/V over USB-C, etc. etc.
Last edited by steve_v (Today 04:58:10)
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Offline
Sorry for triggering you there. I didn't meant PW is the hell but the situation we have now.
Last edited by debdog (Today 05:49:29)
Offline
@steve_v: in my mind neither Devuan nor Debian are "distributions". Rather we are organisations of people that provide a means to pull toghether a large number of software packages, that are tested to work together. A "Distribution" is formed by selecting certain packages towards some particular use. So where software implementing a notion of user services exist Devuan will incorporate that if it is in Debian, except of course if it requires systemd.
Offline
in my mind neither Devuan nor Debian are "distributions".
Debian certainly is a distribution, it damn-near invented the term... Devuan I'm really not sure about any more, seems to me it's less an active project and more "crippled Debian for people who like to complain but refuse to come out from under their rocks to proactively solve problems".
Maybe time to drop the Debian references and rebrand to "mostly-working XFCE live for ancient recycled laptops"?
where software implementing a notion of user services exist Devuan will incorporate that if it is in Debian, except of course if it requires systemd
Nice, that's a perfect way to say "we'll just go minimum-effort and copy Debian, unless Debian uses systemd (which they will), in which case we'll do nothing and it'll stay broken", without explicitly stating the "minimum effort", "do nothing", and "stay broken" parts.
Here's the unpleasant truth: If one wants to build a modern, functional distribution that doesn't use systemd, alternative implementations for some systemd functionality will be needed.
Right now the only distro dealing with that reality is Gentoo, which confirms my decision to move most of my systems to it. They take patches, they are open to ideas newer than 1975, and the devs are almost always up for an argument discussion in the forum and on IRC.
Devuan meanwhile does nothing at all, actively resists implementing available solutions, or dodges any suggestion of action with statements cop-outs like the above "not a distribution" and "(user) would set it up".
The devs (aside from that one dude with the refracta xfce livecds I don't really have any use for) are nowhere to be found.
The few times Devuan has grudgingly and belatedly included alternatives for systemd functionality (eudev, elogind), those haven't been developed by Devuan for Devuan, they've been mooched from Gentoo.
Are we actually interested in forward progress here or what? Is this distro alive, or just a bunch of cranky old men clinging to the ghost of jessie past?
How is that "Init Freedom" bit coming along by the way? I don't really see any progress beyond a list of packages in the repos (with links to upstream).
Where are the init scripts? Where is the Devuan-specific configuration and documentation? Has anything actually been acomplished in the last 8 years beyond copy-pasting a list of available (but not really supported) options from Debian?
Looks to me like Devuan is still just "sysvinit or figure it out yourself" to Debian's "systemd or figure it out yourself", that's not exactly "init diversity", now is it?
Last edited by steve_v (Today 10:17:16)
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Offline
Talk is cheap.
Offline
I'm with Ralph on this one. Really not Devuan's job as it is meant to be a source for distributions, not one in of itself though it does provide working systems.
IMO it's the derivatives and their devs who should be doing that sort of customization based upon what their vision is for use-case-scenario for their distro.
Like how default Devuan only provides basic free firmware as-shipped, leaving it up to users and devs to decide what they want to add.
Please feel free to roll up your own distro with fixes for the issues you mentioned Steve, i'll be the first one to download, test, and congratulate you (and also steal any tasty bits of code you come up with, lol).
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded April 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do. Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
And not for nothing, but by the time wayland actually starts working properly out-of-the-box there will likely also be an audio solution that does so as well...maybe...Pulse still sucks after all these years, and wayland fails whereas X11 is still chugging along, mature and robust and working even on 20 year old hardware.
https://sourceforge.net/projects/vuu-do/ New Vuu-do isos uploaded April 2025!
Vuu-do GNU/Linux, minimal Devuan-based Openbox and Mate systems to build on. Also a max version for OB.
Devuan 5 mate-mini iso, pure Devuan, 100% no-vuu-do. Devuan 6 version also available for testing.
Please donate to support Devuan and init freedom! https://devuan.org/os/donate
Offline
FWIW, I am with Steve. Of course Debian as well as Devuan are distros. Versatile ones compared to others but still distros. Plus, Steve pinned down the issues with Devuan in general and regarding to PW pretty well. He was the only one here the past few days providing solid background information on the situation at hand. And the possible options he listed on how Devuan might proceed here and related issues seem very well considered to me! RESPECT!
What kind of bothers me is, this thread – which resides under "How to:" – has a lot of unhelpful, unnecessary comments. I came here to learn about PW – How-to PW my LXQt environment – and not to read about what non PW users think about PW. Such comments make reading and comprehending a tedious task. Sharing one's opinion is fine but please, not inside "How-to"!
Offline
Talk is cheap.
extremely cheap
This isn't going to go away, so which solution do we want?
* Extend sysvinit.
* Switch to an init system that isn't quite so crusty.
* Adopt something else to manage user daemons, such as the examples I mentioned earlier.
* Maintain fragile semi-functional shell hacks for each package that needs this, and deal with the inevitable bugs/jank as they arise.
* Bury our heads in the sand, and let the users figure it out. *status quo*
i wrote my own solution to manage user level services in pure posix shell script very much inspired by my understanding of sysvinit, it works well enough for me but is still 2, well 3 major feature sets (if you want XDG_AUTOSTART to just work seamlessly) away from being a proper session-manager/session-process that is also completely agnostic to the environment (x11, wayland, tty, ssh, whatever) other than requiring a posix shell interpreter and core utils (all which can so far be provided by busybox), but the project has gained basically no traction, so far i've only got some comments and feedback from like 5 or 6 people so my work on the project has been sporadic, i mainly work on the project when I need a new feature or have foolishly done work before applying to a coding job, mind you without results... if anyone's interested (likely not) the link is here: https://github.com/eylles/shed
Online