[lug] ls -l /var/tmp = drwxrwxrwt 16 root root 1478656 Mar 19 10:38tmp

[D. Stimits]

Bob Collins wrote:
> 
> "D. Stimits" wrote:
> [snip]
> 
> > kfm is probably KDE file manager, user Collins, display 0.0 in X11.
> 
> Right and I think they are OK.  I just got confused when I
> saw the files when I thought I was looking at /var/tmp and I
> was looking at /tmp instead.
> 
> > susehilf is the suse help. The xxxxxx would be a temp file, kind of a
> > cookie ID. What are the permissions on one of these?
> 
> root root drwx------

Ok, so it is probably being executed as root, unless the help system is
suid root (possible, but I doubt it).

> 
> > > case letters mixed with numbers.  The files date from August
> > > of 1999 until July of 2000.  I have been removing the oldest
> > > directory, /susehilf.vCR5nO for over an hour and a half.
> >
> > rm -Rf susehilf.vCR5n0
> 
> Do I really want to tie up my computer for 20 + hours?

Removing that directory recursively shouldn't take but a few minutes
even if the disk is filled there.

> 
> Why do you think it takes that long to remove the directory?

I don't think it would take that long, but if it does, very likely it is
the nature of recursive code. A delete-like function scans for files and
directories, then enters a directory and scans for files and directories
again; so, until it finally reaches the last directory that has no more
subdirectories. Then it begins deleting the files of the last
subdirectory; it then backs out and deletes the directory itself.
Recursive delete of deep trees can take a long time, though I can't
imagine it taking 20 hours or more. I'd be tempted to use vi on some of
the files in those directories and see if they really are help files
(they should be, but for example, malicious attacks tend to hide the
true payload).

> 
> Maybe the problem has been fixed.  July of 2000 was the last
> date one was created.  I have update SuSE since then and I
> have used the SuSE help since then.

If that is the last date then the problem probably is gone. Still, the
left-over needs to be removed, it must be eating up inodes by the
thousands or millions (typically something like 1 inode for every 4k or
8k bytes on the drive; you may have used up over 90% on unused 4k or 8k
chunks).

> 
> [snip]
> 
> > Disk space consists of both actual space, and inodes, the inode
> > containing metadata about what node has the real data. If you run out of
> > inodes, it won't matter if no disk space is used, you would effectively
> > be out of disk at that point.
> 
> My thought was that it was smaller than 1k and it didn't
> show when I did df because it shows blocks.  I don't know,
> but it did take an hour and 40 minuetes to remove the
> directory.

If you have a nearly filled partition but only a very small space
actually accounted for, then your inodes must be nearing capacity.
Again, it sounds like a deep and complicated tree, and removal via
recursion is slow. Especially if for some reason it makes you swap out
while doing the delete.

> 
> > > The real culprit is the approximately 73,600 "taper"
> > > temporary files (backup software).  I sent a note to the
> > > developer of taper ask if I did something wrong or if he has
> > > a fix for what happened.  The files are from a single backup
> > > of my system.
> >
> > Probably it leaves the prior temp for incremental purposes, but that'd
> > only be a guess. Have you actually run backup 73,600 times over that
> > period?
> 
> I used taper for the first time last month and did a single
> backup of my system to tape.  I did some backups to my zip
> drive on my laptop and I just now looked at it and I see I
> have a bunch of the taper temporary files in /var/tmp also.
> I didn't backup the whole system on it and I have a bigger
> disk also.  It wasn't noticeable on the laptop.

I would have to wonder if cron is doing something with it you don't know
about. You may want to check that.

> 
> There were some of the /susehilf.xxxxxx directories also.
> Maybe I shoudn't have removed the one I did.  Butt who nose?

Any /tmp/susehilf.xxxxx should probably be removed without worry.
Especially old stuff dated way back in July or whenever.

> 
> > > I am interested in comments and ideas especially about the
> > > /susehilf.xxxxxx directories.  If the 11 directories each
> > > take an hour and forty minuets to delete, it would take a
> > > long time and they don't seem to take up much space.
> >
> > rm -Rf susehilf.*
> >
> > The suse help system is apparently making temp files. This could
> 
> [snip]
> 
> No new susehilf.* since July of 2000.

Sounds like you can let loose your Terminator...kill all the
susehilf.xxxx temp stuff.

> 
>    Regards, Bob Collins
> Experience is something you don't get until just after you
> need it.
>                 -- Olivier
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug