Page 1 of 1

Confusion with /etc/rc.local

Posted: Tue Oct 02, 2018 7:02 am
by RDK
I have a Python pgm which is started in a screen session by the /etc/rc.local.

Code: Select all

su me -c "screen -d -m /usr/bin/python /mnt/usbdrive/pgms/mypgm.py"
Regardless of the reason, in the Python pgm I execute the two shutil.move lines to swap rc.local.nopgm into rc.local and then initiate a reboot. rc.local.nopgm is identical to the original rc.local except the above command is commented out.

Code: Select all

  shutil.move('/etc/rc.local', '/etc/rc.local.withpgm')
  shutil.move('/etc/rc.local.nopgm', '/etc/rc.local')  
  subprocess.call(["sudo", "shutdown", "-r", "now"])
After the reboot the new rc.local runs and does not start the Python pgm which is what I wanted. Seems like a happy ending.

What I did not expect is that now I seem to have two different /etc/rc.local files. One observed when I logon from the console (the no restart pgm version). The other from a Putty session (the original version which starts the pgm). Both using the same logon id and both within the same reboot.

Can anyone explain what is going on and how to fix it?....Thanks....RDK

OK, I've read that rc.local is now depreciated, but still runs. And that one should start using systemd, which seem to me to be a very complicated process for replacing something simple, but I digress...

Re: Confusion with /etc/rc.local

