Hello Zbigniew, Thank you very much for your answers and sorry for the late reply, IRL things have been hectic. I've had the problem with pipewire once since I last wrote, but I can't figure out how to trigger it at will. On Fri, Jun 18, 2021 at 8:36 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Fri, Jun 18, 2021 at 01:38:08AM +0200, Alexander Ploumistos wrote: > > Should gdb be able to read from a sound device? > > It shouldn't attempt to. Should I file a bug against gdb or abrt? > > Having root logged in a terminal, I tried to check the state of > > pipewire.service: > > systemctl --machine=myuser@.host --user status pipewire.service > > > > to which I got the reply: > > Failed to get properties: Transport endpoint is not connected > > The way that myuser@.host is implemented is surprisingly complex. See > the original commit https://github.com/systemd/systemd/commit/1b630835df > for a description. > > Does it work for other users? If yes, then it looks like something > is borked for that particular user. Forgot to check, I will try to do it later today. > systemctl -M myuser@.host executes > systemd-run -p User=myuser systemd-stdio-bridge -punix:path=${XDG_RUNTIME_DIR}/bus > The error message is most likely from systemd-stdio-bridge, > or from systemctl failing to connect to the bridge. Since the > invocation of systemd-stdio-bridge goes through the system manager, > you can look at the logs for that unit ('journalctl -b -u run-uNNNN.service'). > It should show some error. There is no such service. Assuming NNNN is the uid, I have these units listed: user-runtime-dir@1000.service user@1000.service user-1000.slice Looking at the logs for user@1000.service, there's nothing pertinent. Actually there's nothing even in the unfiltered log when I issue the command and it fails. > > I haven't had to bother with a userspace systemd service before, so > > going down that rabbit hole, at some point I started messing with > > machinectl, and apparently, running something seemingly innocuous such > > as "machinectl list-images --all" triggers a SELinux denial. But not > > always… > > The message I'm seeing is this: > > audit[1079]: AVC avc: denied { write } for pid=1079 > > comm="systemd-machine" name="/" dev="dm-1" ino=2 > > scontext=system_u:system_r:systemd_machined_t:s0 > > tcontext=system_u:object_r:root_t:s0 tclass=dir permissive=0 > > > > setroubleshoot tells me that if I want to allow daemons to dump core, > > then I should enable the 'daemons_dump_core' boolean. I don't know if > > I want to, do I need to do that in order to dive deeper into my > > pipewire issue? How is listing the images on a system related to > > allowing demons to dump core though? > > If machined crashes, there should be logs about this. Did you > look at the journal? Nothing in the journal about machined crashing or doing anything else other than getting the SELinux denial. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
