For development it is useful to be able to start an application (not containerised yet) from ssh.
On Toradex Linux, this works as expected.
However, with Torizon we have a problem. As soon as the user exits from ssh, the application stops.
We are using the command
sudo -b nohup /home/torizon/<app name> <arguments>
Looking at the process list, this is correctly creating processes which are owned by “root” rather than “torizon”. However, the processes all stop when the user exits from ssh.
I tried the following as an alternative
sudo setsid -f sh -c 'exec <app name> <arguments> <> /dev/tty40 >&0 2>&1'
Looking at the process list, this also correctly creates a process which is owned by “root” and connected to tty40, rather than owned by “torizon” and connected to the SSH tty. However, the process again stops when the user exits from ssh.
It appears that the processes are in some way still associated with the ssh session and Torizon kills them when the session exits. I’m confused by this behaviour as my understanding is that either of the above methods should stop it happening - I don’t understand how Torizon “knows” that these processes were originally started by the ssh session.
I appreciate that the expected design pattern for Torizon is to use containers but I suspect we are not unique in migrating from an existing non-containerised app so it may be helpful to others as well to have an understanding of why nohup/setsid don’t seem to be working on Torizon and whether there is a workaround.
Hello @Sebtombs,
If you are using Torizon OS with Docker available, we recommend that you do this in a container. If your concern is hardware access, we have many guides on the topic and it is always possible to run containers with the --privileged in development.
That being said, if you really don’t want to use containers in your initial tests, an alternative to nohup would be to setup a SystemD service to run your application and start the service.
Here is a basic example of what the service file (/etc/systemd/system/myapp.service) might look like:
[Unit]
Description=My Application Service
[Service]
Type=simple
ExecStart=/home/torizon/myapp myargs
[Install]
WantedBy=multi-user.target
After creating this file, enable and start your service with:
sudo systemctl enable myapp.service # only needed if you want the application to auto-start at boot
sudo systemctl start myapp.service
Best Regards,
Bruno
Thanks Bruno. However, with Torizon I thought I could only expect /home and /var to persist and that all the other directories get created by ostree on boot? Is that an incorrect understanding of mine?
All the best,
Mark
So, my understanding was incorrect. ostree does not regenerate directories other than /home and /var on boot, so using systemd works fine.
I therefore presume the issue with directories other than /home and /var is not related to boot but to when an OTA update is performed, which is not an issue for prototyping like this,
Hello @Sebtombs,
It is not worth to go into too much into the detail of this topic here, but both /etc and /var can be written to in a default Torizon OS image. Also note that /home is just a symbolic link to a directory under /var.
Some more information on the topic is available here: OSTree | Toradex Developer Center
Best Regards,
Bruno
