jmm@eci386.uucp (John Macdonald) (07/05/89)
On the 3b1, /etc/rc runs /etc/.cleanup every time the system is brought up. There are two things in here that are wrong. 1. /etc/wtmp is cleaned out! This means that if the system goes down unexpectedly, it throws away some of the most useful information available for determining why it went down. This should be cleaned out in a more predictable and clean way - e.g. in /etc/cleanup.wk it could be moved to /etc/wtmp.old, thus you always have one weeks worth of history. 2. There is a find procedure to clean out the lost+found directory. (This may be commented out by default, it certainly is here.) The problem here is twofold - people don't check lost+found very often so this could lead to an important file being thrown away before it is missed - even worse, it is set up to discard any directory that hasn't been modified in 7 days but when fsck puts something into lost+found it keeps its original timestamp, so this means it doesn't get to stay in lost+found for even a week, it could get removed during the same reboot in which fsck put it into lost+found. -- "Software and cathedrals are much the same - | John Macdonald first we build them, then we pray" (Sam Redwine) | jmm@eci386
rjg@sialis.mn.org (Robert J. Granvin) (07/07/89)
>2. There is a find procedure to clean out the lost+found directory. >(This may be commented out by default, it certainly is here.) The >problem here is twofold - people don't check lost+found very often >so this could lead to an important file being thrown away before it >is missed - even worse, it is set up to discard any directory that >hasn't been modified in 7 days but when fsck puts something into >lost+found it keeps its original timestamp, so this means it doesn't >get to stay in lost+found for even a week, it could get removed >during the same reboot in which fsck put it into lost+found. Are you SURE about this? I'm not. The last time I manually cleaned out lost+found, I had files in there that were 14 months old. And believe me, the system was definately not up all that time... (OK, there were some days where the system was crashing more than I could control ... OK, there were a lot of days). Maybe something changed between OS releases? I've never seen this happen with 3.5 or 3.51 ... (Of course, I haven't looked either, but then, I've no reason to... :-) Of course, we should also be careful about claims and screams of "stupidity". Some things may not be stupid, and some stupid things may not have been done by ATT. -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ BITNET: rjg%sialis.mn.org@cs.umn.edu __National Information Services__ UUCP: ...amdahl!bungia!sialis!rjg "I'll just go bang my head on a wall & figure out why I abuse myself so much"
Robert.J..Granvin@livewire.FIDONET.ORG (Robert J. Granvin) (07/08/89)
-- Robert J. Granvin - via FidoNet node 1:362/130.0 UUCP: ...!tiamat!livewire!Robert.J..Granvin INTERNET: Robert.J..Granvin@livewire.FIDONET.ORG
rjg@sialis.mn.org (Robert J. Granvin) (07/09/89)
No. I most certainly did NOT: In article <386.24B65BC8@livewire.FIDONET.ORG> Robert.J..Granvin@livewire.FIDONET.ORG (Robert J. Granvin) writes: > Article 7395 of comp.sys.att: > Path: sialis!nis!tcnet!umn-cs!nic.MR.NET!xanth!ginosko!uunet!tiamat!livewire!Robert.J..Granvin > From: Robert.J..Granvin@livewire.FIDONET.ORG (Robert J. Granvin) > Newsgroups: comp.sys.att > Subject: Re: 3b1 startup: I CAN'T BELIEVE at&t was really this stupid! > Message-ID: <386.24B65BC8@livewire.FIDONET.ORG> > Date: 8 Jul 89 09:08:01 GMT > Organization: livewire, Chattanooga TN (615)875-6540 > Lines: 6 > > > > -- > Robert J. Granvin - via FidoNet node 1:362/130.0 > UUCP: ...!tiamat!livewire!Robert.J..Granvin > INTERNET: Robert.J..Granvin@livewire.FIDONET.ORG [inews fodder] -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ BITNET: rjg%sialis.mn.org@cs.umn.edu __National Information Services__ UUCP: ...amdahl!bungia!sialis!rjg "I'll just go bang my head on a wall & figure out why I abuse myself so much"
jmm@ecijmm.UUCP (John Macdonald) (07/09/89)
In article <1640@sialis.mn.org> rjg@sialis.mn.org (Robert J. Granvin) writes: >>2. There is a find procedure to clean out the lost+found directory. >>(This may be commented out by default, it certainly is here.) The ^----- Remember this bit. --------------------------------^ >>problem here is twofold - people don't check lost+found very often >>so this could lead to an important file being thrown away before it >>is missed - even worse, it is set up to discard any directory that >>hasn't been modified in 7 days but when fsck puts something into >>lost+found it keeps its original timestamp, so this means it doesn't >>get to stay in lost+found for even a week, it could get removed >>during the same reboot in which fsck put it into lost+found. > >Are you SURE about this? I'm not. Have you looked? > >The last time I manually cleaned out lost+found, I had files in there >that were 14 months old. > >And believe me, the system was definately not up all that time... (OK, >there were some days where the system was crashing more than I could >control ... OK, there were a lot of days). > >Maybe something changed between OS releases? I've never seen this >happen with 3.5 or 3.51 ... (Of course, I haven't looked either, but >then, I've no reason to... :-) My system is 3.5.1.4. >Of course, we should also be careful about claims and screams of >"stupidity". Some things may not be stupid, and some stupid things >may not have been done by ATT. In my original, I said: Subject: 3b1 startup: I CAN'T BELIEVE at&t was really this stupid! Summary: maybe it was Convergent i.e. some stupid things may not have been done by ATT. ------ End of tit for tat, start of real rebuttal. ------------- As I said originally "it may be commented out by default". It is on all of our machines, including some that *I* never checked before. I think it probably comes commented out. As long as no-one is foolish enough to uncomment there is no problem. But then, why include commented-out dangerous code? It serves no useful purpose as is, and might lead someone to uncomment it thinking that it is a carefully thought out working solution to the problem of file space getting wasted in lost+found (when it is actually a disaster waiting to occur). Try looking at the last three lines of /etc/.cleanup to see if it is there. On my system it looks like: -------------------------------------- # Clean the /lost+found directory if one exists #find /lost+found -mtime +7 -type d -exec rm -rf {} \; >/dev/null 2>&1 ^------------------------------------- (Note: commented out - does not currently run. Do not change this.) -- John Macdonald
rjg@sialis.mn.org (Robert J. Granvin) (07/09/89)
>>>(This may be commented out by default, it certainly is here.) > > ^----- Remember this bit. --------------------------------^ > >>>problem here is twofold - people don't check lost+found very often >>>so this could lead to an important file being thrown away before it >>>is missed - even worse, it is set up to discard any directory that >>>hasn't been modified in 7 days but when fsck puts something into >>>lost+found it keeps its original timestamp, so this means it doesn't >>>get to stay in lost+found for even a week, it could get removed >>>during the same reboot in which fsck put it into lost+found. >> >>Are you SURE about this? I'm not. > >Have you looked? I have now, and I still don't see a problem. 1/ If this is such a horrible gross problem to you, why activate it? 2/ Your article was clearly written to make it sound, (even though you can miss the "commented out by default") that it is guaranteed to do this. It isn't. If someone WANTS to clean out lost+found in any way, it's quite obvious that they at least have to go through some conscious method to do so, either by installing their own cleanup script or activating this line. In other words, I see no problem. >>Of course, we should also be careful about claims and screams of >>"stupidity". Some things may not be stupid, and some stupid things >>may not have been done by ATT. > >In my original, I said: > Subject: 3b1 startup: I CAN'T BELIEVE at&t was really this stupid! > Summary: maybe it was Convergent > >i.e. some stupid things may not have been done by ATT. Right. And my statement still stands. A little bit of thoughtful editing gets a better response... :-) >As I said originally "it may be commented out by default". It is on >all of our machines, including some that *I* never checked before. >I think it probably comes commented out. It does. >As long as no-one is >foolish enough to uncomment there is no problem. But then, why >include commented-out dangerous code? It serves no useful purpose >as is, and might lead someone to uncomment it thinking that it is a >carefully thought out working solution to the problem of file space >getting wasted in lost+found (when it is actually a disaster waiting >to occur). It actually does serve quite a bit of value when you consider it. This machine was designed to be used as a desktop workstation, much in the way many PCs are used today. These people who use the machine are not known to be the most conscious in the world of terminating their sessions. "I'm done for the day, so I'll just shut it off". Whatever. The more you abuse the machine, the more garbage you are going to leave around, and where will that garbage go? lost+found. So, the hotline will get a call that their machine is constantly running out of disk space, (or whatever), and after some investigation, it's clear that lost+found is the culprit. Now, which would you rather tell an inexperienced Unix user to do? 1/ "Add: 'find /lost+found -mtime +7 -type d -exec rm -rf {} \; >/dev/null 2>&1' to /etc/cleanup." or 2/ Uncomment the last line in /etc/cleanup. [Yeah, yeah, this is just one example, don't mail me and tell of of a thousand other ways... :-)] >(Note: commented out - does not currently run. Do not change this.) This is yet another one of those "panic runs". To have this cleanup occur, you have to consciously activate it. If you consciously activate it, you are going to be aware of the results and consequences (theoretically at least :-). If you're puttering around enough to get in the middle of something like /etc/.cleanup, then you're either pretty experienced anyways, or are destined to cause a lot of damage... :-). Automatically cleaning up lost+found has definate value to some people, and is a horrible thought to others. However, doing so is not "dangerous", it is not going to damage your system, it is not going to vaporize anything important. Quite honestly, if you log out poorly, or your system crashes, those items that are stuck in lost+found are certainly not going to be seven days old. Unless there is a system error of some sort, what will more than likely appear there is something you are currently working on, or making use of, so the mtime will be nowhere close to 7 days. If 7 days bothers you, you can change it. 14? 30? 90? The possibilities are endless. If the whole concept scares you, ignore it completely. This is hardly stupidity on anyone's part. It's actually a nice little amount of foresight, as far as I'm concerned, and it's commented out because it's not for everyone. -- ________Robert J. Granvin________ INTERNET: rjg@sialis.mn.org ____National Computer Systems____ BITNET: rjg%sialis.mn.org@cs.umn.edu __National Information Services__ UUCP: ...amdahl!bungia!sialis!rjg "I'll just go bang my head on a wall & figure out why I abuse myself so much"
gst@gnosys.UUCP (Gary S. Trujillo) (07/10/89)
I may be missing something, but it seems to me that if the command under
discussion:
#find /lost+found -mtime +7 -type d -exec rm -rf {} \; >/dev/null 2>&1
had any real utility, it would be to clean *files* out of the /lost+found
directory. As the command is written, it will actually delete the /lost+found
directory itself along with its contents if the contents of the directory have
not been modified within the past week. If there is no /lost+found directory
when you run fsck as part of the reboot sequence, there is no place to put
files which have become unlinked.
Just an observation.
--
Gary S. Trujillo {linus,bbn,m2c}!spdcc!gnosys!gst
Somerville, Massachusetts {icus,ima,stech,wjh12}!gnosys!gstmichael@maui.cs.ucla.edu (michael gersten) (07/15/89)
For my $.03 on the subject, On my system this command was ENABLED when I installed my system. I've learned to check all the bootup routines/procedures when installing systems, so it didn't bite me. But it could bite others. Michael