Multiple /etc/rc.local?

The name of the pictureThe name of the pictureThe name of the pictureClash 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.










share|improve this question























  • 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?
    – Jaromanda X
    Oct 2 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
    Oct 2 at 5:42










  • interesting, and you only have one raspberry pi?
    – Jaromanda X
    Oct 2 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
    Oct 2 at 7:51

















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.










share|improve this question























  • 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?
    – Jaromanda X
    Oct 2 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
    Oct 2 at 5:42










  • interesting, and you only have one raspberry pi?
    – Jaromanda X
    Oct 2 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
    Oct 2 at 7:51













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.










share|improve this question















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.







python pi-2 raspbian-stretch






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Oct 1 at 19:49









goldilocks♦

43.7k1051162




43.7k1051162










asked Oct 1 at 13:46









RDK

467




467











  • 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?
    – Jaromanda X
    Oct 2 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
    Oct 2 at 5:42










  • interesting, and you only have one raspberry pi?
    – Jaromanda X
    Oct 2 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
    Oct 2 at 7:51

















  • 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?
    – Jaromanda X
    Oct 2 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
    Oct 2 at 5:42










  • interesting, and you only have one raspberry pi?
    – Jaromanda X
    Oct 2 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
    Oct 2 at 7:51
















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?
– Jaromanda X
Oct 2 at 0:07




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?
– Jaromanda X
Oct 2 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
Oct 2 at 5:42




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
Oct 2 at 5:42












interesting, and you only have one raspberry pi?
– Jaromanda X
Oct 2 at 5:44




interesting, and you only have one raspberry pi?
– Jaromanda X
Oct 2 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
Oct 2 at 7:51





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
Oct 2 at 7:51











1 Answer
1






active

oldest

votes

















up vote
4
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 ;-)






share|improve this answer




















  • 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.
    – Dmitry Grigoryev
    Oct 1 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
    Oct 1 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.
    – Dmitry Grigoryev
    Oct 1 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
    Oct 2 at 5:15










Your Answer





StackExchange.ifUsing("editor", function ()
return StackExchange.using("schematics", function ()
StackExchange.schematics.init();
);
, "cicuitlab");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "447"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















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






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
4
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 ;-)






share|improve this answer




















  • 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.
    – Dmitry Grigoryev
    Oct 1 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
    Oct 1 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.
    – Dmitry Grigoryev
    Oct 1 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
    Oct 2 at 5:15














up vote
4
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 ;-)






share|improve this answer




















  • 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.
    – Dmitry Grigoryev
    Oct 1 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
    Oct 1 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.
    – Dmitry Grigoryev
    Oct 1 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
    Oct 2 at 5:15












up vote
4
down vote










up vote
4
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 ;-)






share|improve this answer












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 ;-)







share|improve this answer












share|improve this answer



share|improve this answer










answered Oct 1 at 16:18









Ingo

3,8122526




3,8122526











  • 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.
    – Dmitry Grigoryev
    Oct 1 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
    Oct 1 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.
    – Dmitry Grigoryev
    Oct 1 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
    Oct 2 at 5:15
















  • 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.
    – Dmitry Grigoryev
    Oct 1 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
    Oct 1 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.
    – Dmitry Grigoryev
    Oct 1 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
    Oct 2 at 5:15















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.
– Dmitry Grigoryev
Oct 1 at 18:17




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.
– Dmitry Grigoryev
Oct 1 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
Oct 1 at 18:27




@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
Oct 1 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.
– Dmitry Grigoryev
Oct 1 at 18:31




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.
– Dmitry Grigoryev
Oct 1 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
Oct 2 at 5:15




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
Oct 2 at 5:15

















 

draft saved


draft discarded















































 


draft saved


draft discarded














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













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay