Hi,
I’m trying to run a script from the pi-sound app. I made a copy of the shutdown script folder in the /usr/local/pisound-ctl/system directory, I renamed it, changed the script, blokas.yml etc.
It all works fine, except, even though I background the latest command (in my case jacktrip -S& ) the server is killed as soon as I start a PD patch from the puredata menu.
I could start PD from the script as well I guess, but prefer to keep it clean and and have it not killed as soon as I run another script…
can I config this somehow?
Hi, try to make your last line like this:
nohup jacktrip -S &
Hi,
It still gets killed…
however, now when I do ps aux | grep jacktrip an extra line is present
patch 2845 1.7 0.3 111072 29300 pts/0 Sl 14:28 0:00 mousepad /usr/local/pisound-ctl/system/jacktripServer/blokas.yml
that line was not there without nohup
oh well, that is the name of the text editor window still open 
that’s not gonna help…
1 Like
Try using https://github.com/bmc/daemonize to get the jacktrip process detached from the process group, so it remains alive.
process remains alive now but…
I also could not start the PD-patch.
If I manually kill the daeminized process sudo killall jacktrip from a different terminal then PD pops up, both on my VNC screen and in the PIsound app controls…
i just ran daemonize jacktrip -S from the script in pisound-ctl using the phone GUI
to clarify, if I run the script from a terminal everything works fine. I just need this (and some other scripts) to be user friendly accessible… I was hoping to use the pisound app.
Why the PD patch did not start? Did it give some error?
no, it just hangs… it waits if I go the console in the pisound, the output (only my echo’s pre jacktrip start) are shown. It really waits. I tried adding an extra echo after the daemonize, but same result. It feels like the pisound app is blocking the PD launch, it does never execute, until I kill jacktrip over VNC or SSH
A sure way to get around this would be to make jacktrip run as a systemd service, and just do sudo systemctl start jacktrip from your script to launch it. Like see this service file for an example:
https://github.com/BlokasLabs/pisound/blob/master/pisound-btn/debian/usr/lib/systemd/system/wifi-hotspot.service - these service files should be in your /etc/systemd/system/ folder, and keep in mind that they run from ‘blank slate’ environment as root, so you have to use Environment= or EnvironmentFile= to set it up if needed, etc…
There’s of course more variations how the service file could be created.
I agree this could solve my jacktrip server problem, but not the clients who will have to be able to run custom scripts…in a user friendly way. In this case choir singers who get a RPi and will just plug it in, use pisound to run a script specific to their situation.
this could be git pull to get the latest settings, supplied by remote support, because the singers don’t know linux, will not have a laptop at their locations…
but I also need it for jackmess to patch in the right connections at the right time. A user should be able to select which participant groups he/she hears seperately…
So in many cases I was hopeing the pisound app would cover that in the scripts pages…
other option is I send a command to a python deamon that will be running anyway, over UDP, using a “setup page” from pure data with some buttons… I’ll try and go down that path for the moment
Yeah, it sounds like the Pisound App’s scripts is not fully suited for this purpose, including from user feedback point of view. Maybe it could work for controlling via the App if you would set up some MEC controls, especially if you could control this via PD.
Hi I’m trying to setup this script to autostart jacktrip on boot. I’m running into this environment problem.
If I run my “startclient.sh” script from /home/patch as the “patch” user the jacktrip client connects fine. However, If use the systemd, I can see it started, but crashes in systemstl status command. I think it’s not happy with the environment as you pointed out. So what line in my .service file would set up a “normal” ptach-user environment, the one I would get when logging in over ssh as patch?
Try: EnvironmentFile=/etc/environment.
You may inspect the current environment of the shell by running export (ignore decalre -x in the output)
Assume that systemd services are running without any environment variables, other than the ones specified by Environment=SOMETHING=VALUE and EnvironmentFile=.... This includes the HOME variable which may be necessary for some software.
alright, took some time to test it, but it works!
1 Like