pythonsshpycharmscreenpyserial

PyCharm remote deployment with screen affects serial interface


I have a flask app.py that I'm developing on my local machine.

The flask app uses a serial interface (pyserial) that is connected to a remote machine.

I setup PyCharm for remote deployment on the remote machine.

When I deploy and run the app remotely (from my local machine) I want to launch it inside a detached screen so that I can disconnect from SSH if needed.

To do this, I wrote this simple python script detach_app.py:

import sys
import subprocess
import shlex

command = "/opt/homebrew/bin/screen -S flask -d -m " + sys.executable + " app.py"
command = shlex.split(command)
subprocess.Popen(command, start_new_session=True)

When in PyCharm I remote deploy detach_app.py it runs app.py in a screen and detaches the screen. It also assigns the screen to a new session so that it becomes the child of the init process and doesn't get shut down when the python script ends.

This works well because if I need to check on the process later on I just SSH into the machine through a terminal in PyCharm and do screen -r flask.

However, I'm experiencing a weird issue where the serial interface is misbehaving when I launch app.py through this method. In particular a device would be able to open the serial port but it would only send empty strings.

Note that this behavior doesn't happen if:

  1. I remotely deploy app.py
  2. I locally launch app.py by itself or through screen
  3. I remotely deploy detach_app.py but instead of using screen I use nohup

It seems the serial interface issue is caused by a combination of screen and PyCharm remote deployment. I'm aware that this is a far fetched question but I'm really struggling to understand what would be the next thing to try to investigate the problem.

Does anybody have any pointer for this?


Solution

  • After some more in depth debugging I discovered that the issue was only related to pyserial and MacOS and had nothing to do with screen.

    In particular I noticed that the issue of reading a blank usb reply was happening exactly after 1 minute of exiting a VNC connection.

    I then suspected that the OS was going in sleep and deactivating tty for some reason, even if I had set it up to never go to sleep.

    I launched the command pmset -g and noticed these two lines

    sleep                1 (sleep prevented by screensharingd, powerd)
    ttyskeepawake        1
    

    man pmset has more details on how ttyskeepawake and sleep interact but if you notice, screensharingd (VNC) prevents the OS from going to sleep. When VNC is exited, it takes one minute for it to go to sleep.

    I modified the settings using the command sudo pmset -a sleep 0 and my current full status is:

    System-wide power settings:
     Currently in use:
     standby              0
     Sleep On Power Button 1
     autorestart          0
     SleepServices        0
     powernap             0
     networkoversleep     0
     disksleep            0
     sleep                0 (sleep prevented by screensharingd, powerd)
     ttyskeepawake        1
     displaysleep         0
     tcpkeepalive         1
     lowpowermode         0
     womp                 1