killing zombie file lock

[Ryan Tate]

I have a perl script that runs reports on a log file. It locks this
file with

(flock $fh, LOCK_EX|LOCK_NB) or die "Could not lock file: $!";

Several days ago I invoked the script via CGI. While my browser was
still receiving lines from the script, and before it had time to
finish its run, I hit "Stop" in my browser, presumably before the
filehandle could close and release the lock. Ever since, the script
cannot get a new lock on the file. I get the $! error "Resource
temporarily unavailable." When I remove the lock code from my script,
it works as it did before.

So I suspect I have a days-old zombie lock still tying up the file,
and I want to know how to get rid of it.

I have tried running the script with LOCK_UN in place of LOCK_EX, but
I don't think this is what I'm looking for. I have tried ps -u
myusername at the console and don't see any unusual
processes to kill.

I have no idea what the lock file name would be for my platform, SunOS
5.8, otherwise I would rm the file manually.

I have tried looking this up in:
*The Camel
*Usenet archive for c.l.p* and generally for unix, sunos and solaris
*FAQ for this group
*flock manpage for my system (which seems to describe a C api call,
not an actual utility)
*Unix System Administrator Handbook, 3rd ed, Nemeth, Snyder, Seebass &
Hein

Anyone have any suggestions?

Gratefully,
RT

 

[Anno Siegel]

I have a perl script that runs reports on a log file. It locks this
file with

(flock $fh, LOCK_EX|LOCK_NB) or die "Could not lock file: $!";

Several days ago I invoked the script via CGI. While my browser was
still receiving lines from the script, and before it had time to
finish its run, I hit "Stop" in my browser, presumably before the
filehandle could close and release the lock. Ever since, the script
cannot get a new lock on the file. I get the $! error "Resource
temporarily unavailable." When I remove the lock code from my script,
it works as it did before.

So I suspect I have a days-old zombie lock still tying up the file,
and I want to know how to get rid of it.

Locks don't exist independent of a process. There must be a process
holding the lock.

I have tried running the script with LOCK_UN in place of LOCK_EX, but
I don't think this is what I'm looking for. I have tried ps -u
myusername at the console and don't see any unusual
processes to kill.

If it's a CGI process you're looking for, it runs under the user id
the web server is running under. That may be a different user from
your own.

I have no idea what the lock file name would be for my platform, SunOS
5.8, otherwise I would rm the file manually.

There are no lock files. Locking is handled by the kernel.

Anyone have any suggestions?

To make sure no process can still hold a lock, reboot the computer
the web server is running on.

Anno

 

[news]

I have a perl script that runs reports on a log file. It locks this
file with
(flock $fh, LOCK_EX|LOCK_NB) or die "Could not lock file: $!";

A non-blocking attempt to get an exclusive lock, which aborts the program
if it fails. Unusual (especially given that your introduction implies
read-only access to the log file), but if that's what you want...

Several days ago I invoked the script via CGI.

Ah, a CGI question...

Ever since, the script
cannot get a new lock on the file. I get the $! error "Resource
temporarily unavailable." When I remove the lock code from my script,
it works as it did before.

That's because there's another process (still) holding the lock.

So I suspect I have a days-old zombie lock still tying up the file,
and I want to know how to get rid of it.

That's OS specific.

I have tried running the script with LOCK_UN in place of LOCK_EX, but
I don't think this is what I'm looking for.

LOCK_UN removes a lock that the current process has already applied. You
can't remove someone else's lock.

I have tried ps -u myusername at the console and don't see any unusual
processes to kill.

Ah. UNIX. Depending on the complexity of your web server, this may give
you a process id:

ps -ef | grep YOUR_CGI_PROGRAM_NAME

I have no idea what the lock file name would be for my platform, SunOS
5.8, otherwise I would rm the file manually.

There is no lock file. A lock is applied to a file by the kernel.

I must admit, I'm quite intrigued as to /why/ you think you want an
exclusive lock on a file that you're reading. Is there anything wrong
with LOCK_SH instead?

Cheers,
Chris

 

[Ryan Travis Tate]

(e-mail address removed) wrote:
| A non-blocking attempt to get an exclusive lock, which aborts the program
| if it fails. Unusual (especially given that your introduction implies
| read-only access to the log file), but if that's what you want...

Yes, I did perhaps phrase things badly. My script reads a custom
access log (for a specific CGI script), looks up domain names for IP
addresses (nslookup) and writes the domain names in place of the IP
addresses where possible. (It also moves a text marker to the end of
the file, and echoes the processed file to STDOUT.)

| Ah. UNIX. Depending on the complexity of your web server, this may give
| you a process id:

| ps -ef | grep YOUR_CGI_PROGRAM_NAME

I haven't had luck with this yet but I appreciate the tip.

Thanks again for your time.

Cheers
ryan

 

[Ryan Travis Tate]

| I haven't had luck with this yet but I appreciate the tip.

The solution was to copy the file to a new name, delete the original
file, and then rename the new copy to the original name.

Thanks Anno and Chris for your help. Sorry for what turns out to be a
non-Perl question.

Cheers
r

 

[Darren Dunham]

| I haven't had luck with this yet but I appreciate the tip.

The solution was to copy the file to a new name, delete the original
file, and then rename the new copy to the original name.

Prior to doing that, I would have run 'fuser <filename>' to see what
processes it identified as holding a lock on the file.

If you had just 'mv'd it rather than deleting it, you could still do
that...

 

[Ryan Travis Tate]

| Prior to doing that, I would have run 'fuser <filename>' to see what
| processes it identified as holding a lock on the file.

Thanks for that, I'll use it next time.

Cheers,
Ryan