Recursive Directories

[akthar]

Please Help and Thanks in Advance,

There is some folder in my filesystem which is being copied to itself I dont know why .. example
/mount01/core-2000 ===> is the original folder structure but after some days it recurse itself like
/mount01/core-2000/core-2000/core-2000/core-2000/core-2000/core-2000/core-2000/core-2000/
and this makes my file systems full very frequently stopping my regular process to run. Why this happens ? what are all the possibilities ? How to correct this?

Urgent help pls

 

[MikeLacey]

'core' - a process that producing core dumps regularly? Are there core files in there?

If there are it should be possible to figure out which process is acting up. I haven't done this in a while (don't ask how long) but it shouldn't be rocket science.... famous last words maybe. Mike
michael.j.lacey@ntlworld.com
Email welcome if you're in a hurry or something -- but post in tek-tips as well please, and I will post my reply here as well.

 

[akthar]

No it is not core dump or stuff like that it is just a example . Folder is nothing to do with core dump and stuffs.

 

[MoshiachNow]

Hi,

There are severall approaches that you can take:

1.If you now the time of the day when it happens - you can setup a trace that will collect all createdir events,and later on can be browsed using the trcrpt command.
One must be carefull - if trace is not limited by time/events - it will error on trace log buffer overflow.
Example of trace:

#trace -a -s -T 10000000 -L 20000000 -o /tmp/trace.log

This runs trace with increased buffer and log files sizes.
wait till the redundunt folders are created,then ...

#trcstop

then run report :

#trcrpt -O exec=on /tmp/trace.log |grep <redundant_dir_name>

2.If you know the dir name that will be created - run a catch script in background ,that checks for this dir existence,and outputs &quot;ps -ef&quot; to some log file when it happens.
From the log file you can try to figure the process that creates those dirs.
SCript:
=================================
#!/bin/ksh
#This scripts catches &quot;rm&quot; system events every 10 seconds. When the dir is created , the script creates log , notifies admin via email and exists.

#Put it in an executable file called &quot;catch-dir.sh&quot; (chmod 711 catch-dir.sh) it will be performed every minute by running (once).

DATE=`date`
LOGFILE=&quot;/tmp/catch-dir.log&quot;
LOGFILE1=&quot;/tmp/catch-dir.log&quot;

while true
do
tail -5000 $LOGFILE > $LOGFILE$$
mv $LOGFILE$$ $LOGFILE
chmod 666 $LOGFILE

if [[ -d “/mount01/core-2000/core-2000/core-2000” ]] ;then
echo &quot;----------------------------------&quot;>> $LOGFILE
echo $DATE >> $LOGFILE;
echo &quot; ----------Starting (ps -ef) ---------------------- &quot; >> $LOGFILE
ps -ef >> $LOGFILE;
echo &quot; &quot; >> $LOGFILE
tail -500 $LOGFILE > $LOGFILE1
mail -s catch-dir admin@creo.com <$LOGFILE1
exit 0

fi
sleep 10
done
exit 0
===============================================
3.To me it looks like some peace od SW badly written.
&quot;Long live king Moshiach !&quot;

 

[pcunix]

If this truly is a recursive directory (something that the kernel is supposed to protect against) you can see that by examining the inode numbers with ls -i. If subdirectories are pointing back to themselves, the inum will be the same.

That's a file system inconsistncy. In single user mode, unlink the inode and then run fsck.

If it's not that, you may need to do the deep tracing suggested above. OTOH, you might get lucky and be able to catch it with &quot;fuser&quot; or &quot;lsof&quot; to track what processes are using the directory. That's much more granular of course. Tony Lawrence
SCO Unix/Linux Resources

http://pcunix.com

tony@pcunix.com

 

[MoshiachNow]

I would also run fsck on this FS,it's possible that there is a FS corruption. &quot;Long live king Moshiach !&quot;

 

[akthar]

Thanks a lot to all who replied , Speacial one to LEVW . Yes Even i doubt about the bad SW codes. I gonna dig it out ..

Thanks again