Opened 11 years ago

Closed 11 years ago

#4009 closed Enhancement (invalid)

let transmission-daemon (et al?) use syslog; automatically use priorities for log-{prio}

Reported by: Astara Owned by:
Priority: Low Milestone: None Set
Component: Transmission Version: 2.20
Severity: Normal Keywords: needinfo
Cc:

Description

syslog provides a rich filtering & trigger environment. Rather than re-inventing the wheel and having options like --log-{error,info,debug}, have option to use syslog and it's priority levels, from low to high: debug, info, notice, warning, error, critical, alert, emergency. Info and Debug messages can go to their respective 'priorities', though some info messages might be considered for 'notice' (normal but significant condition) while error messages can be assigned to the remaining 4 levels. Note, levels are relative to the 'subsystem', otherwise they would be of limited usefulness. For example from a linux perspective, if you had "Windows ME" crash in a virtual machine, the might only be considered priority 'info' (next to lowest). Since that version of windows was the least stable version of Windows, to date, from a system perspective, it might not be considered that significant that it crashed again, though from the program's perspective, it might be of ALERT level priority or higher.

For transmission, EMERG, might be things that keep it from running or just as we are dying of a fatal signal (are those caught? -- never have seen one! but if it did, would be good to try to catch it and spit out some sort of traceback, if possible for a user to report).

ALERT might be if we are running out of (or already out of) disk space. In such a case, if it is in the logs, transmission could continue, but if it is in the data, then either transmission could either 1) stop all downloads & go into 'data-serving-only' mode, or 2) allow downloads to continue, but only for those files where space has already been allocated. Missing data could be 'critical or alert', corrupt data discovered on disk, probably 'error', corrupt data from a peer could be anything from 'warning', 'notice' or even 'info' depending on the frequency and how much the user cares. Etc...

Would suggest using system LOG_DAEMON if running as tr-d, and maybe LOG_USER if running as a user.

Changing the source to allow syslog besides allowing for a finer granularity in message sorting, can also allow for filtering informational and debug messages to a larger storage space while permitting important and more brief messages to go into the standard /var/log/transmission directory.

Clumping all of the messages into 1 file makes it hard to see error conditions -- AND most importantly, can easily fill up a limited space logging device.

At one point in time, it was considered prudent system practice to put different functions on different partitions, separating tmp from log from workspace. One of the reasons behind that was to make /var/log limited in size (<10G), to encourage archiving and to contain the log messages so aberrant log volumes would show up more quickly. With debug enabled with a busy 'trans-d', it's amazing how fast 6G of space can be used up. Fortunately, contained, it's a trivial recovery to copy it to a multi-terabyte work-disk where it can be examined, while allowing tr-d to get on with it's work (as well as the rest of the system).

Since this could be a 'gradual' effort and take some time, am setting the priority to 'low' as would see appropriate for a task that could be done on a 'background' basis....

Change History (6)

comment:1 Changed 11 years ago by jordan

syslog doesn't exist on Windows. And although it exists on OS X, it's an alien concept to most OS X users. I don't think it makes sense to use syslog in any of our GUI applications.

transmission-daemon already uses syslog as the default logging mechanism, so I don't understand youre request for transmission-daemon.

comment:2 Changed 11 years ago by jordan

  • Summary changed from RFE: SYSLOG: add option to transmission-daemon (et al?) for use; automatically use priorities for log-{prio}... to let transmission-daemon (et al?) use syslog; automatically use priorities for log-{prio}

comment:3 Changed 11 years ago by jordan

  • Keywords needinfo added

comment:4 Changed 11 years ago by Astara

I'm not seeing any log messages from transmission in my system log.

But this could be a cause where choosing one option in transmission affects has 'side-effects'...like running it in foreground so one can catch stdout and stderr messages into a log -- (cuz in background those messages don't get sent to syslog). Perfect example of a 'hole' in the logic. If you run in foreground, you don't get syslog, but if you want syslog, then you don't get debug messages....

It's not good to create side-effects in the option setting -- let background only control backgroun, not flipping on and off syslog and flipping on/off stdout/stderr.

What else is controlled by the background option that's not documented?

Make 1 option do 1 thing. But that aside, I don't have any messages in my system log from when it was in background either. Not sure why ... Maybe something else is screwed up in my setup...

I'll look into that -- but meanwhile, can we make the background switch ONLY put transmission in background and not make it affect the various output options? Please????

I'm loosing hair over this! ;-)

comment:5 Changed 11 years ago by jordan

If a logfile setting is specified on the command line or in settings.json, that logfile is used for logging messages. Otherwise if -f was specified, stderr is used. Otherwise, syslog is used.

So far you are the only person to report having a problem with this. I don't see the problem with the current approach.

comment:6 Changed 11 years ago by jordan

  • Resolution set to invalid
  • Status changed from new to closed

The issue is that a normal transmission-daemon run is fundamentally different than a debug run.

A debug run can generate a very high level of traffic that's inappropriate for syslog(), so it makes sense to handle that case differently IMO.

Closing this ticket as "invalid" since syslog() isn't a good match for the gui clients for reasons listed above, and isn't a good match for debugging sessions in transmission-daemon either, and is already used as the default logging system for non-debug transmission-daemon sessions.

Note: See TracTickets for help on using tickets.