Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Truncating logfile is difficult #16

Open
niko opened this issue Jan 5, 2012 · 2 comments
Open

Truncating logfile is difficult #16

niko opened this issue Jan 5, 2012 · 2 comments

Comments

@niko
Copy link

niko commented Jan 5, 2012

I don't know if that's an issue but I noticed that truncating the logfile (the redirected STDOUT) doesn't work, at least the way expected. When doing

echo '' > out.log
ls -l out.log

ls still shows the old filesize. df shows the diskspace being freed. The logfile contains somehow invisible characters. It seems the open file should be rewinded or seek the beginning again. I work around this with this code at the moment:

Signal.trap('USR2'){ STDOUT.truncate 0 ; STDOUT.rewind }

To reproduce see https://gist.github.com/1564418

@DAddYE
Copy link
Owner

DAddYE commented Jan 24, 2012

Hey, sorry for my late reply, yep, what about logrotate?

@niko
Copy link
Author

niko commented Feb 1, 2012

I don't know what logrotate does exactly. I suppose it moves the old file an expects the process to then write to the new file. But for that the process must repoen the file otherwise the process continues to write to the old file. unicorn does this for example on USR1 (see http://unicorn.bogomips.org/SIGNALS.html). The problem is that trapping a signal overrides old traps. So just using one signal (say USR1) could collide with app specific traps. I've no idea how to solve this in a general way. :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants