I have already put many times the question on how to Kron properly a /tmp
cleaning job under linux, and still no clear response.
I'm trying to be clearer evertime.

I put this following in the kron manager (Kcron)
/usr/bin/find /tmp -atime +15 -type f -o -type d -exec /bin/rm -rf '{}' \;

when it first was run, I couldn't do all the things as usual under X,
there was always an error message as following:
"server doesn't respond" or the same thing said differently
so there are files that are not to be deleted lika that, which i knew but not
which ones.

i read once that they were sockets.


--
heavytull

heavytull a écrit :
> I have already put many times the question on how to Kron properly a /tmp
> cleaning job under linux, and still no clear response.
> I'm trying to be clearer evertime.
>
> I put this following in the kron manager (Kcron)
> /usr/bin/find /tmp -atime +15 -type f -o -type d -exec /bin/rm -rf '{}' \;
>
> when it first was run, I couldn't do all the things as usual under X,
> there was always an error message as following:
> "server doesn't respond" or the same thing said differently
> so there are files that are not to be deleted lika that, which i knew but not
> which ones.
>
> i read once that they were sockets.
>
>
Maybe, instead of cron, you should empty your /tmp at shutdown.....
Il always worked for me.

heavytull <heavytull********.com> writes:

>I have already put many times the question on how to Kron properly a /tmp
>cleaning job under linux, and still no clear response.
>I'm trying to be clearer evertime.

People keep answering this question.


>I put this following in the kron manager (Kcron)
>/usr/bin/find /tmp -atime +15 -type f -o -type d -exec /bin/rm -rf '{}' \;


>when it first was run, I couldn't do all the things as usual under X,
>there was always an error message as following:
>"server doesn't respond" or the same thing said differently
>so there are files that are not to be deleted lika that, which i knew but not
>which ones.

>i read once that they were sockets.

IF your system is in use for more than 15 days, yes, you could run into
trouble. But the problem seems to me your recursive erasure on directories.
Why do that? If you want to remove directories, run the above for files
first and then run another find on directories. Ie, youcould have
directories with recent files, which would get clobbered with your
recursive erase of the directories.
Ie
/usr/bin/find /tmp -atime +15 -type f -exec /bin/rm -f \{\} \;
/usr/bin/find /tmp -type d -exec /bin/rmdir \{\} \;
This will only remove directories which are actually empty.

Unruh wrote:

> heavytull <heavytull********.com> writes:
>
>>I have already put many times the question on how to Kron properly a /tmp
>>cleaning job under linux, and still no clear response.
>>I'm trying to be clearer evertime.
>
> People keep answering this question.
>
>
>>I put this following in the kron manager (Kcron)
>>/usr/bin/find /tmp -atime +15 -type f -o -type d -exec /bin/rm -rf '{}' \;
>
>
>>when it first was run, I couldn't do all the things as usual under X,
>>there was always an error message as following:
>>"server doesn't respond" or the same thing said differently
>>so there are files that are not to be deleted lika that, which i knew but not
>>which ones.
>
>>i read once that they were sockets.
>
> IF your system is in use for more than 15 days, yes, you could run into
> trouble. But the problem seems to me your recursive erasure on directories.
actually you make me notice an error that I missed by lack of attention.
yes i'm removing directories recursively.
i though rm -r was equivalent to rmdir
i actually don't remember why i used the -f option


> Why do that? If you want to remove directories, run the above for files
> first and then run another find on directories. Ie, youcould have
> directories with recent files, which would get clobbered with your
> recursive erase of the directories.
> Ie
> /usr/bin/find /tmp -atime +15 -type f -exec /bin/rm -f \{\} \;
could you explain the use of \ in {}?
what is it for?

anyway, that doesn't seem to work

look:

$ find ./ -type f -o -type d
../
../ff
../ff/kok
../ji
the ./ff/kok and ./ji are files

so find ./ -type f -o -type d -exec /bin/rm -f \{} \; should remove it;
$ find ./ -type f -o -type d -exec /bin/rm -f \{} \;
/bin/rm: cannot remove `./': Is a directory
/bin/rm: cannot remove `./ff': Is a directory

and still
$ find ./ -type f -o -type d
../
../ff
../ff/kok
../ji

