3

I run a Python program in a screen session which is started from my /etc/rc.local with this command:

su me -c "screen -d -m /usr/bin/python /mnt/usbdrive/pgms/mypgm.py"

Recently my program has been trapping an end of file situation which I have not yet figured out, but for that situation it would normally terminate with an EOF message. Since it is in a screen session, when it terminates the screen session also closes so I also miss any error messages on the screen but do have those which I write to a file.

Usually when this happens I can reboot or just manually restart the screen session and the program. It will run normally for hours, days, weeks,... or until the next EOF

While I'm trying to figure out the cause, I decided to implement a fix such that if the EOF situation is detected it saves a counter to a file and reboots: subprocess.call(["sudo", "shutdown", "-r", "now"]). If the program runs normally for a period that counter gets set back to 0, but if it continues to get the EOF error then after the 3-rd error in a row, I run the following code:

if int(data[3]) > 3:
  print "More than 3 EOF's in a row.  Forcing a restart but without starting the Python Pgm"
  pi = open('/mnt/usbdrive/Output/error.txt','a')
  wrtline="\r\n*****" + " More than 3 EOF's in a row.  Forcing a restart but without starting the Python Pgm" + time.strftime("%Y-%m-%d %H:%M:%S") + "\n"
  pi.write (wrtline)
  pi.close()
  shutil.move('/etc/rc.local', '/etc/rc.local.withpgm')
  shutil.move('/etc/rc.local.nopgm', '/etc/rc.local')  
  subprocess.call(["sudo", "shutdown", "-r", "now"])

where /etc/rc.local.nopgm is identical to the original rc.local except I have pound-ed out the line which starts the screen session.

OK, it works!!!!!

Except, when I go in via PUTTY using my id (me) and then sudo nano /etc/rc.local I see the original rc.local and not the one with the line pounded-out! If I go in via the console and look at the /etc/rc.local it has that line pounded out!

What's going on? It would appear that some how I have created two /etc/rc.local files. The changed one is run at bootup. The code with the shutil.move lines is being executed in the Python program in the screen session before the reboot.

4
  • so, without rebooting, i.e. at the very same point in time, you can see two different contents of /etc/rc.local when viewing using putty vs console? Commented Oct 2, 2018 at 0:07
  • yes, that is correct. When viewing from the console I see the one with the line starting the session and Python pgm pounded-out and from the Putty session I see the original file with the start line not pounded-out. All after the same reboot.
    – RDK
    Commented Oct 2, 2018 at 5:42
  • interesting, and you only have one raspberry pi? Commented Oct 2, 2018 at 5:44
  • I have several, but only one connected to a monitor and keyboard. And it was that one that I connected-to to swap the rc.local back to the "with pgm" settings and thus discovered it was already there. Subsequent visit via the console connection revealed the other rc.local.
    – RDK
    Commented Oct 2, 2018 at 7:51

1 Answer 1

5

You are running Raspbian Stretch and use /etc/rc.local. I don't have followed your attempts to find the error in detail but it seems you presume old style sequential behavior of rc.local for SysV init system. But you cannot do it since Raspbian Jessie, the predecessor of Raspbian Stretch. Since then SysV including rc.local is emulated by systemd that works parallel. The developer have taken much effort to emulate old style behavior but there are some restrictions. They have documented it in Compatibility with SysV. One point is:

Some SysV systems support an "rc.local" script that is supposed to be called "last" during boot. In systemd, the script is supported, but the semantics are less strict, as there is simply no concept of "last service", as the boot process is event- and request-based, parallelized and compositive. In general, it's a good idea to write proper unit files with properly defined dependncies, and avoid making use of rc.local.

Maybe it explains the unexpected behavior of your script and you should take it into account. Or you follow the suggestion of the developer ;-)

4
  • I don't see how the execution order of script can have an effect on the content of a file which is modified before rebooting. Commented Oct 1, 2018 at 18:17
  • @DmitryGrigoryev "... which is started from my /etc/rc.local" and "Recently my program has been trapping an end of file situation which I have not yet figured out ...". Wasn't that the situation? Do I have it misunderstood?
    – Ingo
    Commented Oct 1, 2018 at 18:27
  • I assumed the program was the python file, not /etc/rc.local, but to be honest I don't understand all aspects of the question either. Commented Oct 1, 2018 at 18:31
  • OK, simply, a Python pgm is started by the /etc/rc.local in a screen session. Regardless of the reason, I execute the two shutil.move lines to swap rc.localnopgm into rc.local and then initiate a reboot. After the reboot the new rc.local runs and does not start the Python pgm. The observation is that now I seem to have two different /etc/rc.local files. One observed from the console (no restart pgm) and the other (the original file starting the pgm) from a Putty session, both using the same logon id.
    – RDK
    Commented Oct 2, 2018 at 5:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.