7 Jul
2021
7 Jul
'21
7:46 p.m.
Could someone please do a simple test on any Pipewire installation
set up to use/replace Jack (or shed any light on this).
If I run 'pw-record crontest.wav' it works fine, as expected.
If I run 'pw-cat 2> errrrr.txt' ditto, of course.
If I setup a user cronjob with 'crontab -e' to run the commands
(at the start of the next minute or so) the first does nothing,
while the second works.
Cron writes to /var/log/syslog like:
CRON[7694]: (john) CMD (pw-record crontest.wav)
rtkit-daemon[1277]: Supervising 7 threads of 4 processes of 1 users
(second line repeated)
--
John (older than 95.6% of the population).
7 Jul
7 Jul
7:50 p.m.
The first thing I'd suggest is to put the full pathname of both the
command and the wav file. Under cron, the PATH variable may not be what
you have interactively:
/usr/bin/pw-record /home/me/crontest.wav (edit as required)
Could someone please do a simple test on any Pipewire
installation
set up to use/replace Jack (or shed any light on this).
If I run 'pw-record crontest.wav' it works fine, as expected.
If I run 'pw-cat 2> errrrr.txt' ditto, of course.
If I setup a user cronjob with 'crontab -e' to run the commands
(at the start of the next minute or so) the first does nothing,
while the second works.
Cron writes to /var/log/syslog like:
CRON[7694]: (john) CMD (pw-record crontest.wav)
rtkit-daemon[1277]: Supervising 7 threads of 4 processes of 1 users
(second line repeated)
--
John (older than 95.6% of the population).
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
--
Great music, chat and even some wit.
Join me every Friday evening at 8pm for
Keith's Music Box:
Follow: https://www.facebook.com/KMBEngland
On Friday go to: https://www.mixcloud.com/live/KeithsMusicBox/
9:24 p.m.
On Wed, 7 Jul 2021 16:50:48 +0100 Keith Edmunds wrote:
The first thing I'd suggest is to put the full
pathname of both the
command and the wav file. Under cron, the PATH variable may not be what
you have interactively:
/usr/bin/pw-record /home/me/crontest.wav (edit as required)
Thanks, but no change, except the syslog entry:
Jul 7 18:20:01 NUC1 CRON[10931]: (john) CMD (/usr/bin/pw-record /home/john/crontest.wav)
--
John.
10:01 p.m.
Thanks, but no change, except the syslog entry:
Jul 7 18:20:01 NUC1 CRON[10931]: (john) CMD (/usr/bin/pw-record
/home/john/crontest.wav)
Try:
/usr/bin/pw-record /home/john/crontest.wav > /tmp/cronjob.txt 2>&1
...and have a look in /tmp/cronjob.txt after it's run
--
Great music, chat and even some wit.
Join me every Friday evening at 8pm for
Keith's Music Box:
Follow: https://www.facebook.com/KMBEngland
On Friday go to: https://www.mixcloud.com/live/KeithsMusicBox/
10:25 p.m.
On Wed, 7 Jul 2021 19:01:25 +0100 Keith Edmunds wrote:
Try:
/usr/bin/pw-record /home/john/crontest.wav > /tmp/cronjob.txt 2>&1
...and have a look in /tmp/cronjob.txt after it's run
/tmp/cronjob.txt says error: pw_context_connect() failed: Host is down
I've no idea what that means, or why that should be so.
I tried with arecord in place of /usr/bin/pw-record and got:
arecord: main:852: audio open error: Host is down.
--
Thanks, John.
10:33 p.m.
/tmp/cronjob.txt says error: pw_context_connect()
failed: Host is down
I can't help you with that, sorry, but hopefully it points the way to
resolving the problem.
--
Great music, chat and even some wit.
Join me every Friday evening at 8pm for
Keith's Music Box:
Follow: https://www.facebook.com/KMBEngland
On Friday go to: https://www.mixcloud.com/live/KeithsMusicBox/
11:11 p.m.
On Wed, 7 Jul 2021 19:33:18 +0100 Keith Edmunds wrote:
Hopefully it will mean something to someone if/when I write to Pipewire/
issues and I know how to see cron errors now, so it's all good.
I'll wait a while, hoping someone can try it on their Pipewire system.
Would prove if it's just a local problem.
Thinking the host might be up if there was already a recording happening;
I started a recording manually first, but no change.
--
Thanks again, John.
/tmp/cronjob.txt says error: pw_context_connect() failed: Host is down
I can't help you with that, sorry, but hopefully it points the way to
resolving the problem. 
8 Jul
8 Jul
2:20 a.m.
Le Wed, 7 Jul 2021 19:24:38 +0100,
John Murphy <rosegardener(a)freeode.co.uk> a écrit :
On Wed, 7 Jul 2021 19:01:25 +0100 Keith Edmunds
wrote:
/tmp/cronjob.txt says error: pw_context_connect() failed: Host is down
Maybe pipewire is not run by the same user than the cron job.
Dominique
7:57 p.m.
On 7/7/21 11:24 AM, John Murphy wrote:
On Wed, 7 Jul 2021 19:01:25 +0100 Keith Edmunds
wrote:
https://docs.pipewire.org/group__pw__core.html
----
Connect to a PipeWire instance.
Returns
a The Core Global Object on success or NULL with errno set on
error. The core will have an id of PW_ID_CORE (0)
----
So it would seem that the pipewire client cannot connect to the server
(or something like that). Could be ownership, permissions, even selinux
if it is running.
It could also be that running things from cron does not establish a
"session" and then you do not have access permission to audio devices
and such (and dbus, as suggested elsewhere in the thread).
-- Fernando
Try:
/usr/bin/pw-record /home/john/crontest.wav > /tmp/cronjob.txt 2>&1
...and have a look in /tmp/cronjob.txt after it's run
/tmp/cronjob.txt says error: pw_context_connect() failed: Host is down
I've no idea what that means, or why that should be so. I tried with arecord in place of /usr/bin/pw-record
and got:
arecord: main:852: audio open error: Host is down.
10:29 p.m.
On Thu, 8 Jul 2021 08:56:56 -0700 Fernando Lopez-Lezcano wrote:
On 7/7/21 11:24 AM, John Murphy wrote:
Thanks for the thoughts. There are some selinux libs installed,
but not much else. I added a job to /etc/crontab like:
04 19 * * * root /usr/bin/pw-record /home/john/crontest.wav > /tmp/cronjob.txt
2>&1
and see the same error in the text file.
On Wed, 7 Jul 2021 19:01:25 +0100 Keith Edmunds
wrote:
https://docs.pipewire.org/group__pw__core.html
----
Connect to a PipeWire instance.
Returns
a The Core Global Object on success or NULL with errno set on
error. The core will have an id of PW_ID_CORE (0)
----
So it would seem that the pipewire client cannot connect to the server
(or something like that). Could be ownership, permissions, even selinux
if it is running. Try:
/usr/bin/pw-record /home/john/crontest.wav > /tmp/cronjob.txt 2>&1
...and have a look in /tmp/cronjob.txt after it's run
/tmp/cronjob.txt says error: pw_context_connect() failed: Host is down
I've no idea what that means, or why that should be so. It could also be that running things from cron does
not establish a
"session" and then you do not have access permission to audio devices
and such (and dbus, as suggested elsewhere in the thread).
It's a long time since I've used root for anything, but I think it
would still have the required permissions to do anything. I begin to
wonder if this is by design, but I still don't know if it works for
anyone else.
--
John.
9 Jul
9 Jul
6:12 a.m.
On 7/8/21 11:29 AM, John Murphy wrote:
On Thu, 8 Jul 2021 08:56:56 -0700 Fernando
Lopez-Lezcano wrote:
Maybe running as root is actually not enough :-(
I don't know how to fix this but it is likely that this does not
establish a "session" (or "seat") and then dbus is not running and
then
nothing that depends on it can work. Maybe running the cron job as a
normal user? I don't know how you can convince the system that you
really are allowed to do all this...
< and if selinux is involved, maybe you can look at what is in the logs?
/var/log/secure, /var/log/messages, and hunt for denials or permission
problems? >
-- Fernando
On 7/7/21 11:24 AM, John Murphy wrote:
Thanks for the thoughts. There are some selinux libs installed,
but not much else. I added a job to /etc/crontab like:
04 19 * * * root /usr/bin/pw-record /home/john/crontest.wav > /tmp/cronjob.txt
2>&1
and see the same error in the text file. On Wed, 7 Jul 2021 19:01:25 +0100 Keith Edmunds
wrote:
https://docs.pipewire.org/group__pw__core.html
----
Connect to a PipeWire instance.
Returns
a The Core Global Object on success or NULL with errno set on
error. The core will have an id of PW_ID_CORE (0)
----
So it would seem that the pipewire client cannot connect to the server
(or something like that). Could be ownership, permissions, even selinux
if it is running. Try:
/usr/bin/pw-record /home/john/crontest.wav > /tmp/cronjob.txt 2>&1
...and have a look in /tmp/cronjob.txt after it's run
/tmp/cronjob.txt says error: pw_context_connect() failed: Host is down
I've no idea what that means, or why that should be so. It could also
be that running things from cron does not establish a
"session" and then you do not have access permission to audio devices
and such (and dbus, as suggested elsewhere in the thread).
It's a long time since I've used root for anything, but I think it
would still have the required permissions to do anything. I begin to
wonder if this is by design, but I still don't know if it works for
anyone else.
11:28 a.m.
Le Thu, 8 Jul 2021 19:12:29 -0700,
Fernando Lopez-Lezcano <nando(a)ccrma.Stanford.EDU> a écrit :
>> It could also be that running things from
cron does not establish a
>> "session" and then you do not have access permission to audio
>> devices and such (and dbus, as suggested elsewhere in the thread).
>>
>
> It's a long time since I've used root for anything, but I think it
> would still have the required permissions to do anything. I begin to
> wonder if this is by design, but I still don't know if it works for
> anyone else.
On linux, the audio devices can be acceded by only 1 user at a time.
Which imply, instead of being root for everything audio related, I would
login as an user member of the audio group and, instead of using cron,
make a custom user script.
12:52 p.m.
On Fri, 9 Jul 2021 09:29:09 +0200 Dominique Michel wrote:
On linux, the audio devices can be acceded by only 1
user at a time.
Which imply, instead of being root for everything audio related, I would
login as an user member of the audio group and, instead of using cron,
make a custom user script.
Thanks, but if Pipewire is going to prevent access to audio devices by
cronjobs, either accidentally or by design, then I'll be removing it.
--
John.
1:35 p.m.
Le Fri, 9 Jul 2021 09:52:18 +0100,
John Murphy <rosegardener(a)freeode.co.uk> a écrit :
On Fri, 9 Jul 2021 09:29:09 +0200 Dominique Michel
wrote:
That issue have nothing to do with pipewire, but with how the
kernel ALSA driver works. Which imply, instead of trying to workaround
normal kernel operations and user/group permissions, you must work with
them. It will be both much simpler and more reliable on the long run to
use a joe user member of the audio group, and instead of messing with
cron jobs which was never intended to be used to implement joe user
tasks, just make a joe user (bash-python-...) script that will implement
what you want to do.
On linux, the audio devices can be acceded by
only 1 user at a time.
Which imply, instead of being root for everything audio related, I
would login as an user member of the audio group and, instead of
using cron, make a custom user script.
Thanks, but if Pipewire is going to prevent access to audio devices by
cronjobs, either accidentally or by design, then I'll be removing it.
1:41 p.m.
instead of messing with cron jobs which was never
intended to be used to
implement joe user tasks
Au contraire, that is exactly what cron is for.
I would agree that the /etc/crontab file should not be used for user
tasks, nor the /etc/cron.* directories that most distros support.
However, there is also the crontab(1) command which allows per-user
crontabs to be set up. The start of the man page even says, "crontab -
maintain crontab files for individual users".
So no, don't use the system cron files under /etc, but do use the crontab
commands to manage user jobs.
--
Great music, chat and even some wit.
Join me every Friday evening at 8pm for
Keith's Music Box:
Follow: https://www.facebook.com/KMBEngland
On Friday go to: https://www.mixcloud.com/live/KeithsMusicBox/
4:15 p.m.
On Fri, 9 Jul 2021 11:35:43 +0200 Dominique Michel wrote:
Le Fri, 9 Jul 2021 09:52:18 +0100,
John Murphy <rosegardener(a)freeode.co.uk> a écrit :
I should have made clear from the start of this thread that I had been
running a script via user cron, to do the recording, which had worked
just fine (obviously not with pw-record) for months prior to installing
Pipewire. It's certainly possible I did something wrong, or that I did
something else around the same time to cause the problem. Which is why
I've asked if it works for others. No one seems to want to answer
definitively.
I was just using pw-record for testing. I couldn't actually use it in
my script as it doesn't have a -d (duration) option.
--
Thanks again, John.
On Fri, 9 Jul 2021 09:29:09 +0200 Dominique
Michel wrote:
That issue have nothing to do with pipewire, but with how the
kernel ALSA driver works. Which imply, instead of trying to workaround
normal kernel operations and user/group permissions, you must work with
them. It will be both much simpler and more reliable on the long run to
use a joe user member of the audio group, and instead of messing with
cron jobs which was never intended to be used to implement joe user
tasks, just make a joe user (bash-python-...) script that will implement
what you want to do. On linux, the audio devices can be acceded by
only 1 user at a time.
Which imply, instead of being root for everything audio related, I
would login as an user member of the audio group and, instead of
using cron, make a custom user script.
Thanks, but if Pipewire is going to prevent access to audio devices by
cronjobs, either accidentally or by design, then I'll be removing it.
12:52 p.m.
On Thu, 8 Jul 2021 19:12:29 -0700 Fernando Lopez-Lezcano wrote:
On 7/8/21 11:29 AM, John Murphy wrote:
Identical error with the /etc/crontab entry run by user john.
04 19 * * * root /usr/bin/pw-record
/home/john/crontest.wav > /tmp/cronjob.txt 2>&1
and see the same error in the text file.
Maybe running as root is actually not enough :-(
I don't know how to fix this but it is likely that this does not
establish a "session" (or "seat") and then dbus is not running and
then
nothing that depends on it can work. Maybe running the cron job as a
normal user? I don't know how you can convince the system that you
really are allowed to do all this... < and if selinux is involved, maybe you can look at
what is in the logs?
/var/log/secure, /var/log/messages, and hunt for denials or permission
problems? >
No selinux thank Dev ('getenforce' returns command not found).
I was running 'tail -f /var/log/syslog' (no /var/log/[messages|secure])
when I saw the CRON and rtkit-daemon messages in my opening post. Would
expect to have seen an entry there for any other problem at the time.
--
Thanks again, John.
4:25 p.m.
You need to make sure the cron script can find the local socket to
talk to pipewire.
It searches for the socket named pipewire-0 in:
$PIPEWIRE_RUNTIME_DIR
$XDG_RUNTIME_DIR
$HOME
~/
I'm guessing that the cron script is running with a different user
and/or does not have
the same environment variables as the main pipewire daemon and thus
looks in a different
place and can't find a socket.
Normally the user running the daemon will set
XDG_RUNTIME_DIR=/run/user/1000 and the
socket will be named /run/user/1000/pipewire-0
Substitute 1000 for the user id.
Try this in the cron script:
PIPEWIRE_RUNTIME_DIR=/run/user/1000 pw-record
An try again. I'm pretty sure it's a socket path thing. There is no
dbus, systemd or device permissions
involved. You need to check if the cronjob can find and has
permissions to connect to the socket and
that's it.
Wim
On Wed, 7 Jul 2021 at 17:47, John Murphy <rosegardener(a)freeode.co.uk> wrote:
Could someone please do a simple test on any Pipewire installation
set up to use/replace Jack (or shed any light on this).
If I run 'pw-record crontest.wav' it works fine, as expected.
If I run 'pw-cat 2> errrrr.txt' ditto, of course.
If I setup a user cronjob with 'crontab -e' to run the commands
(at the start of the next minute or so) the first does nothing,
while the second works.
Cron writes to /var/log/syslog like:
CRON[7694]: (john) CMD (pw-record crontest.wav)
rtkit-daemon[1277]: Supervising 7 threads of 4 processes of 1 users
(second line repeated)
--
John (older than 95.6% of the population).
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
5:23 p.m.
Many thanks for the input Wim. Sorry to distract you from the work.
My user id is indeed 1000 and $XDG_RUNTIME_DIR is /run/user/1000
where there is a pipewire-0 socket (0 bytes) and a pipewire-0.lock
of the same size.
I ran the line below from the command line first and it worked.
Tried it in the cronjob and it works there too!!
PIPEWIRE_RUNTIME_DIR=/run/user/1000 pw-record /home/john/crontest.wav
The script I was using runs jack_record (for the 'duration').
I added a line like: export PIPEWIRE_RUNTIME_DIR=/run/user/1000
and changed the cronjob accordingly. That works too, so I am sorted.
Sincere thanks to all for the help. I'm still learning much.
John.
On Fri, 9 Jul 2021 14:25:03 +0200 Wim Taymans wrote:
You need to make sure the cron script can find the
local socket to
talk to pipewire.
It searches for the socket named pipewire-0 in:
$PIPEWIRE_RUNTIME_DIR
$XDG_RUNTIME_DIR
$HOME
~/
I'm guessing that the cron script is running with a different user
and/or does not have
the same environment variables as the main pipewire daemon and thus
looks in a different
place and can't find a socket.
Normally the user running the daemon will set
XDG_RUNTIME_DIR=/run/user/1000 and the
socket will be named /run/user/1000/pipewire-0
Substitute 1000 for the user id.
Try this in the cron script:
PIPEWIRE_RUNTIME_DIR=/run/user/1000 pw-record
An try again. I'm pretty sure it's a socket path thing. There is no
dbus, systemd or device permissions
involved. You need to check if the cronjob can find and has
permissions to connect to the socket and
that's it.
Wim
On Wed, 7 Jul 2021 at 17:47, John Murphy <rosegardener(a)freeode.co.uk> wrote:
>
> Could someone please do a simple test on any Pipewire installation
> set up to use/replace Jack (or shed any light on this).
>
> If I run 'pw-record crontest.wav' it works fine, as expected.
> If I run 'pw-cat 2> errrrr.txt' ditto, of course.
>
> If I setup a user cronjob with 'crontab -e' to run the commands
> (at the start of the next minute or so) the first does nothing,
> while the second works.
>
> Cron writes to /var/log/syslog like:
>
> CRON[7694]: (john) CMD (pw-record crontest.wav)
> rtkit-daemon[1277]: Supervising 7 threads of 4 processes of 1 users
>
> (second line repeated)
>
> --
> John (older than 95.6% of the population).
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
1261
days inactive
1263
days old
linux-audio-dev@lists.linuxaudio.org
18 comments
5 participants
participants (5)
-
Dominique Michel -
Fernando Lopez-Lezcano -
John Murphy -
Keith Edmunds -
Wim Taymans