I need to rotate a file in HP-UX of a application. I�ve tried to do a task in the cron with a script (with sed and ed commands) but it was a successfully option (the application continued writing the file )
but with this option, it seems like nothing is written into file out until the whole file has been finally processed (yeah, this is a problem).
I have read that a option is to use stdbuf like this:
We use 'logrotate' on our systems. standard on the linux systems. Available for HP-UX at hpux .connect .org.uk. (would have posted link but forum wouldn't let me.
Thanks nzle, but i have tried logrotate and it doesn�t work. The problem is that my aplplications is continuosly running the same file...logrotate does something like:
1.- mv <fileorigin> <filecopy>
2.- gzip <filecopy>
3.- create a new <fileorigin>
In the step 3, my application can not write yet in the <fileorigin>...
1.-
5127 Oct 30 09:52 RmiService.stdout
2.-
1610 Oct 30 09:52 RmiService.stdout-20131030.gz
0 Oct 30 09:54 RmiService.stdout
If you move the file, the writing will continue in the moved file...
I either stop the writing ( daemon ...) and restart or if cannot, do:
mv file.last file.beforelast
cp -p file file.last
> file # zero the file...
#gzip if you wish:
put in a script so it is executed flawlessly so I have less loss possible and choose a moment I know with minimum risk of activity to execute the code...
Sorry vbe, but if i understand that you write, it does not work
5127 Oct 30 11:42 RmiService.stdout
mv RmiService.stdout RmiService.stdout.bak
5127 Oct 30 11:42 RmiService.stdout.bak
cp -p RmiService.stdout.bak RmiService.stdout
5127 Oct 30 11:42 RmiService.stdout
5127 Oct 30 11:42 RmiService.stdout.bak
> RmiService.stdout
5127 Oct 30 11:42 RmiService.stdout.bak
0 Oct 30 11:44 RmiService.stdout
--- Apliccation writes in this moment
0 Oct 30 11:44 RmiService.stdout
5485 Oct 30 11:44 RmiService.stdout.bak --> It�s using this...
or----
5127 Oct 30 11:50 RmiService.stdout
cp -p RmiService.stdout.bak RmiService.stdout.bak2
5127 Oct 30 11:50 RmiService.stdout
5127 Oct 30 11:50 RmiService.stdout.bak
> RmiService.stdout
5127 Oct 30 11:50 RmiService.stdout.bak
0 Oct 30 11:56 RmiService.stdout
--- Apliccation writes in this moment
5127 Oct 30 11:50 RmiService.stdout.bak
5485 Oct 30 11:57 RmiService.stdout --> It�s using this...
In the last code the problem is the size os the file...that will be 358 (5485-5127)...
In my script you move the LAST backup that means if you have one..., NOT the active fille that is called "file" in my example the active file is the one you copy and nul after
5127 Oct 30 13:38 RmiEcpService.stdout
cp -p RmiEcpService.stdout RmiEcpService.stdout.bak
>RmiEcpService.stdout
5127 Oct 30 13:38 RmiEcpService.stdout.bak
0 Oct 30 13:38 RmiEcpService.stdout
-- Application writes in this moment
5127 Oct 30 13:38 RmiEcpService.stdout.bak
5483 Oct 30 13:38 RmiEcpService.stdout
.....and the same before...the problem is the size os the file...that will be 358 (5485-5127)...
Im missing somthing here, you nulled your file and it wrote in it after, so it works!
But maybe that isnt what you wanted... What is it we are not getting? You should try to describe more your issue, here it seems unclear what isnt giving you satisfaction ( what has size got to do?)
I use this methis for sensible logs in /var/adm... but your extension makes me doubt terribly on the usage
Yeah, the application writes it, but the size of the file does not decrement. This file has 8GB in Production right now (2 months) and i want to rotate it each 100Mb. With your solution, we have a backup each day (for example) of 100Mb. Yeah, it�s fine...but the original file keeps the size :s....100MB first day...200MB second day...It have 0MB at the moment of i nulled...but at the next time application writes it....the size return to be the original size.
logrotate implements what vbe is describing using the 'copytruncate' option in the configuration file.
Alternatively, I have used the mv command to rename the logfile, after which the app continues writing to the renamed file, until I 'kill -1 PID' the process id of the parent application process, which causes it to close the log and start writing a new one
@nzle: Ive explained in post#4 the move issue and workaround if you cannot stop the process writing to it...
We were thinking your file was a log, if it isnt the case, things can be far more tricky, for we dont know the content...
Depending what its possible you have no other choice but to stop and create a new one...
So what applicationis this and what is the file for?
Well yes there is something strange for a log is a continuous output from a process which doesnt normally look back at what it already has written like it seems to be the case with your file
What is in the file? what is tis format? ( So we can try to figure out something...)
have you tried nzle's suggestion from #10 with the 'kill -1 PID' suggestion?
Maybe the app writing to the long will catch an interrupt and act accordingly...
Worth a try (not knowing the internals of the app).
What I dont understand is if the file is zeroed ( >file ) how come it the next minute be greater than previously...
I just remebered that in 11.11 you have in SAM: "Routine tasks>Sytem log files " the possibilty by clicking on the menu Action to add to list and configure...
What about trying?
Is your log "per line"?
And Yes I would give a kill -1 a try... it doesnt always work but if it does...
You must update (restart, kill -HUP, ...) your application.
Read your application documentation.
Even logrotate would need such an action; a pre-rotate or post-rotate action.
man open
tells that the O_APPEND flag in open() jumps to the end of the (with the old file size) prior to every write.
That's incorrect. Before each write(), O_APPEND sets the descriptor's offset to the current end of file. If a file opened with O_APPEND is truncated to 0 size, the next write would see that and would place its bytes at the beginning of the file.
What we're seeing here is the absence of O_APPEND. Truncation does not affect the offsets of open file descriptions, so, without O_APPEND, writes continue where they had been located before truncation; file size is restored with null bytes replacing what had been truncated.
Allister describes the exact problem. I cannot modify the application code and i try to find a solution with a script rotate (not possible if i don�t modify application) or splitting the output (not possible...i lost data when i stop the application).
Yes we've had good results with the copytruncate option as well, in logrotate on hp-ux 11.31.
We too have an application that is continuously writing output to the same log file, and it grows to many GB within a week. We configured logrotate to rotate it daily, keep 30 prior days worth of logs, compress the old logs, and use copytruncate to keep the application happy. It works very well.
)