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.
python pi-2 raspbian-stretch
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.
python pi-2 raspbian-stretch
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
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.
python pi-2 raspbian-stretch
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
python pi-2 raspbian-stretch
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
add a comment |Â
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
add a comment |Â
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 ;-)
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
add a comment |Â
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 ;-)
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
add a comment |Â
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 ;-)
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
add a comment |Â
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 ;-)
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 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
add a comment |Â
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
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
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