../ff/kok and ./ji were not removed

anyway if i use
$ find ./ -type f -o -exec /bin/rm -f \{} \; it works

see
$ find ./ -type d
../
../ff

but
$ find ./ -type d -exec /bin/rmdir \{\} \;
/bin/rmdir: ./: Invalid argument
find: ./ff: No such file or directory

although ./ff was actually removed by this latter command

see
$ find ./ -type d
../

is there an option for find to omit the ./ for -exec??




> /usr/bin/find /tmp -type d -exec /bin/rmdir \{\} \;
> This will only remove directories which are actually empty.

--
heavytull

heavytull wrote:
> I have already put many times the question on how to Kron properly a /tmp
> cleaning job under linux, and still no clear response.
> I'm trying to be clearer evertime.

There is a tool for cleaning up /tmp and other directories, but still I see a
lot of people reinvent the wheel. Check for tmpwatch.


--

//Aho

heavytull wrote:

....
>>>/usr/bin/find /tmp -atime +15 -type f -o -type d -exec /bin/rm -rf '{}' \;
....
> actually you make me notice an error that I missed by lack of attention.
> yes i'm removing directories recursively.
> i though rm -r was equivalent to rmdir

-r means recursively

> i actually don't remember why i used the -f option

-f means forcebly remove, regardless of perms (subject to write to directory
& non-sticky, unless root)

>>Why do that? If you want to remove directories, run the above for files
>>first and then run another find on directories. Ie, youcould have
>>directories with recent files, which would get clobbered with your
>>recursive erase of the directories.

Still a good point.

>> /usr/bin/find /tmp -atime +15 -type f -exec /bin/rm -f \{\} \;
>>
> could you explain the use of \ in {}?
> what is it for?

