A possible little bug in pup 1.03 rc.local0. If a modified rc.local exists (calling wireless and firewall scripts for example), the find procedure in rc.local0 fails and it overwrites rc.local with the standard file. I've fiddled a bit but haven't yet gotten it right yet. a ls shows the files existing prior to the test, making the path more explicit (/root/.etc/rc.d/rc.local) works every time in a simple test script but the test still fails in rc.local0. for now, I'm just calling my own rc.local_xxx. 1.01 didn't test, just ran rc.local.
Happily back to kernel 2.4.27 for now. Love the multisession pup the best.
1.03: rc.local not working right
1.03: rc.local not working right
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
i haven't had any problems with rc.local
i often modify mine ... it's a convenient place to put your modifications, even if they don't really belong there
it doesn't look like rc.local should ever be touched, except by rc.local0, which will create a new file but only if the file does not exist
if [ ! -f /etc/rc.d/rc.local ];then
is the line that checks if rc.local exists or not ... it seems ok to me
if there is no symlink linking /etc to /root/.etc it won't find the file ... but it won't overwrite the old rc.local file either
i read somewhere (in the files for a major program ... mplayer? xmms? bash?) some advice about making scripts, and one of the things it suggested was to always use -r to test for files ... which makes sense, because if the file is not readable, it probably isn't going to be useful anyway
one thing about rc.local ... the PATH and LD_LIBRARY_PATH are not setup in rc.local to use the my-applications dir ... if you try to run programs from rc.local that are in my-applications, it probably won't work unless you setup the paths and export them first
i don't know why it's doing that ... do you have an older version of rc.update in rc.d?
i often modify mine ... it's a convenient place to put your modifications, even if they don't really belong there
it doesn't look like rc.local should ever be touched, except by rc.local0, which will create a new file but only if the file does not exist
if [ ! -f /etc/rc.d/rc.local ];then
is the line that checks if rc.local exists or not ... it seems ok to me
if there is no symlink linking /etc to /root/.etc it won't find the file ... but it won't overwrite the old rc.local file either
i read somewhere (in the files for a major program ... mplayer? xmms? bash?) some advice about making scripts, and one of the things it suggested was to always use -r to test for files ... which makes sense, because if the file is not readable, it probably isn't going to be useful anyway
one thing about rc.local ... the PATH and LD_LIBRARY_PATH are not setup in rc.local to use the my-applications dir ... if you try to run programs from rc.local that are in my-applications, it probably won't work unless you setup the paths and export them first
i don't know why it's doing that ... do you have an older version of rc.update in rc.d?
It remains a puzzler. This is a multisession built on the 1.03 barebones so rc.update is current. Symlink is there and working correctly. If I build a test script using
if [ ! -f /etc/rc.d/rc.local ];then
..
..
it works exactly as expected, finds rc.local, and runs it correctly, starting up my ndiswrapper based RT2500 wireless card and setting up my NAT/firewall.
What seems to be exactly the same 4 or five lines at the end of rc.local0 fails to find rc.local and regenerates it.
My patch works fine, just a puzzle.
if [ ! -f /etc/rc.d/rc.local ];then
..
..
it works exactly as expected, finds rc.local, and runs it correctly, starting up my ndiswrapper based RT2500 wireless card and setting up my NAT/firewall.
What seems to be exactly the same 4 or five lines at the end of rc.local0 fails to find rc.local and regenerates it.
My patch works fine, just a puzzle.
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.
