Mixing
Multiple /etc/rc.local?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
3
down vote
favorite
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="rn*****" + " 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.
Help....Thanks...RDK
python pi-2 raspbian-stretch
asked 3 hours ago
RDK
437
add a comment |Â
up vote
3
down vote
favorite
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="rn*****" + " 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.
Help....Thanks...RDK
python pi-2 raspbian-stretch
asked 3 hours ago
RDK
437
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
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="rn*****" + " 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.
Help....Thanks...RDK
python pi-2 raspbian-stretch
asked 3 hours ago
RDK
437
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="rn*****" + " 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.
Help....Thanks...RDK
python pi-2 raspbian-stretch
python pi-2 raspbian-stretch
asked 3 hours ago
RDK
437
asked 3 hours ago
RDK
437
asked 3 hours ago
RDK
437
asked 3 hours ago
RDK
437
asked 3 hours ago
RDK
437
437
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
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 ;-)
answered 45 mins ago
Ingo
3,7172525
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
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 ;-)
answered 45 mins ago
Ingo
3,7172525
add a comment |Â
up vote
2
down vote
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 ;-)
answered 45 mins ago
Ingo
3,7172525
add a comment |Â
up vote
2
down vote
up vote
2
down vote
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 ;-)
answered 45 mins ago
Ingo
3,7172525
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 ;-)
answered 45 mins ago
Ingo
3,7172525
answered 45 mins ago
Ingo
3,7172525
answered 45 mins ago
Ingo
3,7172525
answered 45 mins ago
Ingo
3,7172525
3,7172525
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fraspberrypi.stackexchange.com%2fquestions%2f89540%2fmultiple-etc-rc-local%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password