files are open though i have closed it

[Smaran]

Hi ,
I am facing a strange situation.
I have a main process which forks multiple process and for each process it opens individual file descripter.
like the following code.
if ((pid = fork()) == 0)
{
sprintf(filename, "%s/XXX.new", DEBUG_PATH);
fd = open(filename, O_RDWR|O_CREAT|O_TRUNC, PERM);
close(2);
dup(fd);
close(1);
dup(fd);
Later during the normal backup process. each process closes the current file descripter and
renames it some different file name and
opens a new file descripter.
The code is like this
fflush(stdout);
fflush(stderr);

rename(debug_filename,debug_oldfilename);
fd = open(debug_filename, O_RDWR|O_CREAT|O_TRUNC, PERM);
close(2);
dup(fd);
close(1);
dup(fd);
after the new files are created , old files are zipped and moved to other back pu filessystem by some other process.

Every thing is running fine. But the problem
is though the files are moved from the directory , the space is not freed.
So, after some times we are facing space problem. where the du showing we have spaces but bdf is showing the disk is full, because
the files were still open, when they are moved.
I am using HP UX 11.0
Can anyone plz suggest me the wayout ...
I can not restart the processes due to business constraint.

Thanks in advance.
Smaran

[Steven E. Protter]

The space will not be cleared and available until any procesess that have open filehandles are closed.

Now this may be your job. Make sure the process closes itself down when its done. It may be the job that maintained them or created them in the first place.

fuser -cu will list processes in a filesystem.

See if you can figure out what process is still trying to have a filehandle open.

You can kill a process one at a time or en masse with the fuser -cuk /filesystem command.

That second command is the filesystem equivalent of nuclear weapons. You may need a more precise way of doing it.

SEP

[A. Clay Stephenson]

You have a hole in your logic. As long as a single process has a file open, even if you have unlinked (rm'ed or renamed) the file, the space is not actually frreed until the last process that has it open either terminates or issues a close() system call. If you are having problems identifying exactly what is wrong, use lsof. Lsof can spot open files even when the directory entries have been removed (ie the file pathname has been unlink()'ed). You will at least know the process and the fdes that is open and that should be enough debugging data to resolve your logic problems.

[Laurent Menase]

Hi Smaran,

Apparantly you did not clsoe(fd)
fd = open(filename, O_RDWR|O_CREAT|O_TRUNC, PERM);
close(2);
dup(fd);
close(1);
dup(fd);
close(fd); /*HERE*/

[Smaran]

Thanks all for the response,
From the discussion What I understand,
As I am opening the file from some other
process (parent process which is forking)
and tries to close the file in the child pro
cess, and all the processes are running continously, so the spece is not freed.
If I put the whole opening and closing logic
in a single program , it should work.
Plz clarify me in this point.

[A. Clay Stephenson · Accepted solution]

Yes that approach will work. Another technique is to use fcntl() to set the close-on-exec (FD_CLOEXEC) flag on all the file descriptors in question.

[Mike Stroyan]

The close-on-exec flag is only effective if the child process calls exec*(). The example just calls fork and does not use exec.

[H.Merijn Brand (procura]

Threads should NOT be closed without assigning points to *all* answers!
Even no points is OK, but do not close threads with unassigned posts in it.