Listing file locks on Solaris 10
Suppose that you want to find out what files are locked on your Solaris
10 machine, perhaps because it is an NFS server and you really want a
global view of what locks you have. On a
Linux machine (or a sufficiently old Solaris one) you could use
but it's never been ported to Solaris 10; instead you need to use '
-k', the kernel debugger.
The 'simple' command to get a list of files with file locks is:
echo '::walk lock_graph | ::print lock_descriptor_t l_vnode | ::vnode2path' | mdb -k | sort -u
We need the
sort -u because it's reasonably common for our servers to
have multiple locks (presumably non-overlapping) against the same file.
Your situation may differ.
::lminfo command gives you somewhat more information about all
of the locks, but it has the drawback that it truncates filenames. What
I know about the various fields it prints:
- the bits of the FLAG field come from
flock_impl.h, specifically the section about the
l_statusfield. Note that the FLAG field is printed in hex.
- the PID and COMM fields are not necessarily meaningful for
client locks on an NFS server.
Locks from clients sometimes have a PID of 0 (which shows
as as a COMM of
<kernel>), sometimes have impossible PIDs (which show as
<defunct>, because there's no such PID on the NFS server), and if you're unlucky have the PID (and COMM) of an actual process on your NFS server.
(See here for a possible discussion of this issue.)
- I believe that you can spot file locks from NFS clients
by a FLAG value that includes 0x2000 (aka
Further digging (to, for example, find the name of the client that theoretically holds the lock) is hampered by the NFS lock manager code unfortunately not being part of the OpenSolaris code base because it's not open source. (Allegedly Sun can't share it because it contains third-party code.)
Possibly, even ideally, there's a better way to get this sort of information. If so, I've been unable to find it.
Sidebar: what the mdb command does
This is a sufficiently complicated mdb command sequence that I feel like breaking it down (if only so that I'll remember how it works later).
||Iterate over the 'locking graph', which has
all file locks in the system. This yields a
series of addresses of
||Get the pathname given the vnode pointer.|
If you're doing this inside an interactive
mdb session, you can
! sort -u' to sort it too.
Forwarding emails without false positives
Here is a modest suggestion for email clients: when you forward a
message, you should put some marker of this at the front of the
Subject: header. Similarly, if you are configuring your email client
and you have a choice, you should set it up this way.
(Some but not all clients do this today.)
Many anti-spam systems that I've seen put a spam status marker at the
start of the
Subject: line; it's a relatively obvious place, and
putting it at the start increases the chances that the users will see
it (instead of missing it at the end of the line, or having their
client not even show a specialized header).
(Also, there is the whole tradition of putting 'Re:' at the start of the subject line for replies.)
Now suppose one of your users forwards a spam-tagged message. This
forwarded message is not itself spam (the obvious example is 'dear
system staff, why did this get classified as spam?'), but if your client
leaves the start of the
Subject: header alone, the status marker is
completely intact. Filtering badness is quite likely to occur. Putting
the forwarding marker at the start of the
Subject: line avoids this
(and plays along with the existing 'Re:' tradition).
(Having written this I have to admit that my mail client currently isn't set up this way. I should fix that, but there always seem to be more important things to do than fiddle with the guts of my MUA environment, which is somewhat baroque.)