Opened 3 years ago

Closed 18 months ago

#1751 closed (worksforme)

Scripts in /jffs/etc/config do not seem to be executed.

Reported by: bga Owned by:
Keywords: Cc:

Description (last modified by frater)

I was reading the information here:

http://www.dd-wrt.com/wiki/index.php/Script_Execution

And there it says that to get scripts to run on startup and certain events, I just need to put them in some specific directory and be sure they were executable and with a specific extension and this would be enough. The problem is I can not get this to work.

I have an E3000 running Firmware: DD-WRT v24-sp2 (09/26/10) mega. I have a 2 Gb USB stick connected to the USB port and mounted directly to the /jffs mount point (selected through the web interface) and I have JFFS2 support enabled.

I put all my scripts in /jffs/etc/config:

root@Linksys E3000:/jffs/etc/config# ls -l 
-rwxr-xr-x 1 root root 49 Sep 30 20:09 test.ipdown 
-rwxr-xr-x 1 root root 49 Sep 30 20:09 test.ipup 
-rwxr-xr-x 1 root root 49 Sep 30 20:08 test.prewall 
-rwxr-xr-x 1 root root 49 Sep 30 20:09 test.sesbutton 
-rwxr-xr-x 1 root root 49 Sep 30 20:07 test.startup 
-rwxr-xr-x 1 root root 49 Sep 30 20:09 test.wanup 

As you can see all are set to be executable and every script has exactly the same contents (for testing purposes):

root@Linksys E3000:/jffs/etc/config# cat test.startup 
#!/bin/sh 
echo "$0 executed" >> /jffs/tmp/$0.out 

Executing any script manually does what is expected and creates an entry called [scriptname].out in /jffs/tmp that constains as many lines as the number of executions of the script.

To make a long story short. None of my scripts seem to be executed at all during boot.

Is this really a bug or am I missing something?


    

Change History (8)

comment:1 Changed 3 years ago by BrainSlayer

  • Resolution set to invalid
  • Status changed from new to closed

just one thing is missing. consider that the device is not already mounted when startup is executed. some scripts might work if the device is mounted at the time where these are executed. in addition. if you enable jffs support, the storage is already mounted using the internal free flash space and the jffs filesystem. it makes no sense to remount it with another disc/device. so if you are using this path for your own purpose, keep jffs support disabled and just use this directory as mountpoint

comment:2 Changed 3 years ago by bga

The E3000 with the mega package of DD-WRT seems to result in no space being left on the internal flash space. in any case, what I did with mounting the partition and enabling JFFS is what is described in yet another tutorial on the DD-WRT site:

http://www.dd-wrt.com/wiki/index.php/JFFS_File_System

It explicitly says that some functionality requires JFFS to be enabled and suggest doing what I did.

In any case, I take from your answer that there is no reliable way to have scripts in external storage (the Script tutorial also mentiosn that one could use /mmc/etc/config, which also falls in that category). is that correct? If so, would opening an enhancement ticket to request additional mass storage devices to be mounted early in the boot process worthwhile?

Thanks.

comment:3 Changed 3 years ago by bga

  • Resolution invalid deleted
  • Status changed from closed to reopened

I reinstalled DD-WRT now using the big version instead of the mega one and managed to get 500 Kb of free space for JFFS.

root@Linksys E3000:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                 5888      5888         0 100% /
/dev/mtdblock/4            704       196       508  28% /jffs
/dev/discs/disc0/part1
                       1927656     35996   1793736   2% /opt

I moved all my scripts to the now real JFFS partition and to the same place as mentioned in the original report (/jffs/etc/config). I rebooted the router now expecting the scripts to be executed but, again, none of them were.

If this is still expected behavior (due to the possibility that the JJFS partition was not mounted yet when the system tried to run relevant scripts) then it seems there is no way to run any scripts other than modifying the original firmware. If this is true, then it looks broken to me (and, also, the tutorial I mentioned is completely wrong).

I am reopening this due to what I said above.

comment:4 Changed 3 years ago by Eko

  • Resolution set to worksforme
  • Status changed from reopened to closed

Works here. Are your scrips executable? Set chmod to 777.

comment:5 Changed 3 years ago by bga

  • Resolution worksforme deleted
  • Status changed from closed to reopened

As show in the original report, yes. They are al set as executable just in case, here is how they ar at this exact moment:

root@Linksys E3000:/# ls -l /jffs/etc/config
-rwxr-xr-x    1 root     root           49 Oct  2 08:46 test.ipdown
-rwxr-xr-x    1 root     root           49 Oct  2 08:46 test.ipup
-rwxr-xr-x    1 root     root           29 Oct  2 09:35 test.prewall
-rwxr-xr-x    1 root     root           49 Oct  2 08:46 test.sesbutton
-rwxr-xr-x    1 root     root           30 Oct  2 09:34 test.startup
-rwxr-xr-x    1 root     root           49 Oct  2 08:46 test.wanup
root@Linksys E3000:/# mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
none on /dev type devfs (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
ramfs on /tmp type ramfs (rw)
devpts on /dev/pts type devpts (rw)
devpts on /proc/bus/usb type usbfs (rw)
/dev/mtdblock/4 on /jffs type jffs2 (rw)
/dev/discs/disc0/part1 on /opt type ext3 (rw,data=ordered)

I did a different test and just used the web interface to set my startup script to:

jffs/etc/config/test.startup >> /tmp/scripts.log 2>&1

And my firewall script to:

/jffs/etc/config/test.prewall >> /tmp/scripts.log 2>&1

And both scripts got executed as expected. They are simply not being executed automatically when present in /jffs/etc/config with the correct extensions.

Sorry for reopening the bug yet again but it still seems that there is a problem somewhere. If there is any way for me to debug what is happening on my side (like a way to turn on startup debugging) let me know and I will gladly try to track down what is happening.

Just out of curiosity, which one is the main init script in DD-WRT that starts everything up (and eventually result in the scripts mentioned being run)?

Thanks again for your patience on helping me sort this up.

comment:6 Changed 3 years ago by BrainSlayer

usually you have have a path problem within these scripts. consider that dd-wrt itself uses such startup scripts as well in /etc/config. /jffs/etc/config and mmc/etc/config is executed in the same way in the same place

comment:7 Changed 3 years ago by frater

  • Description modified (diff)

I am running several scripts that heavily depend on the mechanism to run these kind of scripts. These scripts run without any problems for months and I'm updating every month. I'm now using SVN 15280.

I'm using /tmp/etc/config

root@WAN:/tmp/etc/config# ls -l
total 4
lrwxrwxrwx 1 root root  24 Sep 26 18:15 0hammer.wanup -> /opt/etc/iptables.hammer
lrwxrwxrwx 1 root root  22 Sep 26 18:15 asia.prewall -> /opt/etc/iptables.asia
lrwxrwxrwx 1 root root  23 Sep 26 18:15 china.prewall -> /opt/etc/iptables.china
-rwxr-xr-x 1 root root 706 Sep 26 18:15 fixtables.wanup
lrwxrwxrwx 1 root root  23 Sep 26 18:15 world.prewall -> /opt/etc/iptables.world
root@WAN:/tmp/etc/config# cat asia.prewall
# bof
iptables -N SPAMasia
iptables -N asia
iptables -N DROPasia
iptables -F SPAMasia
iptables -F asia
iptables -F DROPasia
iptables -A DROPasia -j LOG --log-prefix "[asia DROP] : " --log-tcp-options --log-ip-options
iptables -A DROPasia -j DROP
iptables-restore -n </opt/etc/iptables.asia.rules
# eof

comment:8 Changed 18 months ago by LOM

  • Resolution set to worksforme
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.