Showing results for 
Search instead for 
Did you mean: 

Serviceguard log file problem RHEL AS 4

Occasional Visitor

Serviceguard log file problem RHEL AS 4

There's some problem with service guard log file, I've deleted the service guard log file in
since it's getting bigger and bigger almost 3 Gb( i'm only setup 8 Gb for / ) . But the problem is somehow the service guard still accessing the deleted file.
# lsof / | grep deleted
java 2490 501 1w REG 104,1 4684771328 721421 /usr/local/cmcluster/conf/OTA_PACKAGE/ (deleted)
java 2490 501 2w REG 104,1 4684771328 721421 /usr/local/cmcluster/conf/OTA_PACKAGE/ (deleted)
bash 2509 501 1w REG 104,1 4684771328 721421 /usr/local/cmcluster/conf/OTA_PACKAGE/ (deleted)
bash 2509 501 2w REG 104,1 4684771328 721421 /usr/local/cmcluster/conf/OTA_PACKAGE/ (deleted)

And even i've deleted the log file, it doesn't increase the / space availabilty so it seems like the log doesn't remove yet (CMIIW).

And then i've created manually the log file , but the serviceguard process seems still access the old one, and not writing the log in new log file that i've created.
Does anyone have some hint, i hope restarting the services is the last option because the server is very important production server.

Steven E. Protter
Exalted Contributor

Re: Serviceguard log file problem RHEL AS 4


deleting the file while there is still an open file handle on the log file does not release the space back to the system.

The fuser command should be used to identify and kill the process with the open file handle.

What this will lead to is probably a serviceguard failure, so you should be prepared for some downtime.

Steven E Protter
Owner of ISN Corporation
Occasional Visitor

Re: Serviceguard log file problem RHEL AS 4

Hi steve

Thank's for your reply and sorry for late response.
Anyway finally about two weeks ago i restarted the package and it release the free space again. And then i setting up logrotate in linux to rotating and compressing the log everyday to avoid this huge log file again.

And then 2 days ago i checking up the log file again and looks like the main problem still occur.
The problem is the log file was deleted by linux logrotate but the service guard didn't write to new log file that created by logrotate.

So the problem still exist , the log file is getting bigger and bigger even it already deleted manually or by logrotate. And it's impossible if we have to restart service guard everytime we want to release the space.

The question is maybe linux logrotate didn't work for service guard log file or service guard have some self log management that have to be configured..?
Anyone have a clue ?