logfile rotation #2251
Comments
|
No, and we were reluctant of adding the option due to requests like these. |
|
I did not ask if syncthing could do log rotation. I asked if syncthing's -logfile option correctly deals with logfile rotation. i.e. if an external process does the equivalent of "mv logfile logfile.old" will syncthing correctly recreate the logfile or will it error out? Or what if the logfile is truncated, does syncthing correctly append to the current file position or does it blindly assume that its cached file offset is correct? syslog subsystems are great in theory. I can appreciate your frustration at some of these feature requests, but logging seems to be something that "stderr piped to syslog" seems only minimally equipped to handle. stderr is typically for errors, not general state logging. I don't want to tell you how to write your own software, but it seems pretty straightforward to write a logging subsystem that handles the logfile moving without resorting to signals and other cruft. Simply throwing out a logging capability for a process that is designed to run for long periods of time seems ... weak. |
|
Right, it's a different matter then. I haven't read the initial post properly. |
Neither, it'll continue writing to the fd it opened, like any other process. (Except maybe on Windows, where I have no idea what happens...) What's the proposed thing here? |
|
The proposed thing would be to have every log "write" be a "open+create+append, write, close" operation so that if the logfile moves, is truncated or otherwise changed syncthing would correctly deal with it. Most logfile rotators just move the file out of the way, but they have options to send signals or other crap that is probably less elegant to deal with than simply always opening the logfile for append, optionally creating it if it doesn't exist, writing what's needed, and closing the file afterward. There are slicker ways to do this but we're not writing a ton of data nor are we writing it quickly, so the "brute force" method mentioned above is simple, fast and os-agnostic. |
|
I think we use the stdlib log package, wonder how that deals with this. |
|
No, in this case we just open a file and write to it, so we could do that. |
calmh
added
enhancement
|
Technically, we need a new io.Writer type that does open+write+close on each write, but that's doable. (A log line is already a single write each) |
|
No no no! If you are not sending a signal to the process after you have rotated its log, you have done your log rotation wrong. If syncthing doesn't support that, then that's an RFE, but asking syncthing to do weird log writing because you forget to send a signal is madness. |
|
Hi I'm new in Github so sorry if I break your netiquette The logfile sudunly become obese. Up to 45 GB. I could not delete the file (or rotate, or truncate) because syncthing has a lock on it, so I had to stop syncthing, delete the log, and start again. Is there a simple way to limit the quantity of logging produced by syncthing? Then the problem came back. I decided that I could do without log for a while, and I check the logflag. But there is no "nolog" option. I tried to set the the logfile to "" or /dev/null but it did not work. So I used the logfile=-, and it did not work also : it still created a logfile (I should mention I also use the "no console" option) I tried to put the logfile read-only, but then syncthing would not start. Then I removed the no-console option, and put logfile=- but it stills create a log. So maybe there is a bug here. I launch it with wsh.Run and intWindowStyle=0, so maybe it is the lack of STDOUt that makes syncthing force log writing on default file even when I specify "-". So here are a few suggestions:
|
|
|
|
Hi Thank-you for your reply. I went back to my launch process (wsh.Run) and the problem was on my side. Now: I put logfile=- and it does not create a log. Still, no-logging is only a workaround. I would prefer to have a log that does not reach cyclopean volume. Am I the only one to report this issue? |
|
So far, yes. What's in the log? |
|
(I am using cygwin) $head syncthing.log [...] [AJZKU] 19:00:20 INFO: Puller: final: GetFileAttributesEx ?\d:\data\syncthing\partage-XXX...: Le chemin d’accès spécifié est introuvable. $ls -l syncthing.log $ls -lh syncthing.log $tail syncthing.log [AJZKU] 19:04:10 INFO: Puller (folder "partage_ABC", file "foo\bar\various file\les53-12-04-p1-bg.jpg"): dst stat dir: GetFileAttributesEx ?\d:\data\syncthing\partage-XXX...zmftn: Le chemin d’accès spécifié est introuvable. $tail syncthing.log I edited to remove the path and other personal info This is all that I have, I deleted the rest. |
|
Looks like it can't find a directory it expects. That's weird. You might solve this by creating it. There's a different bug somewhere in the tracker that triggers this by deleting a directory as it's being scanned/synced, that could be what's happened. |
|
Yes, probably I was reorganizing my directories on both ends when it happened. |
|
It looks like (at least for now) the expectation is that users will figure out logfile rotation themselves. That's fine – features aren't free – but I'm using the default installation on OS X (via homebrew) and just noticed this: -rw-r--r-- 1 rickb admin 5320509386 Oct 25 17:39 /usr/local/var/log/syncthing.log I know, a 5GB log begs the "why?" question, and I'm solving that separately. But if the app can log this much info, I'd like to put something in place to avoid unchecked growth going forward. Is there a standard recommendation for OS X users on how to get logfile rotation for syncthing? The included launchctl plist file just redirects output to that file – AFAICT there's no easy way to pipe through an intermediate process from within a launchctl plist specification. Barring anything clever, I suspect I'll just add a crontab command to launchctl unload -> rotate -> launchctl load, but I'd rather steal a clever solution than hack together a crappy one. |
|
Launchd sure seems a bit lacking in that department, yeah. |
Enable log rotation by automatically closing log file (fixes #2251)
|
@calmh Is this a solution for the current behavior under OS X/homebrew, where stdout and stderr are piped to The plist file is at the end of the formula here: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/syncthing.rb |
|
No, this is unrelated. Something needs to rotate those log files to stop them from growing forever. Possibly launchd already understands what to do when that happens, but someone needs to do it. |
|
Ok, thanks. So this has to be reported to homebrew, if I well understand. |
st-review
added
the
frozen-due-to-age
Does the -logfile option deal well with the file changing out from underneath syncthing?
The text was updated successfully, but these errors were encountered: