status logs don't update correctly ?

Discussion in 'Tomato Firmware' started by Kobalt, Feb 3, 2014.

  1. Kobalt

    Kobalt Networkin' Nut Member

    This is a bit odd... right now, using the latest tomato shibby, syslog is stored on a flash drive, and looking at the file, all is correct there.

    However, looking at the routers links for the logs (last 25/50/100/ all) it shows something different, as if, it is just stuck there since the power went out. Already tried a reboot.
    Tried to restart syslogd as well, didn't help.

    In, other words, they don't sync up.

    I am wondering, how do I clear those logs, and resync them to the logs on the USB device ?

    For what it is worth, ls -l /tmp/var/log shows:
    lrwxrwxrwx 1 root root 33 Feb 2 22:05 messages -> /tmp/mnt/SamsungUSB/syslog/mylog
    -rw-r--r-- 1 root root 0 Dec 31 1969 nmbd.log
    -rw-r--r-- 1 root root 0 Dec 31 1969 smbd.log
    lrwxrwxrwx 1 root root 47 Dec 31 1969 syslog -> /tmp/mnt/SamsungUSB/log/syslog_1969-12-31_1900
    The link shows:

    I have no idea how to know what that is pointing to...
    Last edited: Feb 3, 2014
  2. darkknight93

    darkknight93 Networkin' Nut Member

    Maybe it's an issue with your browser caching the requested logfile via Web :s
  3. Kobalt

    Kobalt Networkin' Nut Member

    Thought of that already, and I used two different browsers as well.. didn't help.
  4. koitsu

    koitsu Network Guru Member

    The log shown under View All is actually just viewing the file /var/log/messages.

    How exactly did you get your /var/log/messages to be "redirected" via a symlink to an alternate place? Is this something you're doing in Scripts (ex. you have an ln -s entry in Init or something similar)?

    If so, then the explanation for what you're seeing is simple but there are two possibilities:

    a) The syslogd daemon is still logging to the actual /var/log/messages file (which your symlink overwrote), but the file descriptor in syslogd has not been re-opened since the symlink was put in place -- meaning, syslogd is now actually logging to a file/inode (in RAM) which will eventually exhaust (or possibly fix itself once the memory usage of the log region hits 50KBytes (default))

    b) The syslogd daemon is logging to where your symlink points, however at the time syslogd started, your actual USB devices' filesystem hadn't been mounted yet, so essentially the situation is the same as (a).

    The solution is quite simple: you need to send a SIGHUP to syslogd (ex. kill -HUP `pidof syslogd`), or do services syslogd restart, after the symlink is made.

    If you're using some kind of script to automatically change where the logs are written, then I recommend moving that away from Scripts and into an auto-mount script, which is a script that gets automatically run when the USB devices' filesystem is mounted. The file is called mount.autorun and is placed in the root directory of the USB devices' filesystem (ex. /tmp/mnt/whatever/mount.autorun) and the perms need to be 755 (if it's FAT/FAT32/NTFS then you may run into problems). Then inside of mount.autorun do the necessary steps to change /var/log/messages to what you need. Ex:

    # - Stop syslogd
    # - Copy contents of /var/log/messages to USB flash drive
    # - Symlink /var/log/messages to /tmp/mnt/whatever/syslog/mylog
    # - Start syslogd
    services syslogd stop >/dev/null
    cp -f /var/log/messages /tmp/mnt/whatever/syslog/mylog
    rm -f /var/log/messages
    ln -s /tmp/mnt/whatever/syslog/mylog /var/log/messages
    services syslogd start >/dev/null
    I should note log rotation probably won't work correctly, i.e. rotated logs will still end up in /var/log/ rather than /tmp/mnt/whatever/syslog/ like you'd (ideally) want them to.

    P.S. -- I have no idea what /var/log/syslog is. There is no such file on my router, but I use the stock logging settings for the most part.
    Last edited: Feb 3, 2014
  5. Kobalt

    Kobalt Networkin' Nut Member

    The symlinks were created when I chose the 'custom log file path' in settings.

    I suppose I can use a script to do this, but, I assumed that doing it via checking the above option in the settings menu would be the correct way to handle it, and since that is a symlink, I am trying to figure out why it is showing some dated from Dec 31 19:00:00 and not the current date.
    That is why I said that those links to view the logs, don't seem to be reading /var/log/messages, but, instead, reading ... something else.

    Doing killall syslogd then restarting it, should refresh everything as well, but that didn't work, so I am left scratching my head.
  6. koitsu

    koitsu Network Guru Member

    Ah, I wasn't aware the symlink method was how the actual "Custom Log File Path" feature worked. Thank you for educating me! I should have looked at the source first, honestly.

    The timestamp I can easily explain: it looks like your timezone is UTC-5, so I'm guessing EST. December 31st 1969 at 23:59:59 UTC is the start of the epoch in computing time. Computers, on a second-level, keep track of time since that point, i.e. 0 = January 1st 1970 00:00:00 UTC, 1 = January 1st 1970 00:00:01 UTC, etc..

    You can verify this yourself by doing the following (on Busybox the syntax is very very specific, argument order matters): date -u +%s -d 197001010000.00 (which should return 0, i.e. 0 seconds since the epoch), while date -u +%s -d 197001010000.01 would return 1 (1 second past epoch). Remove -u and you'll get the number of seconds of that time but in your own local timezone, etc...

    Routers do not have system clocks (a.k.a. RTC) like a standard PC does; they lack this circuitry, so when the router reboots or is power-cycled (either or, doesn't matter) it has no concept of what the current time is, thus the time starts at 0, hence the date you see. All routers behave this way (keep reading).

    It isn't until NTP properly syncs up the clock/date via some NTP servers (once your Internet connection is working) that the router actually knows what the proper time is.

    For validation of my statement, see here. This is from my own RT-N16 which I rebooted a few days ago when doing a firmware update, but my logs do rotate.

    root@gw:/tmp/var/log# ls -l /var/log/messages*
    -rw-r--r--  1 root  root  5359 Feb  4 00:34 /var/log/messages
    -rw-r--r--  1 root  root  51252 Feb  3 15:40 /var/log/messages.0
    root@gw:/tmp/var/log# cat /var/log/messages.0
    Dec 31 16:00:45 gw syslogd started: BusyBox v1.21.1
    Dec 31 16:00:45 gw user.notice kernel: klogd started: BusyBox v1.21.1 (2014-01-31 08:12:54 ICT)
    Dec 31 16:00:45 gw user.notice kernel: Linux version (root@tomato) (gcc version 4.2.4) #11 Fri Jan 31 08:17:02 ICT 2014
    Dec 31 16:00:45 gw user.warn kernel: CPU revision is: 00019740
    Dec 31 16:00:45 gw user.warn kernel: Determined physical RAM map:
    Dec 31 16:00:45 gw user.warn kernel:  memory: 07fff000 @ 00000000 (usable)
    Dec 31 16:00:45 gw user.debug kernel: Entering add_active_range(0, 0, 32767) 0 entries of 256 used
    Dec 31 16:00:45 gw kernel: Zone PFN ranges:
    Dec 31 16:00:45 gw user.warn kernel:  Normal  0 ->  32767
    Dec 31 16:00:45 gw user.warn kernel:  HighMem  32767 ->  32767
    Dec 31 16:00:50 gw kernel: kjournald starting.  Commit interval 5 seconds
    Dec 31 16:00:50 gw kernel: EXT3 FS on sda1, internal journal
    Dec 31 16:00:50 gw kernel: EXT3-fs: mounted filesystem with ordered data mode.
    Dec 31 16:00:50 gw hotplug[531]: USB ext3 fs at /dev/sda1 mounted on /tmp/mnt/usbflash
    Feb  1 15:22:37 gw ntpc[653]: Time Updated: Sat, 01 Feb 2014 15:22:37 -0800 [+1391296905s]
    Feb  1 15:22:38 gw user.debug dhcp6c-state[812]: 182: pptp peerdns disabled
    Feb  1 15:22:39 gw dnsmasq[562]: reading /etc/resolv.dnsmasq
    Feb  1 15:22:39 gw dnsmasq[562]: using nameserver
    Feb  1 15:22:39 gw dnsmasq[562]: using nameserver
    See how the time suddenly changes as a result of ntpc (NTP client) starting? If I was to reboot my router again the log would show the same thing, although because my logs are in RAM I'd lose them. In other words: /var/log/messages* (both files) would get lost, the router would come up with epoch time, then NTP would sync, then the time would be correct.

    It sounds more like syslog isn't logging anything to the log actively, or it's a file descriptor problem like I mentioned above, or maybe there's a permissions problem of some sort where the log file in question doesn't exist or has reached a particular capacity. I really don't know.

    As I stated before, the syslog symlink makes no sense to me; I have no such file on my router. smbd.log and nmbd.log are obviously Samba (I do not use this feature thus I have no such logs), and messages is a symlink to (hopefully) a file on your USB drive.

    I don't see anything wrong with the timestamp of the messages file itself. You'd need to expand/follow symlinks to know when the actual file (and not the symlink) was modified by using ls -lL /var/log/messages or ls -l
    (your choice).

    It sounds like syslogd isn't actually writing any logging at all; possibly I/O errors are being returned due to permissions problems. You'd need to provide full output from the following commands (yes really):

    ls -ld /
    ls -ld /tmp
    ls -ld /tmp/mnt
    ls -ld /tmp/mnt/SamsungUSB
    ls -ld /tmp/mnt/SamsungUSB/syslog
    ls -ld /tmp/mnt/SamsungUSB/syslog/mylog
    ps | grep syslogd
    ls -l /proc/`pidof syslogd`/fd
    That might shed some light on what's going on. Otherwise to debug it at a lower level you will probably have to install Entware along with lsof, strace, and a couple other utilities. This is easier to debug locally than it is remotely, but requires familiarity with software debugging on embedded environments.

    Also, can you please provide the exact filename of the firmware you're using? Maybe this is a bug that has since been fixed. Please don't provide whatever the About dialog in the GUI shows, please provide the actual firmware filename you're using.
  7. Kobalt

    Kobalt Networkin' Nut Member

    Well, updated shibby tomato to get the latest version that fixes heartbleed... and, it is the same issue.

    I enter a custom logfile to my USB flash drive in, and it is indeed working, I can cat the file.
    However, when using the GUI ( ) the log file, it shows the incorrect file.
    The last line in that file it shows is
    Jan  1 01:08:27 unknown user.notice kernel: klogd: exiting
    Jan  1 01:08:27 unknown syslogd exiting
    When I cat the symlink file (/tmp/mnt/SamsungBoot/syslog/mylnewog), the last line there shows
    May  1 14:33:27 mango ntpc[11465]: Time Updated: Thu, 01 May 2014 14:33:27 -0400 [-1s] 
    So, syslogd *is* writing it correctly.

    ps | grep syslogd shows
    10896 root      1588 S    syslogd -L -s 50 -O /tmp/mnt/SamsungBoot/syslog/myln
    11762 root      1588 S    grep syslogd 
    ls -l /proc/`pidof syslogd`/fd
    lrwx------    1 root     root            64 May  1 14:55 0 -> /dev/null
    lrwx------    1 root     root            64 May  1 14:55 1 -> /dev/null
    lrwx------    1 root     root            64 May  1 14:55 2 -> /dev/null
    lrwx------    1 root     root            64 May  1 14:55 3 -> socket:[194855]
    l-wx------    1 root     root            64 May  1 14:55 4 -> /tmp/mnt/SamsungBoot/syslog/mylnewog
    ls -l /tmp/var/log
    -rw-r--r--    1 root     root          2136 May  1 14:32
    drwx------    4 root     root            80 Dec 31  1969 cores
    lrwxrwxrwx    1 root     root            36 May  1 14:32 messages -> /tmp/mnt/SamsungBoot/syslog/mylnewog
    -rw-r--r--    1 root     root             0 Dec 31  1969 nmbd.log
    -rw-r--r--    1 root     root             0 Dec 31  1969 smbd.log
    lrwxrwxrwx    1 root     root            47 Dec 31  1969 syslog -> /tmp/mnt/SamsungBoot/log/syslog_1970-01-01_0100
    Doing cat /etc/syslogd.cfg
    5000 9 /tmp/mnt/SamsungBoot/log/syslog_1970-01-01_0100 
    and doing a cat of that file shows
    Jan  1 01:08:27 unknown user.notice kernel: klogd: exiting
    Jan  1 01:08:27 unknown syslogd exiting 
    So, I think that is the problem.

    That means, the new question is, why didn't the custom path fix this entry in the configure file ?
    I assume this is a bug, is it not ?

    Manually fixing that file to the correct link, and restarting syslogd does fix the problem.
    Last edited: May 1, 2014
  8. koitsu

    koitsu Network Guru Member

    Sounds to me like syslogd needs to start after the system has had a chance to sync time from an NTP server using ntpc (think ntpdate/rdate). The problem is that Tomato has no "clean" way of doing that -- there is no concept of init script order or dependency, etc.. OpenWRT would be a firmware which could (maybe even does) address this problem because it's more like a normal Linux distro and has init scripts and the like.

    I think about all you could do, to hack up a solution (and I stress the word hack), would be to possibly put something in the WAN Up scripts section that restarted syslogd when the WAN came up. However, that's probably not enough -- just because the WAN is up doesn't mean NTP has synced yet. The hackiest solution I could come up with would be this in WAN Up:

    sleep 15
    kill -HUP `pidof syslogd`
    I also don't think it's necessarily as simple as fixing the Tomato code to run ntpc (and wait until it finishes) + then run syslogd -- because there may be several seconds that pass before ntpc finishes and syslogd gets run, during which time syslog messages would be lost. Someone somewhere would probably bitch/cry about that.

    Starting to see the dilemma? It borders on chicken-and-egg, and it can really only get properly fixed if init scripts with dependencies were used, which isn't likely to happen on Tomato any time soon. OpenWRT would be a better contender for that. Tomato was never intended to be treated "like a Linux server", the hardware it's run on has significantly different limitations (lack of battery-backed RTC is one of them).
  9. Kobalt

    Kobalt Networkin' Nut Member

    While this started as a time issue, it became clear that, that wasn't the problem at all.

    The problem is, that after you enter in a custom log path/file, it doesn't update the correct files that actually point to the new custom log path/file.

    That means, that after you enter your data in and save your custom log path/file, it should then modify /etc/syslogd.cfg to point to that file that you specified, and restart syslogd.

    Then, going to the GUI and looking at the log should work correctly.

    Now, it doesn't modify /etc/syslogd.cfg so, it still shows the contents of the old logfile.
  10. jerrm

    jerrm Network Guru Member

    Tomato (and busybox syslogd) does not use syslogd.cfg or any other variation of a syslog config file.

    Where did the "syslog" link in /var/log come from, it is not an expected file.
  11. Kobalt

    Kobalt Networkin' Nut Member

    You sure about that ? shows syslog (default) for lots of things...

    As for the syslogd.cfg file,
  12. Kobalt

    Kobalt Networkin' Nut Member

  13. jerrm

    jerrm Network Guru Member

    Yes, I'm sure about busybox syslogd, it does not use a config file as stated in the busybox docs.

    As for the syslogd.cfg in the Tomato code, I see some old orphaned code in httpd.c and services.c from before the gui supported custom log file options, but it is now completely ignored in services.c if custom log is enabled in the gui, and appears mostly ignored even if the gui custom box is unchecked. Httpd.c still attempts to read the file location from it, but shouldn't.

    I can't consider it not working the way you want a bug. I would consider custom log file location completely nvram based with syslogd.cfg no longer supported. Any remnants of syslogd.cfg would be the bug.

    In a perfect world I guess backward compatibility would be nice, but it would be hard to justify the effort - the current behavior has been around since 2011 - over 2x longer than the prior syslogd.cfg behavior was alive. Have my doubts the syslogd.cfg code was without issues even if/when it worked.

    As for the issue at hand, I would remove all attempts at using syslogd.cfg and start over.
  14. Kobalt

    Kobalt Networkin' Nut Member

    I never set syslogd.cfg to begin with, I have no idea how, or what set it in the first place.
    The router only used Asus's firmware, and shibby's.
    All I know is, I found the issue that I was having, and a fix for said issue.
    If that code is deprecated, then it should be removed, since it has unwanted behavior, as can be seen in this thread.
  15. jerrm

    jerrm Network Guru Member

    Nothing in the Tomato code base creates the file. It has to be some script not of tomato origin. Most likely an automount or autorun script on the USB drive.
  16. koitsu

    koitsu Network Guru Member

    I concur with @jerrm -- at least with Toastman builds, there is no syslogd.cfg (or any file relating to syslog at all) in /etc. I can't speak for other firmware builds/types, but I also don't want to allude to anything by that statement -- I can only go off of what I can personally verify.
  17. Kobalt

    Kobalt Networkin' Nut Member

    I scanned the only flash drive I use, and there is nothing at all on the flash drive except the log files.
    Nothing else has ever been plugged into the router, and there is no remote access to it.
    I don't use any scripts either.

    I am stumped on how that file was made, the only thing I can think of, is, it is a remnant from the Asus firmware.
  18. jerrm

    jerrm Network Guru Member

    Did you look for dot files as well (ls -a)?

    The file has to be re-created every boot. The only non-script way I know of it's creation that could persist across flashes would be if nvram wasn't erased and the file had been saved to nvram using setfile2nvram or equivalent.
    Last edited: May 3, 2014
  19. koitsu

    koitsu Network Guru Member

    Yep. nvram show | grep -i syslog might be useful here (on stock Toastman, this returns no results), though it's not solely the only way something like that could end up in /etc. An autorun script when a drive gets mounted could do it, as well as something in the Scripts section and so on.

    If you wanna know what the firmware provides in its stock flash (although the code itself, of course, can always make new files in /etc (which is RAM after the system boots up)), then go look at /rom/etc. If you have a /rom/etc/syslogd.cfg then whatever firmware you're using definitely provided that file; if you don't then some piece of software is creating /etc/syslogd.cfg (which on TomatoUSB is technically /tmp/etc/syslogd.cfg because /etc becomes a symlink to /tmp/etc -- /tmp is RAM).
  20. Kobalt

    Kobalt Networkin' Nut Member

    Yeah, did that as well...

    That shows
    root@mango:/tmp/home/root#  nvram show | grep -i syslog
    Well, that shows
    root@mango:/tmp/home/root# ls /rom/etc
    ethertypes           motd                 services
    gcom                 openssl.cnf          usb_modeswitch.conf
    hotplug2.rules       profile              usb_modeswitch.d
    l7-protocols         protocols            vpn           resolv.conf
    So, nothing there...and all the shell scripts I see have nothing with syslogd.cfg in them.

    Here is where it gets interesting, doing this on / grep -r -i "syslogd.cfg" .
    shows this so far:
    grep: ./dev/log: No such device or address
    grep: ./dev/sdb: No medium found
    ./dev/sda1:echo "$PARAMS $FFN" >/etc/syslogd.cfg
    ./dev/sda1:rm -f /etc/syslogd.cfg
    ./dev/sda1:echo \"$PARAMS $LOGDIR/${FILNAM}\${EXPFN}\"  >/etc/syslogd.cfg; \
    ./dev/sda1:May  4 00:00:01 mango crond[19143]: crond: USER root pid 24967 cmd EXPFN=$(date +%F_%H%M) ; echo "5000 9 /tmp/mnt/SamsungBoot/log/syslog_${EXPFN}"  >/etc/syslogd.cfg; service logging restart ; ln -sf /tmp/mnt/SamsungBoot/log/syslog_${EXPFN} /var/log/syslog
    (still waiting for it to finish)
    However, I see no cron scripts on
    Last edited: May 4, 2014
  21. koitsu

    koitsu Network Guru Member

    You should stop the grep. Once it hit /dev it's going to go through the entire contents of every device (including disks), and on a disk this would take an extremely long time. Note this isn't looking at things from a per-file viewpoint (when iterating over the contents of /dev/sda1), but instead actually reading every 512 bytes (or maybe 4096 bytes), in a raw fashion, and returning matches -- so we have no idea what files are relevant.

    Looks to me like /dev/sda1 (which is a partition on your /dev/sda device, which is either going to be a USB drive, USB flash, SD, or something like that) is what contains some contents related to this problem. That's further verified by this (from one of your earlier posts):

    Dec 31 16:00:50 gw kernel: EXT3 FS on sda1, internal journal
    Dec 31 16:00:50 gw kernel: EXT3-fs: mounted filesystem with ordered data mode.
    Dec 31 16:00:50 gw hotplug[531]: USB ext3 fs at /dev/sda1 mounted on /tmp/mnt/usbflash
    That looks like where you have logs stored and some other stuff. But your grep results clearly show contents of a script of some kind that is creating /etc/syslogd.cfg and so on.

    So what you really need to do at this point, since we now see references to the creation of /etc/syslogd.cfg and other things on that drive, is grep -r -i /tmp/mnt/usbflash, which will show you the filenames that contain syslogd references, and reverse-engineer what is going on. My gut feeling is still that there's an automounter script, or possibly some daemon/something you're running on start-up, that is doing this. Whether or not it's "left over" from the Asus firmware has yet to be determined.

    If the above grep comes back with no results then I can explain why the first grep you did found results -- because as said, it's looking at the raw contents of the drive, which would contain files no longer used (deleted, etc. -- when you delete a file the contents on the disk are not zeroed out). In this case, my gut feeling would be that you might have some filesystem corruption on /tmp/mnt/usbflash and should fix that with proper use of fsck.ext3 (without the filesystem mounted, ex. fsck.ext3 -f /dev/sda1). Please don't run that command blindly however, take things one step at a time.

    And if that doesn't address the problem, then the next choice is to completely nuke the filesystem entirely by using mkfs.ext3 and start over from scratch. This is not the same thing (in this situation) as rm -fr, by the way.
    Last edited: May 4, 2014
  22. Kobalt

    Kobalt Networkin' Nut Member

    Dec 31 16:00:50 gw hotplug[531]: USB ext3 fs at /dev/sda1 mounted on /tmp/mnt/usbflash is a post from you, so, your router must be using that...

    OK, so grep found this in the logs:
    root@mango:/# grep -r -i "syslogd.cfg" /tmp/mnt/
    /tmp/mnt/SamsungBoot/syslog/mylnewog:May  4 00:00:01 mango crond[19143]: crond: USER root pid 24967 cmd EXPFN=$(date +%F_%H%M) ; echo "5000 9 /tmp/mnt/SamsungBoot/log/syslog_${EXPFN}"  >/etc/syslogd.cfg; service logging restart ; ln -sf /tmp/mnt/SamsungBoot/log/syslog_${EXPFN} /var/log/syslog
    /tmp/mnt/SamsungBoot/25-log-to-disk&.autorun:echo "$PARAMS $FFN" >/etc/syslogd.cfg
    /tmp/mnt/SamsungBoot/25-log-to-disk&.autorun:rm -f /etc/syslogd.cfg
    /tmp/mnt/SamsungBoot/25-log-to-disk&.autorun:echo \"$PARAMS $LOGDIR/${FILNAM}\${EXPFN}\"  >/etc/syslogd.cfg; \
    Hmm... 25-log-to-disk&.autorun ?
    Looking at that file, and some searching, it appears it came from

    That file has now been nuked.
    I still have no idea how it came to be there in the first place.
    -rwxr-xr-x 1 root root 3294 Dec 22 2012 25-log-to-disk&.autorun

    Is really odd, since I got the router (new) on Dec 12 2013, then flashed it with tomato on Dec 13 2013, and cleared NVRAM, and also cleared everything to default.
    The 64MB stick is at least 5-6 years old, and was with a pile of other USB flash drives. I am starting to suspect that it must have been used before for a router, but, my only other router was a wrt54G and that didn't have USB support.

    I didn't know that the router would autorun stuff on the USB flash drive, I always assumed it should be listed in one of the tabs in

    Thanks for your help (both of you) in finding the issue, it is greatly appreciated!
  23. koitsu

    koitsu Network Guru Member

    Re: /dev/sda: Oh crap, you're right. *sigh* Sorry, my mistake/fault!

    Ah ha! The culprit has be found! :D

    I think any files matching *.autorun in the root directory of the filesystem (possibly those with executable bit set, I think? I'd need to look at the code) will get automatically run by TomatoUSB when the filesystem is mounted. So yep, that explains it.

    I actually use this feature to create my /opt bind mount (and inhibit multiple bind mounts, since clicking Save in the GUI multiple times would actually cause this this to get re-run and Linux (idiotically!) will make multiple bind mounts with the same mountpoint, which causes all kinds of havoc) for use with Entware. The "logic" I have with grep -q /opt /proc/mounts deals with that situation. I'll include that here just for the hell of it. I call it mount.autorun (perm 755).

    # automount script for USB flash drives
    # USB flash drives:
    # Same situation, but the drive will be auto-mounted under
    # /tmp/mnt/{drivelabel}.
    # The drivelabel is generated during mkfs.ext3:
    # To format a drive:
    # mkfs.ext3 -L usbflash /dev/sda1
    # {refresh/save in TomatoUSB GUI}
    # tune2fs -c 0 /dev/sda1
    # {manually unmount/remount in TomatoUSB GUI}
    if /bin/grep -q /opt /proc/mounts
            /bin/umount /opt
            if [ $? -ne 0 ]; then
                    echo "umount failed, script not continuing"
                    exit 1
    /bin/mount -o bindable /tmp/mnt/usbflash /opt
  24. jerrm

    jerrm Network Guru Member

    A good example of why I shy away from .autorun files and usb/jffs/cifs based event scripts. I like to see anything that gets started in init. Scripts called from init may in turn create various event scripts under /etc/config, but there's always the reference in init. My version of koitsu's mount script is created from init as /etc/config/00.usbmount.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice