From owner-freebsd-hackers Tue Jun 18 12:57:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA22407 for hackers-outgoing; Tue, 18 Jun 1996 12:57:53 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA22402 for ; Tue, 18 Jun 1996 12:57:50 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id PAA14872; Tue, 18 Jun 1996 15:55:30 -0400 (EDT) Date: Tue, 18 Jun 1996 15:56:34 -0400 (EDT) From: Brian Tao Reply-To: Brian Tao To: Troy Arie Cobb cc: freebsd-hackers@FreeBSD.org Subject: Re: odd results from w command In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 16 Jun 1996, Troy Arie Cobb wrote: > I had a user on the other day, let's call them > foo. When I typed 'w', the results of the > command went something like this: > w: /dev//foo No such file or directory. Your /var/run/utmp is corrupted. I had the exact same problem pop up on a newly-installed 2.2-960501-SNAP system. I'd get something like "w: /dev//ADD ROUTE: File exists" and some other garbage with the 'w' command. So far this has only happened with this one particular server. None of our other 2.2-SNAP servers have experienced this yet. I think I figured out how this happened on our server, ns.ican.net. /var/run/utmp is cleared by /etc/rc on startup by copying /dev/null over it. I wrote a Bourne script to automatically update our secondary name servers from the data on ns.ican.net. That script contained the line rm -f boot2.tmp boot2.data 2>&1 /dev/null Any *competent* /bin/sh programmer (i.e., not me ;-)) will notice that /dev/null will be removed along with the boot2.* files. I forgot about the extra '>' needed before /dev/null. When the server is rebooted, error output of commands in various startup files is sent to /dev/null. In our case, /dev/null was a regular file. Then /etc/rc would 'cp /dev/null /var/run/utmp', and that's how our utmp file was corrupted. Whew. :) So if you still get the problem after a reboot, check your /dev/null device. It may have accidentally been wiped out. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't"