2

Pfiew that was a long question...

So, during bootup, I am starting on the background a python script (it gets called in the launcher).

sh /home/pi/launcher.sh&

When I ssh to the rpi I can see the python running "top -d 1". That python script runs forever and it outputs some print() messages which of course I can't see when I ssh because the app is in the background. To overcome this, I have to pkill python and then run the script "my-self" on my shell...

To put it in the background again I can either kill the app and restart the rpi or run it myself with the & in the end and then simply exit the shell...

The question is, is there a way to grab that proc from the background, without killing it (we can stop/pause it), and then after I finish looking at it and the messages it prints, send it back to the background and close my shell?

Edited: To put this in perspective, we are talking about industrial environment(s) with 20+ devices per customer. The python script is made by me and in those 4k lines of code I have various print() messages. Ofc those by them selves don't spamm the screen, but, in one certain setup of those devices there is serial communications between my devices and the big machine they "sit" on. That machine is sending serial data every 1-2 seconds, which I print() and also based on those data I do stuff. Normally I don't "care" that much about that serial data, but if there is a problem I need to "see" them "live". There were alot of suggestions and thank you for that. Since I am afraid to write to much stuff on the sd card over and over again, I could always use the "ramdrives" I have in my fstab and create the files there. I mainly use those "ramdrives" because my image is readonly and some "stuff" like samba need to be able to write somewhere.

Edit2: I am currently exploring "import logging" and writing that file to the aforementioned ramdrives. Tried changing the stdout but failed miserably. I believe because I have many threads running and also it doesn't seem like a good practice based on the comments. f = open('output.txt','w') sys.stdout = f

papatrexas
  • 511
  • 1
  • 3
  • 12

3 Answers3

1

The way I did something similar is to script starting the process within screen.

screen can be attached and detached inside your ssh connection, to access the program running.

SESSION_NAME=name
NL=$(echo -ne '\015')
screen -S "$SESSION_NAME" -d -m -U -A
screen -S "$SESSION_NAME" -X screen 1
screen -S "$SESSION_NAME" -p 1 -X stuff "sh /home/pi/launcher.sh$NL"

Then from ssh session:

screen -xRR

to connect.

tmux is newer than screen, but I haven't setup scripting with tmux.

Another option might be to make the program log to a file, then you can review the file to check the output.

Another thing that can be done is to use reptyr to take ownership of a running process. However this is rather hacky - using ptrace. And it leaves the command attached to your ssh connection so will get SIGHUP when you disconnect. Best only used as an emergency tool to connect a process to a screen or tmux session.

Douglas Leeder
  • 351
  • 1
  • 7
0

Use tail -f

Change your startup script to

sh /home/pi/launcher.sh > /home/pi/launcher.log &

Then when you log in, just enter

tail -f /home/pi/launcher.log

The tail command show the last few lines of the file. The -f switch causes tail to not stop at the end of the file, but to wait for more data.

Peter Bill
  • 339
  • 2
  • 8
0

Use an environment variable

As you control the source code, you have more options. I would consider an environment variable, declared like:

export my_debug=0

In the Python code, for output you only rarely need, only execute the print() if $my_debug is not zero. Remember to retrieve the variable regularly, say every time round the 'main loop'.

Then, when you need the extended output, you can simply set $my_debug to one. Of course, this must be done in the same shell as started the process, so you would need @DouglasLeeder's answer too.

The benefit is your output file is much smaller, not containing data that will never be read.

I'm not a Python programmer, but have done this many times in C code.

Peter Bill
  • 339
  • 2
  • 8