I'm running F15. Files are mysteriously being removed from /tmp after a number of days of not being touched. I am familiar with /etc/cron.daily/tmpwatch and, in fact, modify it to inhibit removal of files from /tmp. In the past this has worked. Under F15 it has not.
Two or three weeks ago I deleted it from /etc/cron.daily but older files _still_ get removed from /tmp. I've rebooted at least once. I'm not sure if it happens at bootup or while the system is running, but something is still removing files from /tmp.
Does anyone know of another mechanism for this?
Thanks. Dean
On 05/03/2012 11:24 AM, Jeoe Zeff wrote:
On 05/02/2012 07:47 PM, Dean S. Messing wrote:
Does anyone know of another mechanism for this?
Just out of curiosity, why don't you want files to be removed from /tmp?
That question raises a question that I've been wanting to ask several times. So, although I'm asking it in this thread, it isn't solely directed at you.
When someone on this list asks for help in modifying a behavior to suit their needs/desires why are they often asked to justify their requests? In this case, and in may others, I can't see that seeking/offering justification will help in finding a solution.
Ed Greshko wrote:
That question raises a question that I've been wanting to ask several times. So, although I'm asking it in this thread, it isn't solely directed at you.
When someone on this list asks for help in modifying a behavior to suit their needs/desires why are they often asked to justify their requests? In this case, and in may others, I can't see that seeking/offering justification will help in finding a solution.
没关系 (Ed, I suppose you read zhōngwén).
Joe said it himself: "Out of curiosity." I'm easy so I humoured his request. Now I'm hoping for some payback. :-)
Dean
On Thu, 2012-05-03 at 11:40 +0800, Ed Greshko wrote:
On 05/03/2012 11:24 AM, Jeoe Zeff wrote:
On 05/02/2012 07:47 PM, Dean S. Messing wrote:
Does anyone know of another mechanism for this?
Just out of curiosity, why don't you want files to be removed from /tmp?
That question raises a question that I've been wanting to ask several times. So, although I'm asking it in this thread, it isn't solely directed at you.
When someone on this list asks for help in modifying a behavior to suit their needs/desires why are they often asked to justify their requests? In this case, and in may others, I can't see that seeking/offering justification will help in finding a solution.
Anyone who finds himself (officially or unofficially) in a support role soon learns that it can make all the difference if you understand what the user is actually trying to do, rather than just taking his question at face value. Maybe not that relevant in this case, but your comment was directed more broadly.
poc
On 05/03/2012 12:00 PM, Patrick O'Callaghan wrote:
Anyone who finds himself (officially or unofficially) in a support role soon learns that it can make all the difference if you understand what the user is actually trying to do, rather than just taking his question at face value. Maybe not that relevant in this case, but your comment was directed more broadly.
Well, having done hardware support for more years than I care to count, in this case and the others that brought that question to mind were cases in which the desire was fully and clearly expressed. And, the question being asked wasn't of the variety of "do you want this or this?" or "can you explain a bit more of what you want?". It was "why do you want to do that?".
I suppose it may just be a case of "curiosity" and it is then incumbent on the person being asked to decide if they wish to answer.
Just strikes me as odd when these types of questions are asked with no apparent benefit to resolving the original question.
On 05/02/2012 08:40 PM, Ed Greshko wrote:
When someone on this list asks for help in modifying a behavior to suit their needs/desires why are they often asked to justify their requests?
I can't speak for anybody else on the list, but my question was prompted by nothing more than curiosity. If I had an answer for the OP, I'd have included it in the reply.
On Thu, 2012-05-03 at 11:40 +0800, Ed Greshko wrote:
When someone on this list asks for help in modifying a behavior to suit their needs/desires why are they often asked to justify their requests?
Probably because the intent is not to "justify" but to "clarify", and we geeks are often fairly blunt about how we phrase things. As a sysadmin, I frequently have users ask how to do something, and I often have to ask them to clarify what they are really trying to accomplish, because often what they have asked me how to do is far from the best way to accomplish their real goal. The users are practicing medicine without a license (or in this case, misdiagnosing the issue).
Here's a dumb example: it's like somebody asking how to survive cutting off a finger. If what they really want is for the hangnail to stop hurting, you certainly wouldn't advise them to cut off the finger! SO when somebody at work asks me how to do something that seems analagous to cutting off a finger, I respond by asking them what it is they are really trying to accomplish. If somebody has already started down the wrong path, the best way out of the forest may very well be to backtrack a bit first.
--Greg
On Thu, 3 May 2012, Ed Greshko wrote:
On 05/03/2012 11:24 AM, Jeoe Zeff wrote:
On 05/02/2012 07:47 PM, Dean S. Messing wrote:
Does anyone know of another mechanism for this?
Just out of curiosity, why don't you want files to be removed from /tmp?
When someone on this list asks for help in modifying a behavior to suit their needs/desires why are they often asked to justify their requests? In this case, and
I've been on the receiving end, so I've felt your pain. Often it's just a rude "Don't do that.".
In this case, curiosity might have been inspired by your desire to defeat a purpose for which something exists. I'd have been inclined to include the inspiration along with the question.
Sometimes the right answer is you can do that if you really want, but it's dangerous and it's a lot of work with hard to explain details that depend on what you want it for.
Once upon a time, someone asked how to remove all traces of gnome.
Sometimes it's just a matter of religion. Ask a question about using labels instead of UUIDs.
in may others, I can't see that seeking/offering justification will help in finding a solution.
In this case, it might be helpful with a work around.
If you disapprove of cleaning, you might consider creating a /clutter with the same permissions as /tmp .
On Wed, May 2, 2012 at 11:40 PM, Ed Greshko Ed.Greshko@greshko.com wrote:
On 05/03/2012 11:24 AM, Jeoe Zeff wrote:
On 05/02/2012 07:47 PM, Dean S. Messing wrote:
Does anyone know of another mechanism for this?
Just out of curiosity, why don't you want files to be removed from /tmp?
That question raises a question that I've been wanting to ask several times. So, although I'm asking it in this thread, it isn't solely directed at you.
When someone on this list asks for help in modifying a behavior to suit their needs/desires why are they often asked to justify their requests? In this case, and in may others, I can't see that seeking/offering justification will help in finding a solution.
This is often referred to as the "XY Problem" where a questioner has problem X, has determined to solve it with solution Y, and is asking for help getting solution Y to do what it is they think it should do. In fact, solution Y may not be be the optimal solution, and there may be a well-known and reliable solution to problem X. So, asking "why do you want to do this?" often leads to the real problem, and a better solution.
Ref: http://www.catb.org/~esr/faqs/smart-questions.html#id479492
Am 05.05.2012 15:28, schrieb Ted Roche:
On Wed, May 2, 2012 at 11:40 PM, Ed Greshko Ed.Greshko@greshko.com wrote:
When someone on this list asks for help in modifying a behavior to suit their needs/desires why are they often asked to justify their requests? In this case, and in may others, I can't see that seeking/offering justification will help in finding a solution.
This is often referred to as the "XY Problem" where a questioner has problem X, has determined to solve it with solution Y, and is asking for help getting solution Y to do what it is they think it should do. In fact, solution Y may not be be the optimal solution, and there may be a well-known and reliable solution to problem X. So, asking "why do you want to do this?" often leads to the real problem, and a better solution.
Ref: http://www.catb.org/~esr/faqs/smart-questions.html#id479492
especially in this case
why storing data in /tmp and search how to change behavior of the OS instead simply use another directory and accept that /tmp is NOT a place where you can expect your data are alive at any time later?
mkdir /mytmp chmod 1777 /mytmp
so, now you have a folder with the same permissions as /tmp everybody can store files there, only the owner have access to them and nothing of the OS is touching it
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/05/2012 08:42 AM, Reindl Harald wrote:
Am 05.05.2012 15:28, schrieb Ted Roche:
On Wed, May 2, 2012 at 11:40 PM, Ed Greshko
Ed.Greshko@greshko.com wrote:
When someone on this list asks for help in modifying a behavior
to suit their
needs/desires why are they often asked to justify their requests?
In this case, and
in may others, I can't see that seeking/offering justification
will help in finding a
solution.
This is often referred to as the "XY Problem" where a questioner has problem X, has determined to solve it with solution Y, and is asking for help getting solution Y to do what it is they think it should do. In fact, solution Y may not be be the optimal solution, and there may be a well-known and reliable solution to problem X. So, asking "why do you want to do this?" often leads to the real problem, and a better solution.
Ref: http://www.catb.org/~esr/faqs/smart-questions.html#id479492
especially in this case
why storing data in /tmp and search how to change behavior of the OS instead simply use another directory and accept that /tmp is NOT a place where you can expect your data are alive at any time later?
mkdir /mytmp chmod 1777 /mytmp
so, now you have a folder with the same permissions as /tmp everybody can store files there, only the owner have access to them and nothing of the OS is touching it
The way I do it is to create a tmp directory in each user's home directory. (Add to /etc/skel) Then I have TMP set to this directory. (Add local.sh and local.csh in /etc/profile.d) This works for programs that honor TMP and is easy to add to scripts.
if [ -z $TMP ] then temp_file=/tmp/dd.$$ else temp_file=$TMP/dd.$$ fi
Mikkel - -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
Mikkel L. Ellertson wrote: <snip>
The way I do it is to create a tmp directory in each user's home directory. (Add to /etc/skel) Then I have TMP set to this directory. (Add local.sh and local.csh in /etc/profile.d) This works for programs that honor TMP and is easy to add to scripts.
if [ -z $TMP ] then temp_file=/tmp/dd.$$ else temp_file=$TMP/dd.$$ fi
Thanks, Mikkel, for this excellent alternative to using /tmp.
Dean
On Wed, 02 May 2012 at 20:24:46 Joe Zeff joe@zeff.us wrote:
On 05/02/2012 07:47 PM, Dean S. Messing wrote:
Does anyone know of another mechanism for this?
Just out of curiosity, why don't you want files to be removed from /tmp?
Because I have the bad habit of sometimes creating directories in /tmp to try experiments in. I also sometimes stick research papers and other tidbits from the web in /tmp till I have time to think about where to properly file them. Then I don't.
In any case I've operated for years this way. I just hand-clean the cruft every so often. You can't teach on old dog ...
Now that you know my dirty little secret, can you tell me what could be gratuitously cleaning /tmp?
Dean
On 05/02/2012 08:44 PM, Dean S. Messing wrote:
Now that you know my dirty little secret, can you tell me what could be gratuitously cleaning /tmp?
Thank you for satisfying my curiosity. Alas, the only thing I could have suggested is tmpwatch, and you've already eliminated that as a possibility. However, now that I think about it, do you have BleachBit set to run at boot, or any other time automatically? If so, it might be set to clear /tmp.
Joe Zeff wrote:
On 05/02/2012 08:44 PM, Dean S. Messing wrote:
Now that you know my dirty little secret, can you tell me what could be gratuitously cleaning /tmp?
Thank you for satisfying my curiosity. Alas, the only thing I could have suggested is tmpwatch, and you've already eliminated that as a possibility. However, now that I think about it, do you have BleachBit set to run at boot, or any other time automatically? If so, it might be set to clear /tmp.
I was unaware of BleachBit. Unfortunately, both
locate -i bleach
and
rpm -qa | fgrep -i bleach
return the null string. Thanks for the suggestion. This is really quite frustrating. It's like I have a daemon on my system.
Dean
On 05/03/2012 12:05 PM, Joe Zeff wrote:
do you have BleachBit set to run at boot, or any other time automatically? If so, it might be set to clear /tmp.
It does not appear that bleachbit is in the Fedora repositories or rpmfusion. Seems if one wanted to install it they would have had to downloaded it from sourceforge and configured it. Would be hard to forget that....I hope. :-) :-)
On 03/05/12 07:40, Ed Greshko wrote:
On 05/03/2012 12:05 PM, Joe Zeff wrote:
do you have BleachBit set to run at boot, or any other time automatically? If so, it might be set to clear /tmp.
It does not appear that bleachbit is in the Fedora repositories or rpmfusion. Seems if one wanted to install it they would have had to downloaded it from sourceforge and configured it. Would be hard to forget that....I hope. :-) :-)
http://koji.fedoraproject.org/koji/packageinfo?packageID=8886
2012-05-03 08:40, Ed Greshko skrev:
On 05/03/2012 12:05 PM, Joe Zeff wrote:
do you have BleachBit set to run at boot, or any other time automatically? If so, it might be set to clear /tmp.
It does not appear that bleachbit is in the Fedora repositories or rpmfusion. Seems if one wanted to install it they would have had to downloaded it from sourceforge and configured it. Would be hard to forget that....I hope. :-) :-)
yum search BleachBit ... =========================== N/S matchade: BleachBit ============================ bleachbit.noarch : Remove unnecessary files, free space, and maintain privacy
So bleachbit is in the Fedora 16 ;-) (Repo fedora)
On 05/03/2012 02:54 PM, Jon Ingason wrote:
yum search BleachBit ... =========================== N/S matchade: BleachBit ============================ bleachbit.noarch : Remove unnecessary files, free space, and maintain privacy
So bleachbit is in the Fedora 16 ;-) (Repo fedora)
That's weird.... must have had a network hiccup when I first checked.
Am 03.05.2012 08:40, schrieb Ed Greshko:
On 05/03/2012 12:05 PM, Joe Zeff wrote:
do you have BleachBit set to run at boot, or any other time automatically? If so, it might be set to clear /tmp.
It does not appear that bleachbit is in the Fedora repositories or rpmfusion. Seems if one wanted to install it they would have had to downloaded it from sourceforge and configured it. Would be hard to forget that....I hope. :-) :-)
says who?
---> Paket bleachbit.noarch 0:0.8.7-1.fc16 markiert, um installiert zu werden --> Abhängigkeitsauflösung beendet
Abhängigkeiten aufgelöst
========================================================================================================================= Package Arch Version Repository Größe ========================================================================================================================= Installieren: bleachbit noarch 0.8.7-1.fc16 fedora 307 k
Dean S. Messing writes:
I'm running F15. Files are mysteriously being removed from /tmp after a number of days of not being touched. I am familiar with /etc/cron.daily/tmpwatch and, in fact, modify it to inhibit removal of files from /tmp. In the past this has worked. Under F15 it has not.
Two or three weeks ago I deleted it from /etc/cron.daily but older files _still_ get removed from /tmp. I've rebooted at least once. I'm not sure if it happens at bootup or while the system is running, but something is still removing files from /tmp.
Does anyone know of another mechanism for this?
I would check for the low-hanging fruit. Exactly the nature of your modifications to tmpwatch. Without knowing its history, its possible that its options have changed, and your custom changes no longer do the same thing they do before. Double-check the manpage. Especially since, I see, /etc/cron.daily/tmpwatch is %config(noreplace), so if tmpwatch's options have changed, and aren't backwards compatible, and updating the tmpwatch package won't clobber the existing file, as a result the options you have in there may no longer work.
Or, perhaps, gathering some more data would point to the likely culprit. If the files in your tmp get deleted after a consistent period of time, that would offer a clue.
But, sometimes, tilting at windmills is not very productive. /tmp's never meant to be used to archive anything. I wouldn't put anything in /tmp that I'll want to make sure it'll still be there, tomorrow, even if nothing supposed to get nuked from there for weeks. Might be easier to change one's habits.
I'd create a folder in my home, or in my Desktop directory, for stuff that I haven't yet decided where it needs to go, permanently.
Sam Varshavchik wrote:
Dean S. Messing writes:
I'm running F15. Files are mysteriously being removed from /tmp after a number of days of not being touched. I am familiar with /etc/cron.daily/tmpwatch and, in fact, modify it to inhibit removal of files from /tmp. In the past this has worked. Under F15 it has not.
Two or three weeks ago I deleted it from /etc/cron.daily but older files _still_ get removed from /tmp. I've rebooted at least once. I'm not sure if it happens at bootup or while the system is running, but something is still removing files from /tmp.
Does anyone know of another mechanism for this?
I would check for the low-hanging fruit. Exactly the nature of your modifications to tmpwatch. Without knowing its history, its possible that its options have changed, and your custom changes no longer do the same thing they do before. Double-check the manpage. Especially since, I see, /etc/cron.daily/tmpwatch is %config(noreplace), so if tmpwatch's options have changed, and aren't backwards compatible, and updating the tmpwatch package won't clobber the existing file, as a result the options you have in there may no longer work.
Well, as I said in my OP, tmpwatch is no longer even involved. I removed it from /etc/cron.daily. So unless it's ghost is still there, I'm at loss to explain the behaviour. FYI, my mod to tmpwatch was merely to comment out the lines:
#/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \ # -x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \ # -X '/tmp/hsperfdata_*' 10d /tmp
When files continued to disappear, I moved tmpwatch out of /etc/cron.daily. Alas, they still do.
Or, perhaps, gathering some more data would point to the likely culprit. If the files in your tmp get deleted after a consistent period of time, that would offer a clue.
They seem to disappear after about 14 days. But it might be slightly more or less. Untouched files get removed. And directories containing untouched files get cleaned out leaving an empty dir behind. This is just
But, sometimes, tilting at windmills is not very productive. /tmp's never meant to be used to archive anything. I wouldn't put anything in /tmp that I'll want to make sure it'll still be there, tomorrow, even if nothing supposed to get nuked from there for weeks. Might be easier to change one's habits.
Something I've done for a decade w/o issues is hardly tilting at windmills. Be that as it may, I have become extremely curious as to what in F15 might be doing the deed.
I'd create a folder in my home, or in my Desktop directory, for stuff that I haven't yet decided where it needs to go, permanently.
Right now I'd simply like to understand why F15 (and I suppose F16) behaves this way. F13 and prior certainly didn't. I never ran F14.
Dean
On Wed, 2012-05-02 at 19:47 -0700, Dean S. Messing wrote:
older files _still_ get removed from /tmp. I've rebooted at least once.
While I can't answer to why old files might be disappearing, other than to check more than just *daily* CRON entries (hourly, weekly, specific hours of the day), I'll suggest one thing: If you want to keep /tmp contents through a reboot, make sure that /tmp isn't mounted as tmpfs.
On Thu, 03 May 2012 at 15:40:40, Tim wrote:
While I can't answer to why old files might be disappearing, other than to check more than just *daily* CRON entries (hourly, weekly, specific hours of the day), I'll suggest one thing: If you want to keep /tmp contents through a reboot, make sure that /tmp isn't mounted as tmpfs.
Thanks. Checked those. weekly is empty. hourly contains the anacron trigger file and "mcelog.cron" which contains only comments.
Not sure what you mean by specific hours of the day. I don't know how to tell when a file is removed from /tmp/, if that's what you mean.
/tmp is not mounted at all on my system. It is a merely an ordinary subdir of /.
Thanks for the suggestions. Keep 'em coming.
Dean
Dean S. Messing <deanm <at> sharplabs.com> writes:
Not sure what you mean by specific hours of the day. I don't know how to tell when a file is removed from /tmp/, if that's what you mean.
yum install inotify-tools
man inotifywait
You could write a little script that saves ps output at the instant a file gets deleted.
On 05/03/2012 02:35, deanm@sharplabs.com wrote:
On Thu, 03 May 2012 at 15:40:40, Tim wrote:
While I can't answer to why old files might be disappearing, other than to check more than just *daily* CRON entries (hourly, weekly, specific hours of the day), I'll suggest one thing: If you want to keep /tmp contents through a reboot, make sure that /tmp isn't mounted as tmpfs.
Thanks. Checked those. weekly is empty. hourly contains the anacron trigger file and "mcelog.cron" which contains only comments.
Not sure what you mean by specific hours of the day. I don't know how to tell when a file is removed from /tmp/, if that's what you mean.
/tmp is not mounted at all on my system. It is a merely an ordinary subdir of /.
Thanks for the suggestions. Keep 'em coming.
Dean
If you don't mind waiting you could put an audit watch on that directory and look for things unlinking files in the directory. Once you notice a file missing you can look through the audit logs for the syscall that did it and identify the offending process.
Dave
On Wed, 2012-05-02 at 19:47 -0700, Dean S. Messing wrote:
I'm running F15. Files are mysteriously being removed from /tmp after a number of days of not being touched. I am familiar with /etc/cron.daily/tmpwatch and, in fact, modify it to inhibit removal of files from /tmp. In the past this has worked. Under F15 it has not.
Two or three weeks ago I deleted it from /etc/cron.daily but older files _still_ get removed from /tmp. I've rebooted at least once. I'm not sure if it happens at bootup or while the system is running, but something is still removing files from /tmp.
Does anyone know of another mechanism for this?
Take a look in /var/spool/cron to see if some user crontab (like root) is running tmpwatch or deleting the files. Also perhaps a check of /etc/rc.local to see if something is causing this.
I'm not sure if it happens at bootup or while the system is running
I would say add a file to /tmp, leave it a while, check it is still present then reboot. After bootup see if it is still there.
If the problem isn't rebooting, then perhaps setup a cron job to monitor the files' existence (say check every few minutes) and email you when it has gone. It may give you more of an idea of when things are being deleted. You can also check /var/log/cron to see if some cron job is running causing the deletion at the time.
John.
On Wed, 02 May 2012 19:47:03 -0700, DSM (Dean) wrote:
I'm running F15. Files are mysteriously being removed from /tmp after a number of days of not being touched. I am familiar with /etc/cron.daily/tmpwatch and, in fact, modify it to inhibit removal of files from /tmp. In the past this has worked. Under F15 it has not.
Two or three weeks ago I deleted it from /etc/cron.daily but older files _still_ get removed from /tmp. I've rebooted at least once. I'm not sure if it happens at bootup or while the system is running, but something is still removing files from /tmp.
Does anyone know of another mechanism for this?
At least with recent systemd versions, there is the systemd-tmpfiles-clean service. Dunno whether it's available in F15. And it defaults to 10 days not 14, I think: "man tmpfiles.d"
On Thu, May 3, 2012 at 2:34 AM, Michael Schwendt mschwendt@gmail.com wrote:
On Wed, 02 May 2012 19:47:03 -0700, DSM (Dean) wrote:
I'm running F15. Files are mysteriously being removed from /tmp after a number of days of not being touched. I am familiar with /etc/cron.daily/tmpwatch and, in fact, modify it to inhibit removal of files from /tmp. In the past this has worked. Under F15 it has not.
Two or three weeks ago I deleted it from /etc/cron.daily but older files _still_ get removed from /tmp. I've rebooted at least once. I'm not sure if it happens at bootup or while the system is running, but something is still removing files from /tmp.
Does anyone know of another mechanism for this?
At least with recent systemd versions, there is the systemd-tmpfiles-clean service. Dunno whether it's available in F15. And it defaults to 10 days not 14, I think: "man tmpfiles.d"
Yes, F15 has this too.
As that man page indicates, you can exclude directories or files from being cleaned with the 'x' type. So, create a file /etc/tmpfiles.d/dont-clean-tmp-damnit.conf or such and put 'x /tmp' in it and systemd will stop cleaning your /tmp.
-T.C.
On Thu, 3 May 2012 at 11:34:03, Michael Schwendt wrote:
On Wed, 02 May 2012 19:47:03 -0700, DSM (Dean) wrote:
I'm running F15. Files are mysteriously being removed from /tmp after a number of days of not being touched. I am familiar with /etc/cron.daily/tmpwatch and, in fact, modify it to inhibit removal of files from /tmp. In the past this has worked. Under F15 it has not.
Two or three weeks ago I deleted it from /etc/cron.daily but older files _still_ get removed from /tmp. I've rebooted at least once. I'm not sure if it happens at bootup or while the system is running, but something is still removing files from /tmp.
Does anyone know of another mechanism for this?
At least with recent systemd versions, there is the systemd-tmpfiles-clean service. Dunno whether it's available in F15. And it defaults to 10 days not 14, I think: "man tmpfiles.d"
Sorry for not responding till now. I'm traveling and away from the offending system. But I do believe that you have found the culprit. I just remotely logged onto my F15 system at work and found
/usr/lib/tmpfiles.d/systemd.conf
which contains this line:
d /tmp 1777 root root 10d
Knowing NOTHING about "systemd" or this file format (yet), I'm taking the wild guess that the initial "d" stands for "delete". I will read up on this stuff, and verify that it is the cause. (Which raises the question: why does F15 contains two independent mechanisms for cleaning /tmp. Seems like a bug to me.)
I also want to give credit to David Hawes, who wrote me privately this morning and suggested the same solution as Michael. I just saw his e-mail. Many thanks to both of you for pointing me in the right direction! I can't verify now, but my gut tells me this is IT.
Time to head to my flight.
Dean
On Thu, 2012-05-03 at 12:01 -0700, Dean S. Messing wrote:
Sorry for not responding till now. I'm traveling and away from the offending system. But I do believe that you have found the culprit. I just remotely logged onto my F15 system at work and found
/usr/lib/tmpfiles.d/systemd.conf
which contains this line:
d /tmp 1777 root root 10d
Knowing NOTHING about "systemd" or this file format (yet), I'm taking the wild guess that the initial "d" stands for "delete".
man tmpfiles.d
poc
On Thu, 2012-05-03 at 12:01 -0700, Dean S. Messing wrote:
I just remotely logged onto my F15 system at work and found
/usr/lib/tmpfiles.d/systemd.conf
which contains this line:
d /tmp 1777 root root 10d
Thanks for this. I admit I wasn't aware of this mechanism so have learned something :-)
Interestingly though, the man page says that files and directories will be removed. That doesn't seem to happen. I have directories in /tmp (on F15) which are well over 10 days old. They have no files in them, some have subdirectories, but no files at all. So it seems to more purge /tmp of files, but leave the directory structures in place.
John.
On Fri, 2012-05-04 at 12:13 +0100, John Horne wrote:
On Thu, 2012-05-03 at 12:01 -0700, Dean S. Messing wrote:
I just remotely logged onto my F15 system at work and found
/usr/lib/tmpfiles.d/systemd.conf
which contains this line:
d /tmp 1777 root root 10d
Thanks for this. I admit I wasn't aware of this mechanism so have learned something :-)
Interestingly though, the man page says that files and directories will be removed. That doesn't seem to happen. I have directories in /tmp (on F15) which are well over 10 days old. They have no files in them, some have subdirectories, but no files at all. So it seems to more purge /tmp of files, but leave the directory structures in place.
Are you actually running systemd (specifically systemd-tmpfiles)? IIRC it only became the default in F16.
poc
On 04/05/12 13:18, Patrick O'Callaghan wrote:
Are you actually running systemd (specifically systemd-tmpfiles)? IIRC it only became the default in F16.
poc
They are in F15, and seemingly 2 out of 3 currently active
systemd-tmpfiles-clean.service inactive dead systemd-tmpfiles-clean.timer active waiting systemd-tmpfiles-setup.service active exited