The content of this topic has been archived on 19 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.
Hello all,
After one week of utilisation, my router works fine. The reconnection is incredibly fast ! But something is bothering me.
The router crashes once 1-2 days. All connections are dropped, I tried to stay connected when it crashed but nothing. I must plug off the power and it works fine again for 24-48h hours (this is an average).
How can I debug that ? What can make this ?
Thank you and good evening.
wifi settings ? p2p usage ?
Hello Sonic,
1/ Wifi is off.
2/ I use p2p but the router crashes even if the PC aren't up.
Hello Sonic,
1/ Wifi is off.
2/ I use p2p but the router crashes even if the PC aren't up.
Not sure which router/firmware version you have. It sounds similar. In addition to Can't stay with AP in client mode, my Asus WL-500gP often crashed/rebooted regularly while running on Kamikaze 7.09-brcm-2.4.
I have it running on White Russian 0.9 now... even with dual WANs & port forwarding, it hasn't choked on my BT stress test.
I have some news. It seems that the router froze in a small time if I download at full speed (stressing situation for the router?). So I don't know what to do to debug.
Anyway I have a important information: When a task is scheduled in cron, the task won't be done. So is the router really frozen ? (Anyway I'm sure the router don't reboot when it crashes). But I don't understand why the LEDs on the router are blinking as usual?
Sorry I didn't give some informations about my configuration. It's a WAG354G (v1, AR7) Annexe B with Kamikaze built on first January 2008 (2.6.23.1 => r10074). I didn't compile the kernel myself. I use "atm-bridge" with pppoe to connect to the internet.
Hello, buildster. Should I try White Russian ? If so I don't know what headers must I put in the bin file. I need a little help or I need a ready bin file for my router.
Can I try somethings to debug or test ? It's perhaps another problem than freezing?
Thank you for the help.
PS: When I download at full speed, the CPU utilisation is less than 3%. MemTotal: 12724 kB; MemFree: 3568 kB at the moment, perhaps the RAM is missing ?
(Last edited by jamesbch on 29 Feb 2008, 21:59)
white russian doesn't support ar7 platform if I remember ...
white russian doesn't support ar7 platform if I remember ...
That is correct. Even kamikaze 7.09 does not support ar7.
*ouch* So I don't have the choice !
I have news, I downloaded a big file (not p2p but just one connection on a site) at full speed and the router crashed in 3h ! So now it's sure, something saturate.
I'm going to look at the memory or the CPU usage.
Any idea ?
(Last edited by jamesbch on 1 Mar 2008, 00:40)
You could install an snmp daemon and monitor the memory like that. Or maybe munin. Also if you dump the contents of /proc/slabinfo every minute and somehow get it to a pc (maybe with netcat) you could see what memory is being used. Also try logging to a remote syslog server.
I didn't know slabinfo, thank you. I sheduled a task: I use the http server that is already running to let me access pages with stats.
Perhaps can you spot a hungry process ?
root@OpenWrt:/www# ps
PID Uid VSZ Stat Command
1 root 2428 S init
2 root SW< [kthreadd]
3 root SW< [ksoftirqd/0]
4 root SW< [events/0]
5 root SW< [khelper]
25 root SW< [kblockd/0]
45 root SW [pdflush]
46 root SW [pdflush]
47 root SW< [kswapd0]
48 root SW< [aio/0]
64 root SW< [mtdblockd]
186 root SWN [jffs2_gcd_mtd3]
193 root 2428 S logger -s -p 6 -t
194 root 2428 S init
201 root 2440 S syslogd -C16
203 root 2420 S klogd
211 root 1144 S /sbin/hotplug2 --override --persistent --max-children
367 root SW< [acx_vlynq]
506 root 1680 S br2684ctl -b -c 0 -e 0 -a 8.35
513 root 2432 S crond -c /etc/crontabs
524 root 1944 S /usr/sbin/dropbear -p 22
539 root 2424 S httpd -p 80 -h /www -r OpenWrt
565 root 2568 S /usr/sbin/pppd plugin rp-pppoe.so mtu 1492 mru 1492 n
575 nobody 1280 S /usr/sbin/dnsmasq -K -D -y -Z -b -E -s lan -S /lan/ -
599 root 2016 S /usr/sbin/dropbear -p 22
600 root 2440 S -ash
861 root 2428 R ps
I'm monitoring at the moment and will come back with news.
I didn't know slabinfo, thank you. I sheduled a task: I use the http server that is already running to let me access pages with stats.
Yes, I suppose that's the easiest. This should work:
ln -s /proc/slabinfo /www
Then from a PC you can set up a cron job to download http://192.168.1.1/slabinfo every minute or 5 minutes or whatever. Then just see if anything stands out.
Perhaps can you spot a hungry process ?
I don't see anything obvious in your process list, but I wouldn't expect one of the processes to use up lots of memory when you download stuff. If something is leaking memory it will most likely be in the kernel.
Of course it might be something other than memory causing the problem...
Here is slabinfo before the crash and after I plug off and on the power to reboot the router:
[#] Sat Mar 1 20:00:01 UTC 2008
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
ip_fib_alias 11 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip_fib_hash 11 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
bridge_fdb_cache 3 59 64 59 1 : tunables 120 60 0 : slabdata 1 1 0
UNIX 8 10 384 10 1 : tunables 54 27 0 : slabdata 1 1 0
nf_conntrack_expect 0 0 136 29 1 : tunables 120 60 0 : slabdata 0 0 0
nf_conntrack 20 68 224 17 1 : tunables 120 60 0 : slabdata 4 4 0
jffs2_inode_cache 449 580 24 145 1 : tunables 120 60 0 : slabdata 4 4 0
jffs2_node_frag 1105 1160 24 145 1 : tunables 120 60 0 : slabdata 8 8 0
jffs2_refblock 287 330 252 15 1 : tunables 120 60 0 : slabdata 22 22 0
jffs2_tmp_dnode 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
jffs2_raw_inode 16 56 68 56 1 : tunables 120 60 0 : slabdata 1 1 0
jffs2_raw_dirent 0 0 40 92 1 : tunables 120 60 0 : slabdata 0 0 0
jffs2_full_dnode 1223 1421 16 203 1 : tunables 120 60 0 : slabdata 7 7 0
jffs2_i 250 260 304 13 1 : tunables 54 27 0 : slabdata 20 20 0
squashfs_inode_cache 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0
configfs_dir_cache 0 0 52 72 1 : tunables 120 60 0 : slabdata 0 0 0
kioctx 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
kiocb 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
fasync_cache 0 0 16 203 1 : tunables 120 60 0 : slabdata 0 0 0
shmem_inode_cache 55 55 360 11 1 : tunables 54 27 0 : slabdata 5 5 0
nsproxy 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
posix_timers_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
uid_cache 1 59 64 59 1 : tunables 120 60 0 : slabdata 1 1 0
UDP-Lite 0 0 480 8 1 : tunables 54 27 0 : slabdata 0 0 0
tcp_bind_bucket 3 203 16 203 1 : tunables 120 60 0 : slabdata 1 1 0
inet_peer_cache 8 59 64 59 1 : tunables 120 60 0 : slabdata 1 1 0
ip_dst_cache 26 60 256 15 1 : tunables 120 60 0 : slabdata 4 4 0
arp_cache 3 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
RAW 2 9 448 9 1 : tunables 54 27 0 : slabdata 1 1 0
UDP 4 8 480 8 1 : tunables 54 27 0 : slabdata 1 1 0
tw_sock_TCP 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCP 0 0 64 59 1 : tunables 120 60 0 : slabdata 0 0 0
TCP 4 6 1056 3 1 : tunables 24 12 0 : slabdata 2 2 0
eventpoll_pwq 0 0 36 101 1 : tunables 120 60 0 : slabdata 0 0 0
eventpoll_epi 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_ioc 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_queue 1 4 900 4 1 : tunables 54 27 0 : slabdata 1 1 0
blkdev_requests 4 22 180 22 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-256 2 2 3072 1 1 : tunables 24 12 0 : slabdata 2 2 0
biovec-128 2 2 1536 2 1 : tunables 24 12 0 : slabdata 1 1 0
biovec-64 2 5 768 5 1 : tunables 54 27 0 : slabdata 1 1 0
biovec-16 2 20 192 20 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-4 2 59 64 59 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-1 2 203 16 203 1 : tunables 120 60 0 : slabdata 1 1 0
bio 2 59 64 59 1 : tunables 120 60 0 : slabdata 1 1 0
sock_inode_cache 29 36 320 12 1 : tunables 54 27 0 : slabdata 3 3 0
skbuff_fclone_cache 0 0 384 10 1 : tunables 54 27 0 : slabdata 0 0 0
skbuff_head_cache 160 320 192 20 1 : tunables 120 60 0 : slabdata 16 16 0
file_lock_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
proc_inode_cache 112 112 280 14 1 : tunables 54 27 0 : slabdata 8 8 0
sigqueue 0 0 144 27 1 : tunables 120 60 0 : slabdata 0 0 0
radix_tree_node 76 78 288 13 1 : tunables 54 27 0 : slabdata 6 6 0
bdev_cache 2 10 384 10 1 : tunables 54 27 0 : slabdata 1 1 0
sysfs_dir_cache 1270 1296 52 72 1 : tunables 120 60 0 : slabdata 18 18 0
mnt_cache 16 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
inode_cache 210 210 264 15 1 : tunables 54 27 0 : slabdata 14 14 0
dentry 790 806 124 31 1 : tunables 120 60 0 : slabdata 26 26 0
filp 180 180 128 30 1 : tunables 120 60 0 : slabdata 6 6 0
names_cache 2 2 4096 1 1 : tunables 24 12 0 : slabdata 2 2 0
idr_layer_cache 52 58 136 29 1 : tunables 120 60 0 : slabdata 2 2 0
buffer_head 0 0 52 72 1 : tunables 120 60 0 : slabdata 0 0 0
mm_struct 27 27 416 9 1 : tunables 54 27 0 : slabdata 3 3 0
vm_area_struct 506 506 84 46 1 : tunables 120 60 0 : slabdata 11 11 0
fs_cache 29 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
files_cache 30 40 192 20 1 : tunables 120 60 0 : slabdata 2 2 0
signal_cache 36 36 416 9 1 : tunables 54 27 0 : slabdata 4 4 0
sighand_cache 32 32 3104 1 1 : tunables 24 12 0 : slabdata 32 32 0
task_struct 36 36 1072 3 1 : tunables 24 12 0 : slabdata 12 12 0
anon_vma 194 339 8 339 1 : tunables 120 60 0 : slabdata 1 1 0
pid 46 101 36 101 1 : tunables 120 60 0 : slabdata 1 1 0
size-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0
size-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0
size-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0
size-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0
size-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0
size-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0
size-65536 6 6 65536 1 16 : tunables 8 4 0 : slabdata 6 6 0
size-32768 4 4 32768 1 8 : tunables 8 4 0 : slabdata 4 4 0
size-16384 4 4 16384 1 4 : tunables 8 4 0 : slabdata 4 4 0
size-8192 38 38 8192 1 2 : tunables 8 4 0 : slabdata 38 38 0
size-4096 10 10 4096 1 1 : tunables 24 12 0 : slabdata 10 10 0
size-2048 138 172 2048 2 1 : tunables 24 12 0 : slabdata 86 86 0
size-1024 33 36 1024 4 1 : tunables 54 27 0 : slabdata 9 9 0
size-512 144 144 512 8 1 : tunables 54 27 0 : slabdata 18 18 0
size-256 45 45 256 15 1 : tunables 120 60 0 : slabdata 3 3 0
size-192 75 75 256 15 1 : tunables 120 60 0 : slabdata 5 5 0
size-128 226 240 128 30 1 : tunables 120 60 0 : slabdata 8 8 0
size-96 81 90 128 30 1 : tunables 120 60 0 : slabdata 3 3 0
size-64 479 600 128 30 1 : tunables 120 60 0 : slabdata 20 20 0
size-32 1377 1560 128 30 1 : tunables 120 60 0 : slabdata 52 52 0
kmem_cache 90 120 96 40 1 : tunables 120 60 0 : slabdata 3 3 0\n\r\n\r
And after
[#] Sat Jan 1 00:05:01 UTC 2000
labinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
ip_fib_alias 11 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
ip_fib_hash 11 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
bridge_fdb_cache 3 59 64 59 1 : tunables 120 60 0 : slabdata 1 1 0
UNIX 8 10 384 10 1 : tunables 54 27 0 : slabdata 1 1 0
nf_conntrack_expect 0 0 136 29 1 : tunables 120 60 0 : slabdata 0 0 0
nf_conntrack 23 34 224 17 1 : tunables 120 60 0 : slabdata 2 2 0
jffs2_inode_cache 449 580 24 145 1 : tunables 120 60 0 : slabdata 4 4 0
jffs2_node_frag 966 1015 24 145 1 : tunables 120 60 0 : slabdata 7 7 0
jffs2_refblock 287 300 252 15 1 : tunables 120 60 0 : slabdata 20 20 0
jffs2_tmp_dnode 16 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
jffs2_raw_inode 0 0 68 56 1 : tunables 120 60 0 : slabdata 0 0 0
jffs2_raw_dirent 0 0 40 92 1 : tunables 120 60 0 : slabdata 0 0 0
jffs2_full_dnode 1070 1218 16 203 1 : tunables 120 60 0 : slabdata 6 6 0
jffs2_i 234 234 304 13 1 : tunables 54 27 0 : slabdata 18 18 0
squashfs_inode_cache 0 0 320 12 1 : tunables 54 27 0 : slabdata 0 0 0
configfs_dir_cache 0 0 52 72 1 : tunables 120 60 0 : slabdata 0 0 0
kioctx 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
kiocb 0 0 160 24 1 : tunables 120 60 0 : slabdata 0 0 0
fasync_cache 0 0 16 203 1 : tunables 120 60 0 : slabdata 0 0 0
shmem_inode_cache 55 55 360 11 1 : tunables 54 27 0 : slabdata 5 5 0
nsproxy 0 0 24 145 1 : tunables 120 60 0 : slabdata 0 0 0
posix_timers_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
uid_cache 1 59 64 59 1 : tunables 120 60 0 : slabdata 1 1 0
UDP-Lite 0 0 480 8 1 : tunables 54 27 0 : slabdata 0 0 0
tcp_bind_bucket 3 203 16 203 1 : tunables 120 60 0 : slabdata 1 1 0
inet_peer_cache 1 59 64 59 1 : tunables 120 60 0 : slabdata 1 1 0
ip_dst_cache 54 60 256 15 1 : tunables 120 60 0 : slabdata 4 4 0
arp_cache 4 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
RAW 2 9 448 9 1 : tunables 54 27 0 : slabdata 1 1 0
UDP 4 8 480 8 1 : tunables 54 27 0 : slabdata 1 1 0
tw_sock_TCP 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
request_sock_TCP 0 0 64 59 1 : tunables 120 60 0 : slabdata 0 0 0
TCP 4 6 1056 3 1 : tunables 24 12 0 : slabdata 2 2 0
eventpoll_pwq 0 0 36 101 1 : tunables 120 60 0 : slabdata 0 0 0
eventpoll_epi 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_ioc 0 0 32 113 1 : tunables 120 60 0 : slabdata 0 0 0
blkdev_queue 1 4 900 4 1 : tunables 54 27 0 : slabdata 1 1 0
blkdev_requests 4 22 180 22 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-256 2 2 3072 1 1 : tunables 24 12 0 : slabdata 2 2 0
biovec-128 2 2 1536 2 1 : tunables 24 12 0 : slabdata 1 1 0
biovec-64 2 5 768 5 1 : tunables 54 27 0 : slabdata 1 1 0
biovec-16 2 20 192 20 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-4 2 59 64 59 1 : tunables 120 60 0 : slabdata 1 1 0
biovec-1 2 203 16 203 1 : tunables 120 60 0 : slabdata 1 1 0
bio 2 59 64 59 1 : tunables 120 60 0 : slabdata 1 1 0
sock_inode_cache 29 36 320 12 1 : tunables 54 27 0 : slabdata 3 3 0
skbuff_fclone_cache 0 0 384 10 1 : tunables 54 27 0 : slabdata 0 0 0
skbuff_head_cache 160 160 192 20 1 : tunables 120 60 0 : slabdata 8 8 0
file_lock_cache 0 0 96 40 1 : tunables 120 60 0 : slabdata 0 0 0
proc_inode_cache 98 98 280 14 1 : tunables 54 27 0 : slabdata 7 7 0
sigqueue 0 0 144 27 1 : tunables 120 60 0 : slabdata 0 0 0
radix_tree_node 70 78 288 13 1 : tunables 54 27 0 : slabdata 6 6 0
bdev_cache 2 10 384 10 1 : tunables 54 27 0 : slabdata 1 1 0
sysfs_dir_cache 1270 1296 52 72 1 : tunables 120 60 0 : slabdata 18 18 0
mnt_cache 16 30 128 30 1 : tunables 120 60 0 : slabdata 1 1 0
inode_cache 210 210 264 15 1 : tunables 54 27 0 : slabdata 14 14 0
dentry 711 713 124 31 1 : tunables 120 60 0 : slabdata 23 23 0
filp 180 180 128 30 1 : tunables 120 60 0 : slabdata 6 6 0
names_cache 2 2 4096 1 1 : tunables 24 12 0 : slabdata 2 2 0
idr_layer_cache 52 58 136 29 1 : tunables 120 60 0 : slabdata 2 2 0
buffer_head 0 0 52 72 1 : tunables 120 60 0 : slabdata 0 0 0
mm_struct 27 27 416 9 1 : tunables 54 27 0 : slabdata 3 3 0
vm_area_struct 506 506 84 46 1 : tunables 120 60 0 : slabdata 11 11 0
fs_cache 29 113 32 113 1 : tunables 120 60 0 : slabdata 1 1 0
files_cache 40 40 192 20 1 : tunables 120 60 0 : slabdata 2 2 0
signal_cache 36 36 416 9 1 : tunables 54 27 0 : slabdata 4 4 0
sighand_cache 32 32 3104 1 1 : tunables 24 12 0 : slabdata 32 32 0
task_struct 36 36 1072 3 1 : tunables 24 12 0 : slabdata 12 12 0
anon_vma 194 339 8 339 1 : tunables 120 60 0 : slabdata 1 1 0
pid 46 101 36 101 1 : tunables 120 60 0 : slabdata 1 1 0
size-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0
size-2097152 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0
size-1048576 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0
size-524288 0 0 524288 1 128 : tunables 1 1 0 : slabdata 0 0 0
size-262144 0 0 262144 1 64 : tunables 1 1 0 : slabdata 0 0 0
size-131072 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0
size-65536 6 6 65536 1 16 : tunables 8 4 0 : slabdata 6 6 0
size-32768 4 4 32768 1 8 : tunables 8 4 0 : slabdata 4 4 0
size-16384 4 4 16384 1 4 : tunables 8 4 0 : slabdata 4 4 0
size-8192 37 37 8192 1 2 : tunables 8 4 0 : slabdata 37 37 0
size-4096 10 10 4096 1 1 : tunables 24 12 0 : slabdata 10 10 0
size-2048 142 162 2048 2 1 : tunables 24 12 0 : slabdata 81 81 0
size-1024 34 36 1024 4 1 : tunables 54 27 0 : slabdata 9 9 0
size-512 144 144 512 8 1 : tunables 54 27 0 : slabdata 18 18 0
size-256 45 45 256 15 1 : tunables 120 60 0 : slabdata 3 3 0
size-192 75 75 256 15 1 : tunables 120 60 0 : slabdata 5 5 0
size-128 226 240 128 30 1 : tunables 120 60 0 : slabdata 8 8 0
size-96 90 90 128 30 1 : tunables 120 60 0 : slabdata 3 3 0
size-64 478 480 128 30 1 : tunables 120 60 0 : slabdata 16 16 0
size-32 1369 1380 128 30 1 : tunables 120 60 0 : slabdata 46 46 0
kmem_cache 90 120 96 40 1 : tunables 120 60 0 : slabdata 3 3 0
And here is what free told me: (before and after crash)
[#] Sat Mar 1 20:00:01 UTC 2008
total used free shared buffers
Mem: 12724 9936 2788 0 0
Swap: 0 0 0
Total: 12724 9936 2788
[#] Sat Jan 1 00:05:01 UTC 2000
total used free shared buffers
Mem: 12724 9368 3356 0 0
Swap: 0 0 0
Total: 12724 9368 3356\n\r\n\r
Any idea ?
(Last edited by jamesbch on 2 Mar 2008, 13:02)
I don't see anything obvious there.
Do you have a serial console hooked up to the router? If so, are there any errors printed on the console when it hangs?
Can you set up remote syslog and see if you get anything from that?
(e.g. Set up a syslogd on a Linux PC and configure it to allow the router to log to it. Then kill syslogd on the router and run "syslogd -R linux_pc_ip")
Then on the router, run "logger test" and see if you get a "test" message in the logs. If that works, wait to see if you get anything interesting when the router hangs.
No I haven't any console serial and I don't know how to use it either.
Can I with the -O option of syslogd log in a file instead of on a pc because I'm using syslog-ng on my Gentoo Linux. Does it change anything ?
Thank you Wodin.
Yes, you can log to a file instead, but then you will probably chew up space on your flash.
syslog-ng must surely be able to accept messages from a remote syslogd?
I tried syslogd -n to see the log at the screen but nothing appeared. I tried with -O option but nothing either.
It seems when this daemon is stopped once (killall...) it don't receive logs any more. 
Yes, you can log to a file instead, but then you will probably chew up space on your flash.
I think this isn't a problem I can cron a task to gzip it or delete it every hour.
OK, if I add "option type file" and "option file /path/to/messages" to /etc/config/syslog in the "config syslogd" section then it logs to a file. It does use the "-O" option to do it, though, so I don't know why it's not working for you.
843 root 1044 S /sbin/syslogd -s 16 -O /var/log/messages -SOf course I have it logging to /var/log/messages which is on a RAM fs. That would not be useful to you.
Wodin: /etc/config/syslog and /etc/init.d/syslog files are X-Wrt specific.
Plain OpenWrt starts syslogd in /etc/init.d/boot without the possibility to configure the local file and other enhanced options.
Wodin: /etc/config/syslog and /etc/init.d/syslog files are X-Wrt specific.
Plain OpenWrt starts syslogd in /etc/init.d/boot without the possibility to configure the local file and other enhanced options.
And this really is why X-Wrt should not be discussed here if you flashed their image or installed their webif as an package on top of OpenWrt. As you can see, X-Wrt changes too many things.
(Last edited by forum2008 on 5 Mar 2008, 22:29)
Whoops! I installed webif to have a look at it. I didn't realise it added its own /etc/config/syslog file.
However, doing it that way seems like the better long term option than starting syslogd from /etc/init.d/boot.
forum2008: What is the reason of your invectives against X-Wrt. It was not for the first time. Your reply is offtopic and you do not help the original user in solving his trouble in any case.
It is a project very close to OpenWrt. And basically it adds only a web interface. All system changes in X-Wrt are offered to OpenWrt. webif^2's developers are the first testers, it helps spreading OpenWrt.
And you know the reason why the syslogd config and scripts are not included in OpenWrt. I recently described it in the openwrt-devel mailing list.
Wodin has tried to help the original user. And because he described the way of configuring syslogd that is X-Wrt specific, I mentioned that it did not have to be available in the jamesbch's installation. It does not have any relation to the original problem.
I always route users in this forum to the X-Wrt forum when the problem is X-Wrt specific.
And my reply is offtopic as well. Other readers will perhaps forgive me.
Wodin: Thank you for helping other users.
Any new ideas ? It's not fixed yet.... What can I do ?
Thank you every one.
The discussion might have continued from here.