Dear Managers,
Responses were received from the following individuals (and
thanks to all of them!):
Jay Wasserman <jrw_at_vlsi.bu.edu>
Alan Rollow <alan_at_nabeth.cxo.dec.com>
Murat Balci <balci_at_bornova.ege.edu.tr>
Serge Munhoven <munhoven_at_olive.msm.ulg.ac.be>
Concerning each issue:
QUERY:
--------------------------------------------------------------------
I recently upgraded from OSF/1 v3.2 to DU 3.2c using
installupdate. I've noticed several "nuisance" problems since. None
are serious, but I would like to fix them if possible. Help with any
or all would be appreciated.
1) uname -a still gives the old OSF/1 message. (I'm guessing
some kernel .c file wasn't updated?)
RESPONSE:
---------------------------------------------------------------------
Alan Rollow responded:
The only thing that changes in the uname output is the
revision number and as I recall it gets lower. If your revision
number hasn't changed, then one of the following seems likely:
o The object containing that information didn't get replaced.
o The new kernel didn't get built and booted.
o The new kernel didn't get booted.
Apparently it's the first one; I rebuilt and rebooted the
kernel because I had to change some configuration parameters.
QUERY:
--------------------------------------------------------------------
2) While upgrading, I physically detached our DU LAN from the
Internet and our campus network. sendmail (v8.7.5) suddenly became
unable to deliver ANY mail (even between two addresses on my LAN).
The mail.log said it was because DNS was unavailable (true), but all
the addresses on my LAN are in /etc/hosts on each system and I have
configured the systems to look there first. (All the mail was
delivered once I reconnected).
RESPONSE:
---------------------------------------------------------------------
Several respondents suggested that since the upgrade
reinstalls DU's version of sendmail, I needed to restore v8.7.5. I
had neglected to mention that I had already done that (it's essential,
the DEC version can't read the newer sendmail.cf file!) This still
leaves this issue open.
Serge suggested that the sendmail documentation states that a
name-server must be running, but claims he was able to circumvent that
somehow (changed configuration?).
QUERY:
--------------------------------------------------------------------
3) I now have Aharon Schkolnik's problem with vdump attempting
to dump /proc, too. vdump didn't do this until the upgrade.
RESPONSE:
---------------------------------------------------------------------
Alan suggested that this is a bug and that I contact CSC for a
patch. I will follow up on this.
Murat suggested that since /proc doesn't contain any "real"
files (which I knew) that this can be ignored. True, but I get so
many fake error messages that I might miss a real one.
QUERY:
--------------------------------------------------------------------
4) sendmail now reports mail as coming from "daemon" instead
of the actual sender (although replies work OK). I've seen something
about this one, but I can't remember where.
RESPONSE:
---------------------------------------------------------------------
Seems to be a common problem. Again Alan suggested looking
for a patch and Jay suggested restoring sendmail from the previous
version. Since replies are handled OK I'm not too worried; I just
wondered if there was a quick fix.
QUERY:
--------------------------------------------------------------------
5) I changed the swap space configuration on my server
(combining 2 small spaces on 2 disks to one larger space). Suddenly I
get a file called /paging/file. Is there a problem with the swap file
(it SEEMS to work)? The following comments appear in /etc/rc.config ;
should they be uncommented? The partition and disk information is
correct.
#PAGERAW="1"
#PAGEFILE="/dev/rz3b"
#PARTITION="rz3b"
#PARTITIONTYPE="RZ26L"
#PAGEMINSZ=0
#PAGEMAXSZ=0
export PAGERAW PAGEFILE PARTITION PARTITIONTYPE PAGEMINSZ PAGEMAXSZ
RESPONSE:
---------------------------------------------------------------------
I did not receive any comments on this.
QUERY:
--------------------------------------------------------------------
6) One of my users put in a crontab just after the upgrade (I
normally prohibit user crontabs, but this didn't get fixed up
immediately). Now we can't get rid of the cron job, even after the
crontab is erased. Any clues? (I have restarted cron w/o success.
We haven't tried a reboot yet.)
RESPONSE:
---------------------------------------------------------------------
crontab -e was suggested. However, one of my students (Bruce
Eddy) found the fix: use crontab -r . Apparently cron caches the
crontab somehow, so erasing the file isn't enough. crontab -r
apparently removes this cached copy. At any rate, it worked!
QUERY:
--------------------------------------------------------------------
7) Because of past problems with losing contact with our
router and with sendmail going down, I run the following code from
the root crontab daily (fireball is our router):
if [ `/usr/sbin/netstat -r | grep "default" | grep "fireball" | wc -l` -eq 0 ]
then
/sbin/route add default fireball
fi
if [ `ps ax | grep "sendmail" | grep "accepting" | wc -l` -eq 0 ]
then
/sbin/init.d/sendmail start
fi
This job used to run just fine under v3.2 . Now I'm getting
the following messages:
/vmunix: no namelist
writing to routing socket: File exists
add net default: gateway fireball: File exists
ioctl returns 17
I gather this is trying to tell me I'm already connected to
"fireball", but in v3.2 I received no message at all if this was the
case.
RESPONSE:
---------------------------------------------------------------------
Alan suggested:
The lack of a kernel namelist is usually caused by one of:
o The running kernel isn't called /vmunix.
o The application is dependent on kernel data structure that
have changed and the application hasn't been updated to
reflect the new way things are done.
o The kernel has been stripped.
It must be the second; /vmunix is the running kernel and
unless doconfig is stripping the kernel, it hasn't been stripped.
Apparently "route" needs to be updated.
Thanks for all the help!
Larry
============================================================================
Larry Griffith Dept. of Computer & Info Science
larry_at_garfield.wsc.mass.edu Westfield State College
(413) 572-5294 Westfield, MA 01086 USA
PGP public key available at:
http://garfield.wsc.mass.edu/dcis/griffith.html
============================================================================
Received on Wed May 08 1996 - 00:11:40 NZST