25 Apr
2019
25 Apr
'19
8: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