Log file location
Log file location
How do I change the location of the log file in linux? I would like the DVR storage drive to sleep when recordings are not happening. I checked the log file and periodically status messages get written to it. If the location cannot be changed, can the "log level" be changed to exclude status messages?
-
signcarver
- Expert
- Posts: 8640
- Joined: Wed Jan 24, 2007 1:04 am
- Device ID: 131B34B7 13231F92 1070A18E 1073ED6F 15300C36
Re: Log file location
Thats the whole point of having those messages as the dvr engine requires that the drive not spin down as too often a drive won't spin up fast enough when the engine needs to use it.
Re: Log file location
But I think that's the point. I don't care if it spins up too late. I would rather miss the first 30s than have it spun up.
Regardless using a log to keep the drive awake also an improper solution.
WMC had the proper solution for a dedicated box. That was to sleep the system then wake up 5 min prior to any recording and also leave enough time to not re-sleep if an upcoming recording was within its wake window. For shared boxes the solution should be to wake the drive 'n' time intervals in advance to allow the drive to spin up. Requiring a log to keep the drive awake is ridiculously inefficient. Furthermore if the drive should stay awake for whatever reason (hardware issue, kernel, driver, etc.) that responsibility should fall on the user; its easy enough to disable sleep on drives and/or use a utility to keep drives awake.
There should be an option to redirect the log file with the caveat that it would fall upon the user to understand if recordings were late. This is assuming a solution to poke the drive in advance was not implemented by SD. Otherwise I can see no reason this option should not exist. Adding the log file location to the config file is a 5min coding job.
Regardless using a log to keep the drive awake also an improper solution.
WMC had the proper solution for a dedicated box. That was to sleep the system then wake up 5 min prior to any recording and also leave enough time to not re-sleep if an upcoming recording was within its wake window. For shared boxes the solution should be to wake the drive 'n' time intervals in advance to allow the drive to spin up. Requiring a log to keep the drive awake is ridiculously inefficient. Furthermore if the drive should stay awake for whatever reason (hardware issue, kernel, driver, etc.) that responsibility should fall on the user; its easy enough to disable sleep on drives and/or use a utility to keep drives awake.
There should be an option to redirect the log file with the caveat that it would fall upon the user to understand if recordings were late. This is assuming a solution to poke the drive in advance was not implemented by SD. Otherwise I can see no reason this option should not exist. Adding the log file location to the config file is a 5min coding job.
Re: Log file location
Solved.
First, I checked to make sure the binary didn't have any hidden log file options. And it does not.
Next, I just pre-emptively symlinked a bunch of empty log files to my log location and let the server write to the symlinked location. No issue. Drive goes to sleep. I'm going to explore using the API to periodically gather all scheduled recordings and write a utility to poke the drive in advance of each record start time. Looks like I can also intercept http requests to recording_events sync and determine when something is updating the recording list and update my poke scheduler accordingly.
I don't know what the rules are. But I'll post a link to the util when I'm done if allowed.
First, I checked to make sure the binary didn't have any hidden log file options. And it does not.
Next, I just pre-emptively symlinked a bunch of empty log files to my log location and let the server write to the symlinked location. No issue. Drive goes to sleep. I'm going to explore using the API to periodically gather all scheduled recordings and write a utility to poke the drive in advance of each record start time. Looks like I can also intercept http requests to recording_events sync and determine when something is updating the recording list and update my poke scheduler accordingly.
I don't know what the rules are. But I'll post a link to the util when I'm done if allowed.