Re: [MSUNAG] UNIX webserver questions
It sounds like it to me. Is the filesystem ext2 or ext3? An ext3 filesystem is slightly more survivable because of the journal – however, both formats have the same underlying structure, so the same tools work on either (ext2 tools just ignore journaling and work directly on the drive).
----
Jack Kramer
Computer Systems Specialist
University Relations, Michigan State University
w: 517-884-1231 / c: 248-635-4955
From: Jesse Howard <[log in to unmask]">[log in to unmask]>
Reply-To: Jesse Howard <[log in to unmask]">[log in to unmask]>
Date: Wed, 18 Mar 2009 08:50:17 -0400
To: <[log in to unmask]">[log in to unmask]>
Subject: Re: [MSUNAG] UNIX webserver questions
Thanks.
I did an fsck -y and was able to reboot to the command line.
So you think this is caused by a physical disk failure?
Jesse Howard
_______________________
IT Administrator
Michigan State University Press
[log in to unmask]">[log in to unmask]
www.msupress.msu.edu
-----Original Message-----
From: Kelly Climer [mailto:[log in to unmask]]
Sent: Wednesday, March 18, 2009 8:37 AM
To: Jesse Howard
Cc: 'STeve Andre''; 'Peter Cole'; MSU Network Administrators Group
Subject: Re: [MSUNAG] UNIX webserver questions
Hi Jesse,
Last time I had this it was a harbinger of doom. The drive survived for
another 4 months.
You can force a yes response to every question in fsck.
fsck -y
That will clear them all. There is a chance that you might lose some data
but that is the way I could get my old web server back on line after a
crash. Eventually the drive will be corrupt enough that it will not boot
anymore. If these errors can be cleared and the drive is still viable it
will boot. I don't know any other way to mount a drive unless it passes a
fsck.
Replace it soon please. I hope this helps a little.
Thanks,
Kelly
Jesse Howard wrote:
> This morning I was greeted with "kernel panic snapacct_ufs2: bad block.
> Cannot dump. No dump device specified". Fsck in single user mode
> returns the following over and over:
> UNREF FILE
> I=1912306
> OWNER=me
> MODE=100600
> Size=0
> MTIME=today
> Clear?
>
> Is there any way I can turn off snapshots from single user mode?
>
>
> Jesse Howard
> _______________________
>
> IT Administrator
> Michigan State University Press
> [log in to unmask]">[log in to unmask]
> www.msupress.msu.edu
>
>
> -----Original Message-----
> From: STeve Andre' [mailto:[log in to unmask]]
> Sent: Tuesday, March 17, 2009 10:43 PM
> To: [log in to unmask]">[log in to unmask]
> Subject: Re: [MSUNAG] UNIX webserver questions
>
> If you can't access lost+found when you're root, things are definitely
> messed up, or the partition was NFS mounted or something and it was
broken.
>
> Probably you should rebuild this machine, such that /jail is bigger.
> This is one of the reasons I don't like jails: its always the wrong
> size, and you have to deal with it. ;-)
>
> Getting a small ups for the system wouldn't be bad idea either, if
> this is an important machine. Glad to help!
>
> --STeve
>
> On Tuesday 17 March 2009 18:17:43 you wrote:
>
>> I could not access this lost+found directory at all, even though I
>> have root, which is wierd. After checking the logs, I've discovered
>> that this didn't happen all at once. /jail has been around 90% for a
>> while, and somebody tipped it over today, probably just ftping files.
>> I blew away the
>> l+f directory and replaced it. Everything works. I think that you are
>> correct that this was a dump, probably created by a power outage restart.
>> Thanks for your help.
>>
>> Quoting "STeve Andre'" <[log in to unmask]">[log in to unmask]>:
>>
>>> Yes, /jail is at 104% capacity. If lost+found is 12G, that means
>>> that you had a dirty shutdown, and fsck found all sorts of stuff
>>> (files) in an inconsistent state, didn't know where they were, so
>>> put them in lost+found for a human to look at.
>>>
>>> Lost+found is going to stay there 'till you do something to it. At
>>> this point I wonder how damaged the system is. Those things in
>>> l+o were there in /jail and now they're not. My first suggestion
>>> would be to inventory /jail and see what you're missing. If its a
>>> mostly static partition, I'd save it, pull stuff off the last
>>> backup, then manually graft the newer changed stuff atop the items
>>> in /jail.
>>>
>>> How familiar are you with unix, or freebsd in general? This isn't
>>> that hard a thing to do, unless you aren't familiar with it all and
>>> then it can be daunting.
>>>
>>>
>>> --STeve
>>>
>>> On Tuesday 17 March 2009 16:28:42 you wrote:
>>>
>>>> I think I found the problem. I did a sudo du -sh to the
>>>> subdirectories inside /jail, and discovered a directory titled
>>>> 'lost+found' that is 12G. I have to add myself to the operator
>>>> group to even ls it. If I downed the server all the way, would this
>>>> dump that directory, do you think?
>>>>
>>>>
>>>> Jesse Howard
>>>> _______________________
>>>>
>>>> IT Administrator
>>>> Michigan State University Press
>>>> [log in to unmask]">[log in to unmask]
>>>> www.msupress.msu.edu
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: MSU Network Administrators Group [mailto:[log in to unmask]]
>>>> On Behalf Of STeve Andre'
>>>> Sent: Tuesday, March 17, 2009 4:23 PM
>>>> To: [log in to unmask]">[log in to unmask]
>>>> Subject: Re: [MSUNAG] UNIX webserver questions
>>>>
>>>> On Tuesday 17 March 2009 16:16:25 Jesse Howard wrote:
>>>>
>>>>> Who do I go to with UNIX questions on campus. Is there an
>>>>> official/unofficial resource that I can bounce questions off of?
>>>>> I have a freebsd jail telling me that it's file system is full
>>>>> when it
>>>>>
>>>> shouldn't be.
>>>>
>>>>
>>>>> Jesse Howard
>>>>>
>>>> You could post stuff here and see what happens. In this case a df
>>>> showing the disk usage would be a good start.
>>>>
>>>> --STeve Andre'
>>>>
>
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 3944 (20090317) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 3944 (20090317) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
__________ Information from ESET NOD32 Antivirus, version of virus signature
database 3944 (20090317) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
