Hi,
Once I start a .py program (or using any kind of .sh script etc) how can I monitor (i.e. print statements) after I disconnect putty, and then connect again later, getting a new cmd line? How can I find and get present rolling messages again from my running program? Need PID?
Many thanks,
Adpi
-
GlowInTheDark
- Posts: 742
- Joined: Sat Nov 09, 2019 12:14 pm
Re: Find running .py again once disconnected (i.e. putty)
apt-get install tmux
GitD's list of things that are not ready for prime time:
1) IPv6
2) 64 bit OSes
3) USB 3
4) Bluetooth
1) IPv6
2) 64 bit OSes
3) USB 3
4) Bluetooth
Re: Find running .py again once disconnected (i.e. putty)
Install screen or tmux. If you start a program inside either of them it will remain running if you lose connection and all the output from the program will be preserved so you can scroll back and look at it.
I use screen so I can use the same program from different locations devices without stopping and starting my sessions.
I use screen so I can use the same program from different locations devices without stopping and starting my sessions.
Unreadable squiggle
Re: Find running .py again once disconnected (i.e. putty)
Be aware that if you run a program normally in a shell (terminal window) on your Pi or via Putty or whatever then that program dies when you close that shell session, disconnect putty or whatever.
To have it run forever you could:
1) Run it from the nohup command: https://linux.101hacks.com/unix/nohup-command/ In which case it's output will go to some file that you can read when you log in again.
2) Run it as a 'daemon', a background service: Typically done by creating a systemd 'service' file for it: https://domoticproject.com/creating-ras ... %20running. In which case it's output will go to /var/log/syslog or some other log file if you configure it.
3) Run it from screen or tmux as stated above. Basically they run a shell forever, that you can disconnect from without it dying, and you can reconnect to it later.
4) Why send all your programs data to the terminal on standard output. Typically I have such services that should run forever sending their data to an MQTT server, in the cloud or a local machine or even the same Pi, or some other messaging system. That server can then store the data for inspection later in files or a database. It can relay the data in real time to other machines if needed.
To have it run forever you could:
1) Run it from the nohup command: https://linux.101hacks.com/unix/nohup-command/ In which case it's output will go to some file that you can read when you log in again.
2) Run it as a 'daemon', a background service: Typically done by creating a systemd 'service' file for it: https://domoticproject.com/creating-ras ... %20running. In which case it's output will go to /var/log/syslog or some other log file if you configure it.
3) Run it from screen or tmux as stated above. Basically they run a shell forever, that you can disconnect from without it dying, and you can reconnect to it later.
4) Why send all your programs data to the terminal on standard output. Typically I have such services that should run forever sending their data to an MQTT server, in the cloud or a local machine or even the same Pi, or some other messaging system. That server can then store the data for inspection later in files or a database. It can relay the data in real time to other machines if needed.
Memory in C++ is a leaky abstraction .
Re: Find running .py again once disconnected (i.e. putty)
Thanks guys, all very helpfull!
Yes, it dos not make sense to sending output to screen forever, but sometimes I do need some breakout details and process flow during development. For better logging the essentials elsewhere as mentioned by Heater including nohup, mqtt, deamon etc as good info!
tmux was recommended by all..and that did the job! Never heard of it before!
Thanks again,
Adpi
Yes, it dos not make sense to sending output to screen forever, but sometimes I do need some breakout details and process flow during development. For better logging the essentials elsewhere as mentioned by Heater including nohup, mqtt, deamon etc as good info!
tmux was recommended by all..and that did the job! Never heard of it before!
Thanks again,
Adpi