Joined: 05 Oct 2008 Posts: 651 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Mon Oct 24, 2022 18:28 Post subject:
Could it be the overall startup script length that's too big:
3824 bytes when nvram-save.sh still works, a few bytes more and it crashes.
I removed the dates from the first line and it worked.
I could add two dates, but not three before it crashed. (characters added by typing)
EDIT:
Later I added rc_firewall and rc_usb to the ini file.
Even though rc_firewall is longer and starts with the same kind of comment line as rc_startup, this didn't cause any segmentation fault.
Odd ...
Joined: 05 Oct 2008 Posts: 651 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Mon Oct 24, 2022 23:14 Post subject:
the-joker wrote:
you souldnt add useless stuff to scripts it all takes space in nvram, spacing and such and new lines all should be one line for ultimate space saving. It also makes script size smaller.
OK. I get it. However, comments are helpful for the human administering it all.
So ... the way to go is to store all scripts in /jffs or /opt ...
Thanks.
An automatic backup of /jffs and /opt has been arranged in the mean time.
EDIT:
all 4 scripts moved to /jffs successfully ... router boots, looks normal ...
nvram backup size went down by about 20% from 51 kB to 41 kB.
No shebangs in the scripts btw. Never had ...
Is that OK?
The syslog doesn't show any logger command output now.
Maybe better read the script file like in
< /jffs/whatever
Last edited by ArjenR49 on Tue Oct 25, 2022 0:30; edited 1 time in total
Joined: 05 Oct 2008 Posts: 651 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Tue Oct 25, 2022 0:26 Post subject:
the-joker wrote:
Its easier to run the script with debug bash|sh -x <scriptname> You also have set -x or set +x and further you have -v which can be done as bash|sh -xv <scriptname>
Later I added rc_firewall and rc_usb to the ini file.
Even though rc_firewall is longer and starts with the same kind of comment line as rc_startup, this didn't cause any segmentation fault.
Odd ...
I was subscribed to the busybox mailing list for a while. There was quite a bit of traffic from users trying to run scripts that worked on other platforms and were failing on busybox. For nvram-save.sh, these dd-wrt scripts are just data to save/restore like any other variable.
My gut feeling is the segmentation fault is a lower level bug in busybox not nvram-save.sh. A buggy script shouldn't segfault.
Adding rc_custom, rc_firewall and rc_usb to the sample ini file in the easyddup package sounds like a good idea.
Joined: 05 Oct 2008 Posts: 651 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Tue Oct 25, 2022 13:56 Post subject:
So I tried with all 4 command scripts on /jffs.
At first it looked like the router worked OK, but is was already past 2 a.m. and I wasn't too sharp.
The troubles showed up in the morning:
My startup script has commands for a virtual LAN and the VLAN broke.
I had to put that handful of commands (starting with swconfig, vconfig and brctl) back into the GUI.
The rest is still in the script which resides on /jffs, but it doesn't look like it's working, either.
Later I noticed my firewall rules to accommodate the virtual LAN etc. were obviously not in action. So I had to put those back into the GUI, too.
At the moment only the shutdown and USB scripts reside on /jffs and are called in the GUI.
It remains to be seen if they actually work this way, unlike the firewall script. It doesn't cause immediate havoc when they don't.
The command I call the scripts with is of this form:
/jffs/command_scripts/<script name>
I tried with
< /jffs/command_scripts/<script name>
as well. Can't tell if there was a difference.
Either the way I call the scripts is wrong, or it cannot work that way, which I doubt.
Are you sure your storage is up and ready when the scripts get run? I've had this as my first startup command for ages. I think people have something better these days if you search the forums.
I tried adding a bunch of that fateful comment to the beginning of my startup script to make it 6790 bytes and couldn't get nvram-save.sh to segfault. What's your dd-wrt build number and busybox version shown when logging in at the terminal in case busybox has fixed this already? Also dd-wrt has recently removed windows CRLF line endings from multi-line variables in favor of linux line endings so no more Ctrl-M's.
Can you PM me a zipped startup script that causes segfaults?
Joined: 05 Oct 2008 Posts: 651 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Wed Oct 26, 2022 21:58 Post subject:
I haven't been able to find out why the first line in my startup script, a comment line, caused the recurring Segmentation fault when running nvram-save.sh, so I took it out.
In order to save nvram, I attempted to move all scripts from the GUI to /jffs, but ran into trouble. Probably tried to change too much at once.
After going back to all command scripts in the GUI, and based on experience gained along the way, I did away with the usb script, moving its essence to the startup script.
Moving all of the startup script to a file on /jffs didn't work, but moving the last part, which only contains the code to mount USB drives to fixed mounting points by UUID, is apparently ok being called from the GUI startup command window as a script on /jffs.
Setting up a VLAN, changing cpu governor settings, waiting for /opt to be mounted, setting dnsmasq.leases to be written to /jffs and starting rc_unslung, seem best to be left in the GUI startup window.
Moving all of the firewall script to /jffs is OK, as far as I have been able to check.
All of the shutdown script is still in the GUI. It contains code to stop rc_unslung, unmount /jffs and /opt and finally do a check with automatic repair of the file system of these two partitions with e2fsck.
/jffs and /opt reside on a USB thumbdrive which has a tendency to develop faults in its file systems. I use to check them on a Linux Mint system every now and then. The disks utility says there are faults. The repair is said to be unsuccessful, but a renewed check turns up a clean fs.
The check with e2fsck in the shutdown script is an attempt to correct these faults automatically, but in reality I don't know when the shutdown script runs. Likely not when it matters most, namely when cutting power to the router.
There's a logout button the the GUI of recent builds, but no shutdown button for a clean powering down.
The way to call a script on /jffs from the GUI command window, that works best for me, is like this:
/jffs and /opt reside on a USB thumbdrive which has a tendency to develop faults in its file systems. I use to check them on a Linux Mint system every now and then. The disks utility says there are faults. The repair is said to be unsuccessful, but a renewed check turns up a clean fs.
The check with e2fsck in the shutdown script is an attempt to correct these faults automatically, but in reality I don't know when the shutdown script runs. Likely not when it matters most, namely when cutting power to the router.
My shutdown script in the GUI starts with the following so I can track when it runs.
I solved the faults on the thumbdrive by buying good USB storage that can run ext4 and journaling.
ArjenR49 wrote:
There's a logout button the the GUI of recent builds, but no shutdown button for a clean powering down.
That sounds like a good enhancement request for creating a ticket. I've got an alias in my .profile so I can clean power down. I also have one for reboot.
Code:
"alias shutdown='cd;startservice run_rc_shutdown'
ArjenR49 wrote:
The way to call a script on /jffs from the GUI command window, that works best for me, is like this:
sh /jffs/<directory>/<script>.sh
Maybe if your scripts had a shebang they'd run from the GUI without the sh prefix.
Joined: 05 Oct 2008 Posts: 651 Location: Helsinki, Finland / nr. Alkmaar, Netherlands
Posted: Thu Oct 27, 2022 10:48 Post subject:
yoyoma2 wrote:
ArjenR49 wrote:
/jffs and /opt reside on a USB thumbdrive which has a tendency to develop faults in its file systems. I use to check them on a Linux Mint system every now and then. The disks utility says there are faults. The repair is said to be unsuccessful, but a renewed check turns up a clean fs.
The check with e2fsck in the shutdown script is an attempt to correct these faults automatically, but in reality I don't know when the shutdown script runs. Likely not when it matters most, namely when cutting power to the router.
My shutdown script in the GUI starts with the following so I can track when it runs.
Great tip! I applied it immediately. When I rebooted the router I could see afterwards that rc_showdown ran.
I solved the faults on the thumbdrive by buying good USB storage that can run ext4 and journaling.
I have some M2 SSD's in USB enclosures that I could use, but it feels like overkill. The thumbdrive I use is just 2GB and is plenty big at that ... You can't get them so small anymore. I'd rather keep the M2's for my Raspberry Pi's ...
ArjenR49 wrote:
There's a logout button the the GUI of recent builds, but no shutdown button for a clean powering down.
That sounds like a good enhancement request for creating a ticket. I've got an alias in my .profile so I can clean power down. I also have one for reboot.
Code:
"alias shutdown='cd;startservice run_rc_shutdown'
Now that I've got shutdown script 'tracking' I must try the logout function, although I don't suppose it run the shutdown script.
I know about the alias thing per se. I haven't used aliases myself and I don't know about .profile. I suppose it must be a file in the R7800 router that maybe I can edit in an ssh session ??
Having a shutdown command sounds very sensible.
ArjenR49 wrote:
The way to call a script on /jffs from the GUI command window, that works best for me, is like this:
sh /jffs/<directory>/<script>.sh
Maybe if your scripts had a shebang they'd run from the GUI without the sh prefix.
It should work like that, too, and it probably does, but considering all the malfunctioning that came down upon me when I tried to change too much at the same time, I figured I leave it at calling with sh when I got back in control of the router ...
I tried bash, too, because I know there are essential differences in syntax, and I thought I may have used some in a script, but it looked like the command windows can't use bash even though it has been installed, I think. While the router is starting up or shutting down, it is hard to tell what is available and when from USB memory, like /opt and /jffs.
One of my reasons to use dd-wrt is that I have hundreds of hours of effort in it, so if one day I need a new router, I hopefully can switch without another hundreds of hours of work on a different GUI/OS.
I am sorry this post is a bit messy. I've got a BT keyboard problem. The cursor suddenly jumps elsewhere sometimes. The keys are too close together. It's hard to use. The laptop's own keyboard is malfunctioning, dropping some keys.
