SUMMARY: /tmp/.getwdxnnnnn (again)

From: fed!
Date: Fri Feb 15 1991 - 11:47:12 CST

It seems that I summarized too soon. Right after I sent out
my summary, I got a pile of messages, some of which
contained some additional information that I thought was
useful enough to warrant a follow-up, to wit:

>From Jim Mattson <uunet!cs.UCSD.EDU!mattson>:
There are two solutions. One is to make sure that as root
you do a pwd in some deeper directory than / each time your
mount table changes (i.e. each time you mount or umount a
file system). This will force an update of /tmp/.getwd and
keep it in synch with /etc/mtab. If you run an
automounter, though, this may not be so easy. (Maybe you
could do it out of cron every half hour, but what a
kludge.) The other solution is to upgrade to 4.1 or 4.1.1
where this problem has been fixed. (I don't know about
your Solbournes).

>From Paul O'Neill, OSU--Oceanography, Corvallis, OR:
Here are the last 2 lines of my /etc/rc.local. I'm not
enough of a system hacker to know why this works. I saw it
on the net, tried it, and it's gotten rid of all those
/tmp/.get?????'s. It's been so long, I forget the

# 06 feb 90 -- get rid of .getwdxxxxxx in /tmp
pwd >/dev/null

>From Daniel Trinkle, Purdue University:
Sun decided to speed up getwd() by adding a cache that
contains information relevant to NFS mounted filesystems.
This is a big win over probing each NFS server every time.
The cache is in /tmp/.getwd. If /etc/mtab has changed
since /tmp/.getwd, then getwd() rebuilds the cache in
/tmp/.getwda<pid> and then moves the new cache into place
(removing /tmp/.getwd in the process). However, if the
person that happens to trigger the rebuild of the cache
does not own the previous cache, and the /tmp directory has
the sticky bit set, it will not work.

There are two workarounds. The first is to remove the
sticky bit from /tmp. This is a slight security loss. The
second is to make sure root runs getwd any time a
filesystem is mounted or umounted. This is not a big deal
for most systems, and may be the prefered option.

>From Andie Ness, CSTR, University of Edinburgh, EDINBURGH:
At a guess, I would say you have the sticky bit set on /tmp.

If you run "trace pwd", it prints out a log of lstats of
the form...

lstat ("/a/hume/u4", 0xf7ffe628) = 0
lstat ("/a/phoenix/u21", 0xf7ffe628) = 0
lstat ("/a/maxwell/u10", 0xf7ffe628) = 0
lstat ("/a/scott/u13", 0xf7ffe628) = 0


and then writes out /tmp/.getwd{pid}

Once this is close it tries to rename /tmp/.getwda{pid} to
"/tmp/.getwd" which will fail thus

rename ("/tmp/.getwda14170", "/tmp/.getwd") = -1 EPERM (Not owner)

because a the first pwd since /tmp got cleared managed to
rename ... Since you have the sticky bit set for /tmp,
only the owner can remove .getwd so you'll get left with
the /tmp/.getpwda* files owned by everyone except the owner
of /tmp/.getpwd (if you see what I mean).

One way to test this would be to check that the owner of
.getwd doesn't own any other .getwda* files.

We get round this by running a script every hour to clear
out /tmp/.getwd* files.

[The sticky bit is rather useful for the stuff we do round


On reviewing all this, I am curious about one thing: We do
not run any auto-mounter, but we were collecting thousands
of .getwdxxx files with a stable mount table. We *do*,
however, have our fstabs automated, so it should be
possible to force the getwd every time the mtab changes.
In any event, I think that we might try one or some
combination of these suggestions.

I also had similar replies from:

Andy Sherman/AT&T Bell Laboratories
uunet!CUNYVM.CUNY.EDU!xphyhofu%DDATHD21.BITNET (Joachim Holzfuss)
Richard Evans, Topexpress Ltd, Cambridge, CB3 0RD, UK
Bruce Rossiter, Oracle Corporation
Jim Guyton,
Bala Vasireddi, Synopsys, Inc., Mountain View, CA

Thanks again to everyone for all your help.

Bob Drzyzgula
Federal Reserve Board

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:10 CDT