25 Apr
2019
25 Apr
'19
2:35 a.m.
Hey!
I have a hard time setting up a tmux session started with systemd on
raspbian (patchbox OS, realtime kernel) to behaves like as if I started
my script manually.
This is my Jack Capture service:
[Unit]
Description=Jack Capture autostart daemon
Wants=jack.service
After=multi-user.target
[Service]
Type=forking
EnvironmentFile=/etc/environment
User=patch
Group=realtime
ExecStart=/home/patch/jack-capture-tmux.sh
[Install]
WantedBy=jack.service
and this my script to start tmux with jack capture:
#!/bin/bash
. /etc/environment
/usr/bin/jack_wait -w
tmux new-session -d -s jackd
tmux new-window -t jackd -n Jack Capture -d
sleep 1
tmux send-keys -t jackd:0 'cd ~/' C-m
tmux send-keys -t jackd:0 'clear' C-m
tmux send-keys -t jackd:0 'jack_capture -c 2 -mb -tm -f wav
--filename-prefix ABC-TEST- --hook-close ./hookstop.sh --hook-timing
./hookstart.sh' C-m
everything a bloated from all my tries to make this work...
Now it starts properly but if I look into that tmux session I get
warnings/errors:
jack_capture -c 2 -mb -tm -f wav --filename-prefix ABC-TEST-
--hook-close ./hookstop.sh --hook-timing ./hookstart.sh
Cannot lock down 82287136 byte memory area (Cannot allocate memory)
>> Warning. Could not set higher priority for a
SCHED_OTHER process
>> using setpriority().
Cannot use real-time scheduling (RR/70)(1: Operation
not permitted)
JackClient::AcquireSelfRealTime error
>> Waiting to start recording of
"ABC-TEST-10.wav"
>> Press <Ctrl-C> to stop recording and quit.
I had this solved when starting the script manually by adding * - nice
-20 into /etc/security/limits.conf - but this obviously is not working
when starting the script within systemd (although same user).
Any ideas?
Cheers
Jan
25 Apr
25 Apr
3:30 a.m.
On Thu, Apr 25, 2019 at 11:35 AM <jack(a)microfx.de> wrote:
Now it starts properly but if I look into that tmux
session I get
warnings/errors:
jack_capture -c 2 -mb -tm -f wav --filename-prefix ABC-TEST-
--hook-close ./hookstop.sh --hook-timing ./hookstart.sh
Cannot lock down 82287136 byte memory area (Cannot allocate memory)
Hi, I don't know how to solve this. Just want to point out that the
"Could not set higher priority for a SCHED_OTHER process" warning is
not very important. jack_capture just tries to renice the thread that
writes to disk, but this might not make any difference. It's not
something you should care about.
The other error, "Cannot use real-time scheduling (RR/70)(1: Operation
not permitted)" is probably important though. This error comes from
libjack.
>> Warning. Could not set higher priority
for a SCHED_OTHER process
>> using setpriority().
Cannot use real-time scheduling (RR/70)(1: Operation
not permitted)
JackClient::AcquireSelfRealTime error
>> Waiting to start recording of
"ABC-TEST-10.wav"
>> Press <Ctrl-C> to stop recording and quit.
I had this solved when starting the script manually by adding * - nice
-20 into /etc/security/limits.conf - but this obviously is not working
when starting the script within systemd (although same user).
Any ideas?
3:36 a.m.
On 2019-04-25 11:35, jack(a)microfx.de wrote:
Hey!
I have a hard time setting up a tmux session started with systemd on
raspbian (patchbox OS, realtime kernel) to behaves like as if I
started my script manually.
Cannot use real-time scheduling (RR/70)(1: Operation
not permitted)
JackClient::AcquireSelfRealTime error
I had this solved when starting the script manually by adding * - nice
-20 into /etc/security/limits.conf - but this obviously is not working
when starting the script within systemd (although same user).
Any ideas?
Hi,
it could be related to https://github.com/systemd/systemd/issues/11386
https://github.com/jackaudio/jack2/issues/429
Quick test, is your systemd version 240?
Greetings
Thomas
3:39 a.m.
Hey Thomas,
systemctl --version
systemd 232
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS
+KMOD +IDN
From that issue thread I see it's only in 240 - so this is not the
problem I suppose.
Cheers
Jan
Am 2019-04-25 12:33, schrieb Thomas Brand:
On 2019-04-25 11:35, jack(a)microfx.de wrote:
Hey!
I have a hard time setting up a tmux session started with systemd on
raspbian (patchbox OS, realtime kernel) to behaves like as if I
started my script manually.
Cannot use real-time scheduling (RR/70)(1:
Operation not permitted)
JackClient::AcquireSelfRealTime error
I had this solved when starting the script manually by adding * - nice
-20 into /etc/security/limits.conf - but this obviously is not working
when starting the script within systemd (although same user).
Any ideas?
Hi,
it could be related to https://github.com/systemd/systemd/issues/11386
https://github.com/jackaudio/jack2/issues/429
Quick test, is your systemd version 240?
Greetings
Thomas
6:44 a.m.
On 2019-04-25 12:39, jack(a)microfx.de wrote:
Hey Thomas,
systemctl --version
systemd 232
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS
+KMOD +IDN
From that issue thread I see it's only in 240 - so this is not the
problem I suppose.
Cheers
Jan
Am 2019-04-25 12:33, schrieb Thomas Brand:
> On 2019-04-25 11:35, jack(a)microfx.de wrote:
>> Hey!
>>
>> I have a hard time setting up a tmux session started with systemd on
>> raspbian (patchbox OS, realtime kernel) to behaves like as if I
>> started my script manually.
>
>> Cannot use real-time scheduling (RR/70)(1: Operation not permitted)
>> JackClient::AcquireSelfRealTime error
>
>>
It's yet unclear to me if this is related to jack at all.. Can you test
this without jack? Basically leaving everything out except a script
started by systemd that tries to lock memory or calls ulimit.
Similar to your tmux approach, with screen, here's a building block:
#!/bin/bash
start_in_detached_screen()
{
#$1: username
#$2: screen name
#$3: command string (without ^M)
su ${1} -c "screen -d -m -S \"$2\""
su ${1} -c "screen -S \"$2\" -p 0 -X stuff
\"$3\"^M"
}
start_in_detached_screen john_doe "my test" "cd /tmp && ls
-ltra"
-> as root: start screen as given user and feed command to screen
session.
It should work to start jackd as a specific user early in the boot
process and see what happened by attaching the screen later on.
Greetings
Thomas
4:09 p.m.
Hey Thomas!
Thanks a lot for your input! You are totally right, I could have checked
this myself. Works like a charm with screen. So I suppose I'll go with
that solution - fantastic - also your script is very helpful! Kudos!
Cheers
Jan
Am 2019-04-25 15:41, schrieb Thomas Brand:
On 2019-04-25 12:39, jack(a)microfx.de wrote:
Hey Thomas,
systemctl --version
systemd 232
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS
+KMOD +IDN
From that issue thread I see it's only in 240 - so this is not the
problem I suppose.
Cheers
Jan
Am 2019-04-25 12:33, schrieb Thomas Brand:
> On 2019-04-25 11:35, jack(a)microfx.de wrote:
>> Hey!
>>
>> I have a hard time setting up a tmux session started with systemd on
>> raspbian (patchbox OS, realtime kernel) to behaves like as if I
>> started my script manually.
>
>> Cannot use real-time scheduling (RR/70)(1: Operation not permitted)
>> JackClient::AcquireSelfRealTime error
>
>>
It's yet unclear to me if this is related to jack at all.. Can you
test this without jack? Basically leaving everything out except a
script started by systemd that tries to lock memory or calls ulimit.
Similar to your tmux approach, with screen, here's a building block:
#!/bin/bash
start_in_detached_screen()
{
#$1: username
#$2: screen name
#$3: command string (without ^M)
su ${1} -c "screen -d -m -S \"$2\""
su ${1} -c "screen -S \"$2\" -p 0 -X stuff
\"$3\"^M"
}
start_in_detached_screen john_doe "my test" "cd /tmp && ls
-ltra"
-> as root: start screen as given user and feed command to screen
session.
It should work to start jackd as a specific user early in the boot
process and see what happened by attaching the screen later on.
Greetings
Thomas 
8:36 p.m.
Am 26.04.19 um 01:09 schrieb jack(a)microfx.de:
Hey Thomas!
Thanks a lot for your input! You are totally right, I could have
checked this myself. Works like a charm with screen. So I suppose I'll
go with that solution - fantastic - also your script is very helpful!
Kudos!
Cheers
Jan
Am 2019-04-25 15:41, schrieb Thomas Brand:
If it is a Users permission issue, you could do it with systemd by using
the XDG_RUNTIME_DIR var.
[Service]
User=USERNAME
Type=oneshot
Environment="XDG_RUNTIME_DIR=/run/user/USERID"
ExecStart=/home/patch/jack-capture-tmux.sh
were you need to set your username and id (id -u $(logname))
this will start the script with the permissions set for the user.
On 2019-04-25 12:39, jack(a)microfx.de wrote:
Hey Thomas,
systemctl --version
systemd 232
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS
+KMOD +IDN
From that issue thread I see it's only in 240 - so this is not the
problem I suppose.
Cheers
Jan
Am 2019-04-25 12:33, schrieb Thomas Brand:
> On 2019-04-25 11:35, jack(a)microfx.de wrote:
>> Hey!
>>
>> I have a hard time setting up a tmux session started with systemd on
>> raspbian (patchbox OS, realtime kernel) to behaves like as if I
>> started my script manually.
>
>> Cannot use real-time scheduling (RR/70)(1: Operation not permitted)
>> JackClient::AcquireSelfRealTime error
>
>>
It's yet unclear to me if this is related to jack at all.. Can you
test this without jack? Basically leaving everything out except a
script started by systemd that tries to lock memory or calls ulimit.
Similar to your tmux approach, with screen, here's a building block:
#!/bin/bash
start_in_detached_screen()
{
#$1: username
#$2: screen name
#$3: command string (without ^M)
su ${1} -c "screen -d -m -S \"$2\""
su ${1} -c "screen -S \"$2\" -p 0 -X stuff
\"$3\"^M"
}
start_in_detached_screen john_doe "my test" "cd /tmp && ls
-ltra"
-> as root: start screen as given user and feed command to screen
session.
It should work to start jackd as a specific user early in the boot
process and see what happened by attaching the screen later on.
Greetings
Thomas
26 Apr
26 Apr
2:01 a.m.
Am 2019-04-26 05:35, schrieb Hermann Meyer:
Am 26.04.19 um 01:09 schrieb jack(a)microfx.de:
Thank you big time too! This indeed fixed the problem - I also had to
add /bin/bash before the bash script. Really appreciated! Have a nice
weekend!
Hey Thomas!
Thanks a lot for your input! You are totally right, I could have
checked this myself. Works like a charm with screen. So I suppose I'll
go with that solution - fantastic - also your script is very helpful!
Kudos!
Cheers
Jan
Am 2019-04-25 15:41, schrieb Thomas Brand:
If it is a Users permission issue, you could do it with systemd by
using
the XDG_RUNTIME_DIR var.
[Service]
User=USERNAME
Type=oneshot
Environment="XDG_RUNTIME_DIR=/run/user/USERID"
ExecStart=/home/patch/jack-capture-tmux.sh
were you need to set your username and id (id -u $(logname))
this will start the script with the permissions set for the user. On 2019-04-25 12:39, jack(a)microfx.de wrote:
Hey Thomas,
systemctl --version
systemd 232
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID
+ELFUTILS
+KMOD +IDN
From that issue thread I see it's only in 240 - so this is not the
problem I suppose.
Cheers
Jan
Am 2019-04-25 12:33, schrieb Thomas Brand:
> On 2019-04-25 11:35, jack(a)microfx.de wrote:
>> Hey!
>>
>> I have a hard time setting up a tmux session started with systemd
>> on
>> raspbian (patchbox OS, realtime kernel) to behaves like as if I
>> started my script manually.
>
>> Cannot use real-time scheduling (RR/70)(1: Operation not
>> permitted)
>> JackClient::AcquireSelfRealTime error
>
>>
It's yet unclear to me if this is related to jack at all.. Can you
test this without jack? Basically leaving everything out except a
script started by systemd that tries to lock memory or calls ulimit.
Similar to your tmux approach, with screen, here's a building block:
#!/bin/bash
start_in_detached_screen()
{
#$1: username
#$2: screen name
#$3: command string (without ^M)
su ${1} -c "screen -d -m -S \"$2\""
su ${1} -c "screen -S \"$2\" -p 0 -X stuff
\"$3\"^M"
}
start_in_detached_screen john_doe "my test" "cd /tmp && ls
-ltra"
-> as root: start screen as given user and feed command to screen
session.
It should work to start jackd as a specific user early in the boot
process and see what happened by attaching the screen later on.
Greetings
Thomas
25 Apr
25 Apr
6:53 a.m.
On 2019-04-25 12:39, jack(a)microfx.de wrote:
Hey Thomas,
systemctl --version
systemd 232
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS
+KMOD +IDN
From that issue thread I see it's only in 240 - so this is not the
problem I suppose.
For your case you'd start jack with a user that has necessary
permissions, eventually in a screen or tmux session.
Same with the capture script, and this one can wait until jack is
available:
jack_wait -w
#... do capture etc.
Greetings
Thomas
1859
days inactive
1860
days old
jackaudio@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
Hermann Meyer -
jack＠microfx.de -
Kjetil Matheussen -
Thomas Brand