to prevent the shell[1] from trying to interpret them. The backslash (\)
literally quotes the next character. You had the {} within single quotes
(') which also does the same thing - quotes a literal string to prevent
shell[1] interpretation of meta characters.

[1] from normal interactive use, I haven't found the need to quote them, but
I've never tried (myself) to cron-adise them.

> anyway, that doesn't seem to work
>
> look:
>
> $ find ./ -type f -o -type d
> ./
> ./ff
> ./ff/kok
> ./ji
> the ./ff/kok and ./ji are files
>
> so find ./ -type f -o -type d -exec /bin/rm -f \{} \; should remove it;
> $ find ./ -type f -o -type d -exec /bin/rm -f \{} \;

You should also be quoting the close '}' as in '...-f \{\} \;' (like you
quote the semicolon to prevent the shell from interpreting it, though I'm
not sure they need quoting)

> /bin/rm: cannot remove `./': Is a directory
> /bin/rm: cannot remove `./ff': Is a directory

rm doesn't normally remove directories unless being done recursively; you
need to specifically tell it to:

$ man rm
....
OPTIONS
Remove (unlink) the FILE(s).

-d, --directory
unlink directory, even if non-empty (super-user
only)
....

It's [probably] designed as a "safety" feature - to make you think about
what you're removing.

> anyway if i use
> $ find ./ -type f -o -exec /bin/rm -f \{} \; it works

Mefinx you've missed a bit of copying your command there: '...-o -exec...'

....
> $ find ./ -type d -exec /bin/rmdir \{\} \;
> /bin/rmdir: ./: Invalid argument

Suspect rmdir won't remove current directory as a sensible protection -
where would your current directory be afterwards?

> find: ./ff: No such file or directory

That's because on finding it, it was removed THEN find tried to go into it
to find further files (of type d: directory).


> is there an option for find to omit the ./ for -exec??

$ find -type d
..
../Desktop
../Desktop/Trash
....
$ find -not -name '.' -type d
../Desktop
../Desktop/Trash
....

Curiously, in my experiments, if I specify a directory for the start of the
find, the -not -name bit don't work.

Instead of using

/usr/bin/find /tmp -atime +15 -type f -o -type d -exec /bin/rm -rf '{}' \;

try using:

/usr/bin/find /tmp -atime +15 -type f -o -type d -print0 | xargs -0 /bin/rm -f

Using -exec uses another process for each file found whereas using xargs
will string together as many files onto the command as can fit on the
command line to each instance of /bin/rm and so is more process-friendly and
slightly quicker.


My system has a tmp cleaner which runs on a cron.daily loop. It removes
files, but not directories using: /usr/sbin/tmpwatch

$ man tmpwatch
TMPWATCH(8) TMPWATCH(8)

NAME
tmpwatch - removes files which haven't been accessed for a
period of time
....

The tmp cleaner does:

/usr/sbin/tmpwatch 240 /tmp /var/tmp
/usr/sbin/tmpwatch -f 240 /var/catman/{X11R6/cat?,cat?,local/cat?}

which cleans out unused files in /tmp, /var/tmp and man pages that have been
decompressed and stored as a result of being read, all of which haven't been
accessed for 10 days. However, it does leave directory structures intact,
just empty.

J.O. Aho wrote:

> heavytull wrote:
>> I have already put many times the question on how to Kron properly a /tmp
>> cleaning job under linux, and still no clear response.
>> I'm trying to be clearer evertime.
>
> There is a tool for cleaning up /tmp and other directories, but still I see a
> lot of people reinvent the wheel. Check for tmpwatch.
>
>
if find can everything i need then why would i use another programm.
i like to see things clear. I would use another programm only if find is really
dumb which i don't think. Also I think that Pat. Volkerding would have added
tmpwatch if it was really useful, unless it is unstable. Stability, Simplicity
and lightness are the main concerns of Pat. Vokerding.


--
heavytull

heavytull <heavytull********.com> writes:

>J.O. Aho wrote:

>> heavytull wrote:
>>> I have already put many times the question on how to Kron properly a /tmp
>>> cleaning job under linux, and still no clear response.
>>> I'm trying to be clearer evertime.
>>
>> There is a tool for cleaning up /tmp and other directories, but still I see a
>> lot of people reinvent the wheel. Check for tmpwatch.
>>
>>
>if find can everything i need then why would i use another programm.
>i like to see things clear. I would use another programm only if find is really
>dumb which i don't think. Also I think that Pat. Volkerding would have added
>tmpwatch if it was really useful, unless it is unstable. Stability, Simplicity
>and lightness are the main concerns of Pat. Vokerding.

Apparently you do not want your questions answered. You ask how to clean
tmp. You ae given suggestions. You then slang the suggestions. You may do
with the suggestions what you want-- that is your right. But please do not
come back here complaining that noone helps you. o

To answer your question you might use tmpwatch because the author has spent
some time figuring what could go wrong and avoiding those mistakes. But
apparently efficiency and robustness are not part of what you consider
important.




>--
>heavytull

heavytull wrote:
> J.O. Aho wrote:
>
>> heavytull wrote:
>>> I have already put many times the question on how to Kron properly a /tmp
>>> cleaning job under linux, and still no clear response.
>>> I'm trying to be clearer evertime.
>> There is a tool for cleaning up /tmp and other directories, but still I see a
>> lot of people reinvent the wheel. Check for tmpwatch.
>>
>>
> if find can everything i need then why would i use another programm.

As you seem to delete files that you shouldn't.

> i like to see things clear. I would use another programm only if find is really
> dumb which i don't think. Also I think that Pat. Volkerding would have added
> tmpwatch if it was really useful, unless it is unstable. Stability, Simplicity
> and lightness are the main concerns of Pat. Vokerding.

Maybe he thinks you should get it yourself if you get overflooded /tmp
directories. Something that talks against your description of Mr. Volkerding
is that Slack has gnome2.


--

//Aho

On Mon, 16 Apr 2007 06:28:35 +0200, J.O. Aho wrote:

> Maybe he thinks you should get it yourself if you get overflooded /tmp
> directories. Something that talks against your description of Mr. Volkerding
> is that Slack has gnome2.

No it doesn't. Gnome hasn't been distributed with Slackware for the last
few releases.

paul_s

Unruh wrote:

> heavytull <heavytull********.com> writes:
>
>>J.O. Aho wrote:
>
>>> heavytull wrote:
>>>> I have already put many times the question on how to Kron properly a /tmp
>>>> cleaning job under linux, and still no clear response.
>>>> I'm trying to be clearer evertime.
>>>
>>> There is a tool for cleaning up /tmp and other directories, but still I see
>>> a lot of people reinvent the wheel. Check for tmpwatch.
>>>
>>>
>>if find can everything i need then why would i use another programm.
>>i like to see things clear. I would use another programm only if find is
>>really dumb which i don't think. Also I think that Pat. Volkerding would have
>>added tmpwatch if it was really useful, unless it is unstable. Stability,
>>Simplicity and lightness are the main concerns of Pat. Vokerding.
>
> Apparently you do not want your questions answered. You ask how to clean
> tmp. You ae given suggestions. You then slang the suggestions. You may do
> with the suggestions what you want-- that is your right. But please do not
> come back here complaining that noone helps you. o
>
> To answer your question you might use tmpwatch because the author has spent
> some time figuring what could go wrong and avoiding those mistakes. But
> apparently efficiency and robustness are not part of what you consider
> important.
>
>
you still don't give any technical reason why using tmpwatch
so i'm still waiting for wise people. not blind consummers.



there are a lot of people that spend time programming for nothing.

>
>
>>--
>>heavytull

--
heavytull

heavytull <heavytull********.com> writes:

>Unruh wrote:

>> heavytull <heavytull********.com> writes:
>>
>>>J.O. Aho wrote:
>>
>>>> heavytull wrote:
>>>>> I have already put many times the question on how to Kron properly a /tmp
>>>>> cleaning job under linux, and still no clear response.
>>>>> I'm trying to be clearer evertime.
>>>>
>>>> There is a tool for cleaning up /tmp and other directories, but still I see
>>>> a lot of people reinvent the wheel. Check for tmpwatch.
>>>>
>>>>
>>>if find can everything i need then why would i use another programm.
>>>i like to see things clear. I would use another programm only if find is
>>>really dumb which i don't think. Also I think that Pat. Volkerding would have
>>>added tmpwatch if it was really useful, unless it is unstable. Stability,
>>>Simplicity and lightness are the main concerns of Pat. Vokerding.
>>
>> Apparently you do not want your questions answered. You ask how to clean
>> tmp. You ae given suggestions. You then slang the suggestions. You may do
>> with the suggestions what you want-- that is your right. But please do not
>> come back here complaining that noone helps you. o
>>
>> To answer your question you might use tmpwatch because the author has spent
>> some time figuring what could go wrong and avoiding those mistakes. But
>> apparently efficiency and robustness are not part of what you consider
>> important.
>>
>>
>you still don't give any technical reason why using tmpwatch
>so i'm still waiting for wise people. not blind consummers.


Do you know something, it is not surprizing that you get no answers to your
questions, since it is pointless giving you answers. You refuse to do your
own homework and reject things people suggest on the basis of completely
off the wall arguments. Noone is forcing you to do anything, ( and note
that tmpwatch is part of most linux distros and is used by many to do
exactly what you want)
man tmpwatch.



>there are a lot of people that spend time programming for nothing.

And there are a lot of people who waste other's time by asking questions
they have no intention of listening to answers for.


>>
>>
>>>--
>>>heavytull

>--
>heavytull

Unruh wrote:

> heavytull <heavytull********.com> writes:
>
>>Unruh wrote:
>
>>> heavytull <heavytull********.com> writes:
>>>
>>>>J.O. Aho wrote:
>>>
>>>>> heavytull wrote:
>>>>>> I have already put many times the question on how to Kron properly a /tmp
>>>>>> cleaning job under linux, and still no clear response.
>>>>>> I'm trying to be clearer evertime.
>>>>>
>>>>> There is a tool for cleaning up /tmp and other directories, but still I
>>>>> see a lot of people reinvent the wheel. Check for tmpwatch.
>>>>>
>>>>>
>>>>if find can everything i need then why would i use another programm.
>>>>i like to see things clear. I would use another programm only if find is
>>>>really dumb which i don't think. Also I think that Pat. Volkerding would
>>>>have added tmpwatch if it was really useful, unless it is unstable.
>>>>Stability, Simplicity and lightness are the main concerns of Pat. Vokerding.
>>>
>>> Apparently you do not want your questions answered. You ask how to clean
>>> tmp. You ae given suggestions. You then slang the suggestions. You may do
>>> with the suggestions what you want-- that is your right. But please do not
>>> come back here complaining that noone helps you. o
>>>
>>> To answer your question you might use tmpwatch because the author has spent
>>> some time figuring what could go wrong and avoiding those mistakes. But
>>> apparently efficiency and robustness are not part of what you consider
>>> important.
>>>
>>>
>>you still don't give any technical reason why using tmpwatch
>>so i'm still waiting for wise people. not blind consummers.
>
>
> Do you know something, it is not surprizing that you get no answers to your
> questions, since it is pointless giving you answers. You refuse to do your
> own homework and reject things people suggest on the basis of completely
> off the wall arguments. Noone is forcing you to do anything, ( and note
> that tmpwatch is part of most linux distros and is used by many to do
> exactly what you want)
> man tmpwatch.
>

you're wrong!
i did search quite enough about tmpwatch, i know its manpage, i haven't found
any particular reason to use it instead of find.
i though s.o. could tell me the difference. i believe it is just simpler to use.


>
>
>>there are a lot of people that spend time programming for nothing.
>
> And there are a lot of people who waste other's time by asking questions
> they have no intention of listening to answers for.
>
that's enough don't cry
>
>>>
>>>
>>>>--
>>>>heavytull
>
>>--
>>heavytull

--
heavytull

heavytull wrote:

....
> you're wrong!
> i did search quite enough about tmpwatch, i know its manpage, i haven't found
> any particular reason to use it instead of find.

Perhaps you haven't investigated find enough then?

> i though s.o. could tell me the difference. i believe it is just simpler to use.

It may be simpler to use than find for clearing out temporary files as that
is the specific purpose for which it was written with the KISS mentality.
find is a general purpose file finder; what you do with the files it finds
is up to you and requires [an] extra process[es]. tmpwatch is specifically
designed to remove files not accessed over a given number of hours ago;
however, it leaves directory structures - useful for certain "system"
commands, like man: man pages are stored compressed to save disk space and
so are expanded when needed and stored so that they are there uncompressed
ready for the next reading; however, if nobody has read the page for a
while, using tmpwatch the system removes the uncompressed version, but
leaves the directory structure, even if all the uncompressed pages are
removed so that expanding a compressed page will still have somewhere to be put.

You are aware that when you use '-exec ... {} \;' with find it creates a new
process for every instance of a file that is found. So if your temporary
directory has lots of files and you use '-exec rm -f {} \;' that will create
lots of processes, each removing one file complete with the overhead of the
'fork(); exec();' along with the overhead of decoding the argument(s)
supplied before the actual 'unlink();'. Using tmpwatch, the moment the file
is found, it can be 'unlink();'ed there and then with none of these
overheads and thus be more efficient.

An alternative to using '-exec ... \;' is to use '-print0 | xargs -0 rm -f'
which is more efficient as xargs will attempt to put as many entries from
its input onto the arg list of the command given before 'fork();'ing to
'exec();' the command. Thus it will have less process creation overheads
and less argument decoding overheads, but it still requires at least 2 extra
processes (unless xargs just 'exec();'s the final command after it has
received the last input entry, when obviously, if not enough files are used,
only 1 extra process will be needed).

It all boils down to efficiency: using tmpwatch, once the file is found, it
can be 'unlink();'ed immediately without the intermediate steps of compiling
an argument list for another command which has to be found and 'exec();'ed
before the list is then decoded before the 'unlink();' can be done.

>>>there are a lot of people that spend time programming for nothing.

Which has been proven by people spending time programming stuff for which
others have already provided a[n efficient] solution which is freely available.

Why re-invent a wheel when there's already a better wheel available to use
(other than to prove that you can do it and learn the tools in the process;
just remember to consider how much efficiency is of importance to you, along
with [data] security (knowing any change will mean that what you are trying
to achieve actually happens - you won't [accidently] introduce a bug).

tmpwatch is an efficient method of removing old, unused files. On a busy
system that's not for nothing.

Robert Newson wrote:
> tmpwatch is an efficient method of removing old, unused files.
> On a busy system that's not for nothing.

Yep. :)
Someone felt a need, made it and shared it with others.
Pretty stinkin cool IMO. :)

Two to four letter commands is more my style tho. :/

Alvin using Tin&Pico in AZ