Bug 28344 - pipewire Permission denied errors
Summary: pipewire Permission denied errors
Status: RESOLVED WORKSFORME
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-10 18:15 CET by Bit Twister
Modified: 2021-03-05 19:53 CET (History)
3 users (show)

See Also:
Source RPM: pipewire-0.3.19-1.mga8.src.rpm
CVE:
Status comment:


Attachments
journal grep pipewire (4.86 KB, text/plain)
2021-02-10 18:17 CET, Bit Twister
Details

Description Bit Twister 2021-02-10 18:15:06 CET
Description of problem: mga8 rc


No systemctl control

# locate pipewire.service
/etc/systemd/user/default.target.wants/pipewire.service
/usr/lib/systemd/user/pipewire.service

# systemctl status pipewire.service
Unit pipewire.service could not be found.

Missing binaries,

$ grep pw- /usr/share/doc/lib64pipewire0.3_0/README.md snippets:

pw-cat can be used to play and record audio and midi. ke
pw-play /home/wim/data/01.
pw-jack <appname>
pw-mon  dumps and monitors the state of the PipeWire daemon.
pw-dot can dump a graph of the pipeline, check out the help for
pw-cli. This tools can be used interactively or it can execute

$ locate bin/pw-
/usr/bin/pw-top

Problems in journal
 could not set nice-level to -11: Permission denied
 Failed to receive portal pid
 could not make thread realtime: Permission denied
See attachment.

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


How reproducible: Always


Steps to Reproduce:
1. journalctl --no-hostname | grep pipewire


Clean network nonfree/tainted 64bit install on cms/non-efi systems
Comment 1 Bit Twister 2021-02-10 18:17:05 CET
Created attachment 12328 [details]
journal grep pipewire
Comment 2 Lewis Smith 2021-02-10 20:52:20 CET
Thank you for the report, and the nice journal extract. Could the bug title be "pipewire does not start"?

> Missing binaries
> $ locate bin/pw-
> /usr/bin/pw-top
 $ urpmq -l pipewire            includes:
/etc/pipewire                                                                  
/etc/pipewire/media-session.d
/etc/pipewire/media-session.d/media-session.conf
/etc/pipewire/pipewire.conf

/usr/bin/pipewire
/usr/bin/pipewire-media-session
/usr/bin/pw-top

/usr/lib/systemd/user/pipewire.service
/usr/lib/systemd/user/pipewire.socket
/usr/lib/udev/rules.d/90-pipewire-alsa.rules

/usr/lib64/pipewire-0.3/libpipewire-module-*.so         x16
/usr/lib64/spa-0.2/*                                    x21

If you are missing some of these, can you say what you do have from this list?
And if you urpme then re-install it?

CC: (none) => lewyssmith

Bit Twister 2021-02-10 22:21:41 CET

Summary: pipewire problems => pipewire Permission denied errors

Comment 3 Bit Twister 2021-02-10 22:37:26 CET
(In reply to Lewis Smith from comment #2)
> Thank you for the report, and the nice journal extract. Could the bug title
> be "pipewire does not start"?
> 
> > Missing binaries
> > $ locate bin/pw-
> > /usr/bin/pw-top

>  $ urpmq -l pipewire            includes:


> 
> /usr/bin/pipewire
> /usr/bin/pipewire-media-session
> /usr/bin/pw-top

Note that I had pw-top installed. :)

Missing apps solution is to install the pipewire-utils for
the rest of the utilities mentioned in the documentation.

> And if you urpme then re-install it?

Nothing would change. I have the same denied errors on two systems.
Both were netinstalls.

No systemctl control is a "Feature" there is no unit name in
/usr/lib/systemd/user/pipewire.service
Comment 4 Dave Hodgins 2021-02-11 03:44:41 CET
# urpmq -l pipewire|grep service
/usr/lib/systemd/user/pipewire.service

Note the "user" in the service directory path.

Starting it should be done as a regular user, not as root with

$ systemctl --user start pipewire.service

[dave@x3 ~]$ systemctl --user start pipewire.service
[dave@x3 ~]$ systemctl --user status pipewire.service
● pipewire.service - Multimedia Service
   Loaded: loaded (/usr/lib/systemd/user/pipewire.service; disabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-02-10 21:42:31 EST; 3s ago
 Main PID: 2439 (pipewire)
   CGroup: /user.slice/user-500.slice/user@500.service/pipewire.service
           └─2439 /usr/bin/pipewire

Feb 10 21:42:31 x3.hodgins.homeip.net systemd[2346]: Started Multimedia Service.
Feb 10 21:42:31 x3.hodgins.homeip.net pipewire[2439]: [E][module-protocol-native.c:336 client_new()] no peersec: Protocol not available

I haven't looked into what's actually required to use it.

CC: (none) => davidwhodgins

Comment 5 Lewis Smith 2021-02-11 19:54:11 CET
> Note that I had pw-top installed. :)
> Missing apps solution is to install the pipewire-utils
I was confused that you cited just 'pw-top' which with the following phrase suggested that /usr/bin/pipewire  & /usr/bin/pipewire-media-session were missing; I see now you meant all the other applications.

Await your reply to Dave's suggestion.
Comment 6 Aurelien Oudelet 2021-02-19 14:40:47 CET
$ systemctl --user status pipewire.service
● pipewire.service - Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2021-02-19 09:56:27 CET; 4h 42min ago
TriggeredBy: ● pipewire.socket
   Main PID: 2262 (pipewire)
      Tasks: 4 (limit: 19128)
     Memory: 2.7M
        CPU: 1.092s
     CGroup: /user.slice/user-1000.slice/user@1000.service/pipewire.service
             ├─2262 /usr/bin/pipewire
             └─2267 /usr/bin/pipewire-media-session

févr. 19 09:56:27 mageia.local systemd[2248]: Started Multimedia Service.
févr. 19 09:56:27 mageia.local pipewire[2262]: Failed to receive portal pid: org.freedesktop.DBus.Error.NameHasNoOwner: Could not get PID of name 'org.freedesktop.portal.Desktop': no such name

The above error logged each boot time is annoying.
Meanwhile, I don't see any permission error in my logs.
(M8 installed from RC take 5, x86_64, Plasma-only)
Also, I leave this open as I will redo tests under VBox later.

CC: (none) => ouaurelien

Comment 7 Aurelien Oudelet 2021-03-05 17:54:21 CET
Still the case as my comment 6. No longer complain about Permission denied errors.

Can I change the title?
Comment 8 Bit Twister 2021-03-05 19:43:56 CET
> Can I change the title?

Sure, and while you are at it, Could you change the Resolved status.

Guessing I hit the wrong mouse button and bug shows fixed.  :(

 Permission denied errors are caused by non-gui logins (su - some_user).
Comment 9 Aurelien Oudelet 2021-03-05 19:53:16 CET
(In reply to Bit Twister from comment #8)
> > Can I change the title?
> 
> Sure, and while you are at it, Could you change the Resolved status.
> 
> Guessing I hit the wrong mouse button and bug shows fixed.  :(
> 
>  Permission denied errors are caused by non-gui logins (su - some_user).

Oh yeah, this is another issue running systemd --user service while running in a CLI...
So, WORKSFORME for permission errors.

But, changing it to dbus error. Seems as long as this runs by a systemd --user manager, it should runs AFTER an other systemd -user service launched before.

Opening a new bug for this.

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


Note You need to log in before you can comment on or make changes to this bug.