 |
What to do when you try to read mail in Pine and get the
message:
[Mailbox is open by another process, access is readonly]
Many issues can lead to Pine not being able to read mail. The
usual indication is a "readonly" inbox in pine when
attempting to read mail. This may or may not be a
mail-related issue; there are several things you need to
check to make sure you understand the situation and correct
it.
What to do when you try to read mail in Pine and get the
message:
[Mailbox is open by another process, access is readonly]
Many issues can lead to Pine not being able to read mail. The
usual indication is a "readonly" inbox in pine when
attempting to read mail. This may or may not be a
mail-related issue; there are several things you need to
check to make sure you understand the situation and correct
it.
-
Over Quota:
The first thing to look for in a mailbox "read only"
situation, on both WAM and standard Glue accounts(*), is
whether the user is over their allocated disk quota.
How
(Pine) mail works:
When Pine deals with your new mail, it copies the mail
spool file:
/mail/userid/userid
and appends it to the file:
/mail/userid/mbox
and then works on the mbox file. (This
is to prevent corruption to your real incoming mail file
while you're reading your mail and new mail comes in for
you.) For a very short time during this copy process, both
the mail spool file and the mbox file
must exist at the same time; when the copy is finished the
mail spool file is emptied (but the file remains).
Therefore, for a brief time, the disk space usage is:
(mbox file) + (mail spool file) + (copy of mail spool file)
Once this copy process is completed, you'll only be using
as much disk space as:
(mbox file) + (mail spool file)
which will all be in your mbox file.
If you don't have enough room under your quota to handle
this copy procedure, you'll get the (misleading) error
"read only" message.
To check this, make sure the user is at the system
prompt, then type:
quota
The results of the quota command
should look similar to this:
rac1:~: quota
Volume Name Quota Used %Used Partition
user.userid 100000 39652 39%
rac1:~:
where userid is the login id of your account. The
total amount of disk space allowed on WAM and standard Glue
accounts is 100MB; the above readout shows it in Kilobytes,
so 100MB = 100000KB. Notice the "Used" and "%Used" values
indicate how much physical space (in KB) you are using, and
how much of a percentage of 100MB that space is. This is a
normal situation where the user apparently has plenty of
space.
If a person is using up all of their disk space
allotment, you'll see a result more like this:
rac1:~: quota
Volume Name Quota Used %Used Partition
user.userid 100000 100084 100%<<
Note the double less-than ("<<") symbols pointing to
the percentage value - this is the systems way of drawing
your attention to this problem.
Also note that the usage percentage (under "Partition")
is 100%; this person has used their entire 100MB disk
quota allowance (in this example, they're actually 84
bytes over the quota).
If you see a quota which is at or over the 100% mark,
that's a red flag that the user has too many files and/or
mail items, and something needs to be done.
If someone tries to send mail to a WAM or Glue account
which is over quota, they'll get the mail bounced back,
containing the original mail and an error something like:
<<< 550 5.2.0 userid: Disk quota exceeded, try again later.
554 <userid@wam.umd.edu>... Service unavailable
in the headers of the bounced mail.
If the problem is an at or over quota problem, the only
possibility is to clear some disk space on the account
before the user will be able to receive mail again, and
be able to use Pine to read the mail. You have two
options on approaching this, depending upon where the
space is being used:
-
Near Quota:
There's another situation like the at/over quota
situation, which may not be as obvious to the user, but
still may cause the same problem. This is that the
account is under the quota, but the unread mail (in
/mail/userid/userid) may be larger
than the amount of free space left on the account. (See
the description of how mail
works at the top of the page.)
There is a program on the WAM and Glue systems to deal
with this issue, which will append your mail spool file
to your "mbox" file for you (mimicing the first step in a
Pine session) without using your own file space. The
command is:
catmail
If you are under quota, you will be able to get all your
mail into the "mbox" file so that you can deal with it
normally in Pine.
Remember, this is only a quick fix - you'll still need to
do something to get your disk space usage down or you'll
keep having the problem.
Once the issue of quota has been settled, if the problem
still persists there are other things for which you can
check.
-
Leftover Pine, Netscape Lock Files
In this case the user has left open a Pine session on
another terminal, or the user is using an offline mail
client (Netscape, Outlook Express, etc.) and is trying to
read their mail while the other program already has
control over the mail files.
If in the current Pine session they are getting the
"readonly" message, the user needs to get out of Pine and
determine if the culprit is actually another mail session
or simply the lock file from a previous mail session
which was not properly removed.
Note: You have to be careful when
doing this; removing a lock file for an active mail
session could cause your mail file(s) to get corrupted,
possibly losing some mail items in the process!
The first step is to identify if a lock file exists. A
lock file from a Pine session begins with a dot (".") and
is followed by seven characters, an example of which
looks like:
.6700300
A lock file from an offline mail client is a longer string,
usually containing the word "lock" as well as the word
"imap" (part of the hostname of the IMAP server which the
mail connection came in through, an example of which looks
like:
mbox.lock.954921580.25647.imap0.wam.umd.edu
Note there is no leading dot (".") on this latter type of
lock file.
If you discover you have one (or more) of these types of
files, the next thing to determine is whether it's from a
current or old (defunct) mail session. To check this,
start by listing the files with date information:
ls -alt /mail/USERID
where USERID is your WAM/Glue login ID. This will list all
the files in your mail spool (incoming) directory,
including dot (hidden) files, and sort them by date, most
recent files first. If you see a date prior to the current
date, it's probably a leftover from an old mail session,
and the file can be safely removed. If the date on any of
the files is the current date, it still could be an active
session requiring more investigation.
If you find Pine lock files from the current date, the
next thing to do is determine if they're from a current
or old session. To do this, determine into which tty port
you're connected on the current system with:
who am i
You should see a result like:
who am i
USERID pts/63 May 4 11:59 (rac1.wam.umd.edu)
This shows you that you're connected to the RAC1 host on
tty (pts) 63 on host rac1.wam.umd.edu. Once you get this
information, use the finger command to determine
if you are logged on anywhere besides the current session:
finger USERID
Login: USERID Name: Users name
Directory: /homes/USERID Shell: /bin/tcsh
rac1.wam.umd.edu:
On since Thu May 4 11:59 (EST) on pts/63 from hostname
network:
On since Thu May 4 10:55 (EST) on 21 at hostname
You're looking for entries listed with "On since..." -- if
you see any for ttys besides the one you're currently on,
they may still be active sessions. In the example above,
USERID is logged into WAM twice; once on the current
session and another one on tty 21 on hostname
(notice the "at hostname " in the example above).
If there are no other current sessions on the system, you
can safely remove the file(s). If there are other current
sessions, you need to kill them so that your current
session is the only one.
If you have active sessions other than your current
session, make a note of which hostname they're on, and
which tty (pty) they are on. Then, for each
hostname, login to that host and type:
ps -ef | grep USERID | grep TTY
where USERID is your own WAM/Glue login ID and TTY is the
tty/pty from the output of the finger command. You
should see something like this:
ps -ef | grep USERID | grep 21
-
Leftover AFS Locks
Another type of lock file which could interfere with mail
being read are leftover AFS locks. AFS stands for the
Andrew File System, which is the file/directory
security used on the WAM and Glue systems. Sometimes AFS
locks are not removed correctly, and they may still be
laying around after a mail session has concluded.
Some AFS lock file examples:
.__afs1594
.__afs4781
.__afsA0D4
Note: Those are two underscore characters ("_") between the
period and the "afs" parts of the filename.
These lock files contain only 4-5 bytes, which is the PID
of the process which created them. This will only matter
if the process is from the same day (on WAM and standard
Glue), as the RACs and y.glue and z.glue reboot nightly.
If the files are NOT from the
current date, they can be removed safely:
rm .__afs1594
To get rid of a group of such files, you can use the "*"
wildcard, like:
rm .__afs*
-
Corrupted mail file
If you have a corrupted mail file (two mail processes
attempted to write to your mail file at the same time,
conflicting with each other and damaging the contents of
the file), it will cause mail to not behave normally. In this case, please contact the OIT Help Desk for assistance.
As always, if you're not sure what your problem is, or don't
feel confident in repairing your own situation, you can feel
free to contact the OIT Help Desk at (301) 405-1500 (x51500)
or visiting us in room 1400 CSS (bldg 224), Mon-Fri 8-6.
-
(*)
-
Some Glue accounts are hosted by (the home directory is
stored on) departmental servers. The quota situations will
be different on these accounts. Refer to your local lab
manager or a Help Desk full-timer for explanations of how
these accounts are set up.
|
