Hi. I am using OpenWRT on a Netgear R7800. This works quite well so far. Today I connected a USB stick and it is also mounted during boot. After that I set the following.
config system
...
option log_file '/path/to/mylog'
From then on the log was written cleanly to the USB stick. Unfortunately this does not work after a reboot. As soon as I restart the log service, the logging to the file works again. Does anyone have an idea what I can do?
manually (re)start the logger in rc.local ?
Yes, that is my current workaround. Currently I have this in the rc.local:
logger "Restarting log service..."
logread >> /mnt/sda1/log/system.log
/etc/init.d/log restart
sleep 1
logger "Log service restarted."
This works to some extent, but doesn't feel right.
It's probably a race condition between the logger service and the mounter...
I think so too. How can I solve this?
I agree with @frollic .
Create a script that simply sleeps for a period of time (maybe 10-30 seconds) and then restarts the logger service. Then add that script to rc.local.
Yes. That is my current workaround. See Persistent logging to USB stick does not work after reboot - #3 by maik3k
right. The only change I'd recommned is that you move your workaround into another script and then call that script from rc.local (instead of having the script itself all inside rc.local).
The workaround is the only way to do this because you cannot guarantee when your storage is mounted vs when the logger service reads the desired log location. So simply restarting the logger service after the drive has mounted will solve the issue.
What's the S?? for the logger service in /etc/init.d ?
Might want to move it to S99 if it isn't already, could be good enough...
I am not sure I'd delay the startup of the logging service -- at least when it starts, it's logging to tmp space, so you can still see what is going on. If it is delayed, you wouldn't see the logs until much later -- possibly too late to catch something interesting that might need to be examined.
Sure, but you can always change it back, assuming it's a reoccurring issue.
That's true. But if restarting the logging service is a viable method of achieving the goal without compromising the early log data, why bother changing its start order (which, BTW, may or may not actually help -- the S number is specifically the start order, but there is no guarantee that the previous tasks have completed prior to next process starting).
Thanks for your help. I'll leave it like this for now.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.