Posted: Tue Oct 02, 2018 8:22 am
by mfa298
RDK wrote:
Tue Oct 02, 2018 7:02 am
OK, I've read that rc.local is now depreciated, but still runs. And that one should start using systemd, which seem to me to be a very complicated process for replacing something simple, but I digress...
rc.local has always been the quick hacky way to start things at boot, previously the correct way to start and stop things was via an init.d script (which usually weren't that nice to write and even worse to debug.

The advantages you get with a systemd service file is that you can easily start/stop/restart your application as well as enable/disable whether it starts at boot all with some simple commands (no more moving files around*). Systemd can also monitor your applications and restart them if they crash.

There is a bit of a learning curve in getting started (although it might be a bit better than when I first started looking at systemd) but once you've written one or two systemd services it gets easier.

---
* consider if you had two things you wanted to control whether they start at boot by moving rc.local files around - you now have 4 possible configs, add a 3rd program and there's 8 combinations.

Re: Confusion with /etc/rc.local

Posted: Tue Oct 02, 2018 12:21 pm
by RDK
@mfa298.....OK, but this totally avoids the meat of my posting: why am I seeing/ why have I created two rc.locals and what can I do about it?...RDK

Now to your comments, the goal of my code was to prevent the screen session and associated Python pgm from starting automatically after a reboot. I'm willing to use systemd if there is a way from my Python pgm to do the same thing and then later from a ssh/Putty session to reverse the situation....RDK

Re: Confusion with /etc/rc.local

Posted: Tue Oct 02, 2018 12:34 pm
by mfa298
RDK wrote:
Tue Oct 02, 2018 12:21 pm
@mfa298.....OK, but this totally avoids the meat of my posting: why am I seeing/ why have I created two rc.locals and what can I do about it?...RDK

Now to your comments, the goal of my code was to prevent the screen session and associated Python pgm from starting automatically after a reboot. I'm willing to use systemd if there is a way from my Python pgm to do the same thing and then later from a ssh/Putty session to reverse the situation....RDK
I'm struggling to work out what your actually trying to do.

So you have a program that runs at reboot, moves from rc.local files around so it doesn't start at reboot and then reboots the system ?
If you don't want it to start at boot why are you putting it into rc.local in the first place ?

This is reminding me of a Useless Box (https://www.youtube.com/watch?v=aqAUmgE3WyM)

Re: Confusion with /etc/rc.local

Posted: Tue Oct 02, 2018 2:19 pm
by RDK
OK, :)

This is a program monitoring a continuous process, like for example the weather. The program posts data to a database. It can run for days, weeks, months without any issues. However, it does fail on occasion. In that case I trap the error and I don't want the program to restart during the next reboot or until I have had a chance to examine the posted data and/or the error messages. After that time I revert the rc.local to automatically restart the program on reboot, power failure, etc.

I hope this gets me out of the "useless box" category....RDK

Re: Confusion with /etc/rc.local

Posted: Fri Oct 05, 2018 5:44 am
by RDK
OK now that we have discussed the merits (or lack thereof) for using rc.local, can anyone comment on the meat of my original question?...RDK

Re: Confusion with /etc/rc.local

Posted: Fri Oct 05, 2018 9:56 am
by thagrol
Rather than manipulating rc.local on a failure I'd do it this way:
  • When a failure is detected, write a 0 byte file to a known localtion.
  • In rc.local check if said file exists and only start your script if it does not.
Alternatively you could make the first thing your python code does is to check for that file and exit if it's found.

Re: Confusion with /etc/rc.local

Posted: Fri Oct 05, 2018 10:51 am
by epoch1970
thagrol wrote:
Fri Oct 05, 2018 9:56 am
[*]When a failure is detected, write a 0 byte file to a known localtion.
/var/tmp is a good place for that, this location persists across reboots.

I can't see any way 2 "normal" shells would give a different view of the filesystem at the same instant. I hope your .profile or .bashrc does not execute /etc/rc.local when a login session starts... That could account for a file flip-flop post boot, but still not for parallel reality.

Re: Confusion with /etc/rc.local

Posted: Fri Oct 05, 2018 2:21 pm
by RDK
Thanks for the ideas. I'll give it some thought....RDK

Re: Confusion with /etc/rc.local

Posted: Fri Oct 05, 2018 2:35 pm
by DougieLawson
epoch1970 wrote:
Fri Oct 05, 2018 10:51 am
thagrol wrote:
Fri Oct 05, 2018 9:56 am
[*]When a failure is detected, write a 0 byte file to a known localtion.
/var/tmp is a good place for that, this location persists across reboots.
/var/log is better because /var/tmp just like /tmp gets wiped out at every boot and daily (based on the rules in /etc/tmpfiles.d/*.conf or /run/tmpfiles.d/*.conf or /usr/lib/tmpfiles.d/*.conf).

Re: Confusion with /etc/rc.local

Posted: Fri Oct 05, 2018 3:48 pm
by thagrol
DougieLawson wrote:
Fri Oct 05, 2018 2:35 pm
epoch1970 wrote:
Fri Oct 05, 2018 10:51 am
thagrol wrote:
Fri Oct 05, 2018 9:56 am
[*]When a failure is detected, write a 0 byte file to a known localtion.
/var/tmp is a good place for that, this location persists across reboots.
/var/log is better because /var/tmp just like /tmp gets wiped out at every boot and daily (based on the rules in /etc/tmpfiles.d/*.conf or /run/tmpfiles.d/*.conf or /usr/lib/tmpfiles.d/*.conf).
Yep. But it can be anywhere you want within reason. Just make sure that a. it isn't on tmpfs and b. doesn't get cleared daily or at boot up.

Re: Confusion with /etc/rc.local

Posted: Fri Oct 05, 2018 7:15 pm
by mfa298
DougieLawson wrote:
Fri Oct 05, 2018 2:35 pm
epoch1970 wrote:
Fri Oct 05, 2018 10:51 am
/var/tmp is a good place for that, this location persists across reboots.
/var/log is better because /var/tmp just like /tmp gets wiped out at every boot and daily (based on the rules in /etc/tmpfiles.d/*.conf or /run/tmpfiles.d/*.conf or /usr/lib/tmpfiles.d/*.conf).
Are you sure about that?

Traditionally /tmp would be cleaned out regularly (weekly and/or on boot are common) and could often be mounted in ram. So isn't ideal for this sort of task. Similarly /var/run and /run (one is often a symlink to the other) isn't ideal as that's usually cleared at boot and/or mounted in ram.

However /var/tmp is normally cleaned out manually and should be on disk so would be more than suitable and is likely to be the best choice. It would also have suitable permissions for any task to write to (where other folders like /var/log might not).


To help you in answering:

Code: Select all

pi@raspberrypi:~ $ grep -E "var/(log|tmp)" /usr/lib/tmpfiles.d/*
/usr/lib/tmpfiles.d/journal-nocow.conf:h /var/log/journal - - - - +C
/usr/lib/tmpfiles.d/journal-nocow.conf:h /var/log/journal/%m - - - - +C
/usr/lib/tmpfiles.d/journal-nocow.conf:h /var/log/journal/remote - - - - +C
/usr/lib/tmpfiles.d/systemd.conf:z /var/log/journal 2755 root systemd-journal - -
/usr/lib/tmpfiles.d/systemd.conf:z /var/log/journal/%m 2755 root systemd-journal - -
/usr/lib/tmpfiles.d/systemd.conf:z /var/log/journal/%m/system.journal 0640 root systemd-journal - -
/usr/lib/tmpfiles.d/systemd.conf:a+ /var/log/journal    - - - - d:group:adm:r-x
/usr/lib/tmpfiles.d/systemd.conf:a+ /var/log/journal    - - - - group:adm:r-x
/usr/lib/tmpfiles.d/systemd.conf:a+ /var/log/journal/%m - - - - d:group:adm:r-x
/usr/lib/tmpfiles.d/systemd.conf:a+ /var/log/journal/%m - - - - group:adm:r-x
/usr/lib/tmpfiles.d/systemd.conf:a+ /var/log/journal/%m/system.journal - - - - group:adm:r--
/usr/lib/tmpfiles.d/tmp.conf:#q /var/tmp 1777 root root 30d
/usr/lib/tmpfiles.d/tmp.conf:x /var/tmp/systemd-private-%b-*
/usr/lib/tmpfiles.d/tmp.conf:X /var/tmp/systemd-private-%b-*/tmp
/usr/lib/tmpfiles.d/var.conf:d /var/log 0755 - - -
/usr/lib/tmpfiles.d/var.conf:f /var/log/wtmp 0664 root utmp -
/usr/lib/tmpfiles.d/var.conf:f /var/log/btmp 0600 root utmp -

Re: Confusion with /etc/rc.local

Posted: Fri Oct 05, 2018 7:28 pm
by DougieLawson
Oh sorry, you're right. My /var/tmp folders were full of ancient junk (gone now). I thought it worked like /var/mail and /var/spool/mail being a symbolic link.

Re: Confusion with /etc/rc.local

Posted: Sat Oct 06, 2018 6:27 am
by RDK
Folks.....Thanks for all of the good ideas. I'll put a file in /var/tmp, but first I'll clean it out:

Code: Select all

sudo find /var/tmp/ -mindepth 1 -delete
....RDK

Re: Confusion with /etc/rc.local

Posted: Thu Oct 11, 2018 8:13 am
by RDK
Folks......Geez, this was a much simpler idea. My way was way too complicated and, apparently, prone to system issues. I'm now creating a file instead of swapping out the rc.local files and using that file to prevent the Python program from restarting.

Thanks again for showing me the error in my ways.....RDK