Personally I feel against "reboot as troubleshooting tool" for two
reasons:

1. Sometimes system that is still useable won't boot at all if you try
to reboot it: like root filesystem corruption that kills some of the
files needed during the boot process, etc. People who used to the fact
that windows stability and performance improves after reboot, often find
out that this is not the case with unix-like systems.

2. Unfortunately most problems won't go away "by themselves". So finding
out what exactly went wrong and fixing that specific problem is always
better then mindless rebooting. 

I don't see this as religious issue however, like some linux users who
love to baby their uptime and brag about it. I always reboot my systems
after any significant upgrade that changes files used during the boot
process, just to make sure the system boots as expected. You don't want
to fix problems at 3 AM in the morning after power outage that forced
the reboot and some damn service won't come up because of configuration
file error.

Haim.

> 
> Never Reboot? I agree that reboot is NEVER the first solution 
> but there are
> cases that you have to reboot even when you have no hardware 
> problems. (I do
> not want to start a flame war here..)
> What can you do when you run a login script that depends on utmpx and
> someone deletes utmpx?
> taking down the system to single-user and back to runlevel 2 
> as far as i can
> see it, it's just like reboot. Users have to get of, runlevel 
> script run
> again and all the things around.
> 
> In any case, This is only my personal feeling about this 
> "Reboot" issue.
> don't kill me.
> 
> -- Yarin
> 
> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]]On
> Behalf Of mulix
> Sent: Saturday, June 02, 2001 3:14 PM
> To: Noam Meltzer
> Cc: Israeli Group of Linux Users
> Subject: Re: taking down adsl connection
> 
> 
> On Sat, 2 Jun 2001, Noam Meltzer wrote:
> 
> > anyway, from time to time, my adsl connection down, and i 
> can't take it
> > down so easily.
> 
> "cant take it down" means what exactly? that you cant get it to
> reconnect?
> 
> > actually i have to reboot the computer (maybe moving to
> > runlevel 1 and then to 2 back will help, but when all you 
> have is a telnet
> > window on the masq-server..., anyhow,)
> 
> oy vey. reboot is NEVER the answer, unless you have hardware problems.
> never ever. the day reboots start solving problem, you can 
> start calling
> it MSLinux.
> 
> > I remember once a discussion on how to take down an 
> adsl-connection and i
> > wish to get a URL for the thread of it in the archive, or a 
> short summary
> > of it.
> 
> quite simple, really.
> 1. kill pppd.
> 2. kill pptp.
> 3. if pptp didn't clean up after itself properly, you need to
> 'rm /var/run/pptp/10.0.0.138'.
> 
> that's all there is to it. that pptp doesn not clean up after itself
> properly is a bug in pptp, which i haven't felt like chasing yet. pptp
> plays some tricks with sigaction and friends, and as long as i didnt
> have to, i did not feel like delving into it. if someone want 
> to do it,
> patches in unified diff format will be gladly accepted.
> 
> [ there's a new pptp version out there on the net, which might (or
> might not) have fixed this problem. i haven't check it yet. ]
> --
> mulix
> http://www.advogato.com/person/mulix
> 
> linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
> 
> 
> =================================================================
> To unsubscribe, send mail to [EMAIL PROTECTED] with
> the word "unsubscribe" in the message body, e.g., run the command
> echo unsubscribe | mail [EMAIL PROTECTED]
> 
> 
> 
> =================================================================
> To unsubscribe, send mail to [EMAIL PROTECTED] with
> the word "unsubscribe" in the message body, e.g., run the command
> echo unsubscribe | mail [EMAIL PROTECTED]
> 
> 
> 


================================================================To unsubscribe, send 
mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to