i followed the how-to to setup syslogd so that it writes to a remote system, in my case a computer hooked up to the wrt54gs. Now, how do i retrieve those logging messages? (I have set up syslogd -r on the linux system im using)

Usually the syslog log files are located in /var/log. See which file contains what (based on facility and priority) in /etc/syslog.conf.

Hi!

I got mines in /var/log/messages, /var/log/debug and /var/log/syslog

But, as Tornado said, it will depend on what the /etc/syslog.conf says.

Off course, you need to run syslogd -R IP in the wrt AND klogd (if you want to get kernel log).

If you want to test, just do a tail -f /var/log/messages in your PC, and a "logger Testing" in the wrt, you should see the message "Testing" in the logs of your PC.

useless note: as of yesterday's cvs changes, syslogd gets run at bootup. The arguments are set so it will store the last 16k of logs in memory, read using the logread command.

Would it be an idea to have some nvram parameter set to a remote syslog server, and have the startup script check against that to determine whether or not to log remote or locally?

Why would we want to use NVRAM ? We have a real file system ! We can use real configuration files, even configuration scripts.
Leave NVRAM to those poor Sveasoft users :-).

I guess you understood him wrong (or I did ).
He doesn't want to log *into* nvram. He just wants to put some parameters for the configuration of syslogd there.

Sure, I understood that.
But why would we use NVRAM to store configuration when we have a real filesystem available, that is more flash-friendly ?
The only use of NVRAM is for Linksys tools: wlconf uses it to set WEP keys, MAC filtering, etc., and the bootloader needs it to correctly configure some hardware components (and also for boot_wait !).
But why would we write a script that executes 'nvram get someparam' when it can as well do 'cat /etc/someparam.conf' ?
Once I understood that NVRAM is in fact nothing else than a fixed piece of the flash, without the advantages of a filesystem (wear-leveling, hierarchical access), I stopped touching it at all (except for wlconf parameters, et al), and all my customizations and configuration parameters go simply into one or more files on jffs.

So...  The nvram is just a part of the flash chip? or is it an *real* nvram mapped through the flash chip (this kind of flash chip can do that).  I sent that question to linksys yesterday, I'm wating for an answer.

Oh, by the way, if the nvram is only a part of the flash chip, then you should definetly use the jffs2 filesystem to store configs (say, modify the init script and add the -R parameter and a -L (to have local logging as well)).

nvram is a part of the 4/8MBytes flash. During boot, the kernel how the flash device is partitioned. Use dmesg to see it:

0x00000000-0x00040000 : "pmon"
0x00040000-0x007e0000 : "linux"
0x000e36d4-0x001b693e : "rootfs"
mtd: partition "rootfs" doesn't start on an erase block boundary -- force read-only
0x007e0000-0x00800000 : "nvram"
0x001c0000-0x007e0000 : "OpenWrt"

And a note about syslogging to flash - it's really not recommended. I log locally as well as remotely, but I log to /tmp rather than flash. Most of the time you only need messages since last boot, and if you do need messages before that, then check the remote syslog server.

Sure, nobody would even think about logging to flash.
The point is storing syslog's configuration for remote logging.
I just added

/sbin/syslogd -R myloghost -L

to /etc/init.d/S50services.
In the current version of OpenWRT, I think that syslogd is started from inittab, so /etc/inittab is the file that should be modified.

In the current version syslog gets started from /etc/init.d/S10boot.

And a note PolarWolf's post - it would be a nice thing. I prefer not to change init scripts that can (and do) get updated/modified whenever the author decides it should to look differently. It will save many a lot of copy/paste and headache.

The nvram stays untouched after a re-flash, and since syslog now gets started automatically, having this option set in nvram seems appropriate.

Better yet would be to put this info in /etc/nvram.overrides, or a similar file.
So everybody will be able to choose to configure its box by changing NVRAM or by patching a file...:-)

The idea was to have the remote log configuration stored somewhere, where it would not be overwritten by an upgrade of firmware.

Ideally, after an upgrade, you would run firstboot to make sure the new files in the firmware are symlinked automatically - if the new firmware size doesn't mess up the jffs2 filesystem, in which case you'll need to run firstboot anyway to erase jffs2 filesystem and redo it.

Running firstboot in both cases will erase /etc/nvram.overrides as ln is called with -f, so it's pointless to use a file on the jffs2 filesystem unless you like doing things over and over again each time you perform an upgrade.

As I said, you can map an "external" memory chip in an address group in the flash chip, without having that data "actually" written to the flash chip.

0x007e0000-0x00800000 : "nvram"

Ok, According to this mapping, there is one block of the flash chip reserved for the nvram, that means that the nvram can only take 100000 erase/write cycles.

The jffs2 filesystem does a more smart writing method, and for a wrt54gs the maximum writes (of less that 128kB) to the jffs2 is 4000000 (four million).

This is terrible (only 100000 for the "nvram").  I think that I'll try to implement my FRAM hack (uf, when I have the time, righ now have *many* things to do).