Re: FS corruption... some help maybe??

Erik Mouw (J.A.K.Mouw@its.tudelft.nl)
Wed, 21 Jul 99 20:03:55 +0200


On Wed, 21 Jul 1999 12:48:02 +0200, Thierry Danis wrote:
> On Wed, Jul 21, 1999 at 12:17:43PM +0200, Herbert Wengatz 42850 wrote:
>> Can you tell me, what use rebooting is?
>
> Maybe because of nightly running applications, not releasing
> shared memory and other IPC stuf, producing amazingly zombies,
> preventing useful tasks to run (such as backup & Co).
> Yes, scripts could be written to attempt to cleanly put
> things up, but usually the best way is to reboot regularly.

A zombie is just bad coding style. The parent process has to wait() or
waitpid(). Fix it if you have the source, blame your vendor otherwise.

IPC stuff can be cleaned up. I use the following script to cleanup the
shared memory segments that my multi-agent application creates:

#! /bin/sh
Whoami=`whoami`
ipcId=`ipcs shm | grep $Whoami | awk '{ print "-m " $2 ; }'`
for i in $ipcIds ; do
ipcrm shm $i
done

Actually, it should only look for segments with 0 attachments, but that's
just an extra grep in the ipcId line. Can be put in the crontab.

> And, with Linux + autofs, taking into account dynamic modifications
> of the NIS automount tables is possible without rebooting but
> is quite painful with 100 or so machines. Sun's automount is
> much better in reconfiguration...

Linux with Sun style automount maps can be a bit difficult. However, if
you can live with a fifteen minutes delay, you can use the following
auto.master file:

/net /etc/auto.net

Together with this simple cron command to update the automount tables:

# Get automount map every 15 minutes
0,15,30,45 * * * * /usr/bin/ypcat -k auto.net > /etc/auto.net

Works flawless on our Linux boxes.

> However, whenever we can keep the uptime rising, we do it :-)
>
>>
>> At work (where I use Sun workstations) I have three machines
> (USER-Workstations!
>> Where there are sitting users at the thing, logging in and out and crashing
>> their applications all day long ;) ) - and these three machines have an
>> uptime of far more than 280 days!!!!! (one is over 290 !)

Okay, here's my extensive uptime story: In my group we had (and still
have) a Linux box used as a public web browsing terminal (and it's also
our loghost) with an uptime of 439 days. We had to switch it off because
we moved to another floor.

Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2785859  Fax: +31-15-2781843  Email J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/