What is the process that deletes contents of /tmp? Is it the shutdown scripts or the scripts started by systemd?
On Feb 19, 2015 11:39 AM, "jd1008" jd1008@gmail.com wrote:
What is the process that deletes contents of /tmp? Is it the shutdown scripts or the scripts started by systemd? --
You mean when not using tmpfs for /tmp?
On Wed, Feb 18, 2015 at 8:38 PM, jd1008 jd1008@gmail.com wrote:
What is the process that deletes contents of /tmp? Is it the shutdown scripts or the scripts started by systemd?
Neither, it's a function of it being on tmpfs and being rebooted - it's not persistent. Whereas /var/tmp is managed by systemd-tmpfiles-clean.timer.
jd1008 jd1008@gmail.com wrote:
What is the process that deletes contents of /tmp? Is it the shutdown scripts or the scripts started by systemd?
Chris Murphy:
Neither, it's a function of it being on tmpfs and being rebooted - it's not persistent. Whereas /var/tmp is managed by systemd-tmpfiles-clean.timer.
And on those systems that are left running 24 hours a day?
Maybe it's installed the tmpwatch package...
https://fedorahosted.org/tmpwatch/
2015-02-19 15:16 GMT+01:00 Tim ignored_mailbox@yahoo.com.au:
jd1008 jd1008@gmail.com wrote:
What is the process that deletes contents of /tmp? Is it the shutdown scripts or the scripts started by systemd?
Chris Murphy:
Neither, it's a function of it being on tmpfs and being rebooted - it's not persistent. Whereas /var/tmp is managed by systemd-tmpfiles-clean.timer.
And on those systems that are left running 24 hours a day?
--
All mail to my mailbox is automatically deleted, there is no point trying to privately email me, I will only read messages posted to the public lists.
ZNQR LBH YBBX
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 02/19/2015 07:26 AM, Fran Tsao Santín wrote:
2015-02-19 15:16 GMT+01:00 Tim <ignored_mailbox@yahoo.com.au mailto:ignored_mailbox@yahoo.com.au>:
jd1008 <jd1008@gmail.com <mailto:jd1008@gmail.com>> wrote: >> What is the process that deletes contents of /tmp? >> Is it the shutdown scripts or the scripts started by systemd? Chris Murphy: > Neither, it's a function of it being on tmpfs and being rebooted - > it's not persistent. Whereas /var/tmp is managed by > systemd-tmpfiles-clean.timer. And on those systems that are left running 24 hours a day? -- All mail to my mailbox is automatically deleted, there is no point trying to privately email me, I will only read messages posted to the public lists. ZNQR LBH YBBXMaybe it's installed the tmpwatch package...
I do not have tmpwatch installed.
On Fri, Feb 20, 2015 at 12:46:31AM +1030, Tim wrote:
Neither, it's a function of it being on tmpfs and being rebooted - it's not persistent. Whereas /var/tmp is managed by systemd-tmpfiles-clean.timer.
And on those systems that are left running 24 hours a day?
Note that systemd-tmpfiles also cleans /tmp in its default configuration. See /usr/lib/tmpfiles.d/tmp.conf, which contains (with some other stuff):
d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d
On 02/19/2015 09:56 AM, Matthew Miller wrote:
On Fri, Feb 20, 2015 at 12:46:31AM +1030, Tim wrote:
Neither, it's a function of it being on tmpfs and being rebooted - it's not persistent. Whereas /var/tmp is managed by systemd-tmpfiles-clean.timer.
And on those systems that are left running 24 hours a day?
Note that systemd-tmpfiles also cleans /tmp in its default configuration. See /usr/lib/tmpfiles.d/tmp.conf, which contains (with some other stuff):
d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d
What about
/usr/bin/systemd-tmpfiles /usr/lib/tmpfiles.d /usr/lib/dracut/modules.d/98systemd/dracut-tmpfiles.conf /usr/lib/systemd/system/systemd-tmpfiles-clean.service /usr/lib/systemd/system/systemd-tmpfiles-clean.timer /usr/lib/systemd/system/systemd-tmpfiles-setup-dev.service /usr/lib/systemd/system/systemd-tmpfiles-setup.service /usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup-dev.service /usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup.service /usr/lib/systemd/system/timers.target.wants/systemd-tmpfiles-clean.timer
Which of these should be disabled in order to make my /tmp files to survive reboot?
On 02/19/2015 11:04 PM, jd1008 wrote:
On 02/19/2015 09:56 AM, Matthew Miller wrote:
On Fri, Feb 20, 2015 at 12:46:31AM +1030, Tim wrote:
Neither, it's a function of it being on tmpfs and being rebooted - it's not persistent. Whereas /var/tmp is managed by systemd-tmpfiles-clean.timer.
And on those systems that are left running 24 hours a day?
Note that systemd-tmpfiles also cleans /tmp in its default configuration. See /usr/lib/tmpfiles.d/tmp.conf, which contains (with some other stuff):
d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d
What about
/usr/bin/systemd-tmpfiles /usr/lib/tmpfiles.d /usr/lib/dracut/modules.d/98systemd/dracut-tmpfiles.conf /usr/lib/systemd/system/systemd-tmpfiles-clean.service /usr/lib/systemd/system/systemd-tmpfiles-clean.timer /usr/lib/systemd/system/systemd-tmpfiles-setup-dev.service /usr/lib/systemd/system/systemd-tmpfiles-setup.service /usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup-dev.service
/usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup.service /usr/lib/systemd/system/timers.target.wants/systemd-tmpfiles-clean.timer
Which of these should be disabled in order to make my /tmp files to survive reboot?
Generally it is the *.conf file which needs to be created/edited to change the default configuration settings for services. So it looks like /usr/lib/tmpfiles.d/tmp.conf is your friend for this objective.
'man systemd-tmpfiles' will help you with more information
On 02/19/2015 10:40 AM, Rejy M Cyriac wrote:
On 02/19/2015 11:04 PM, jd1008 wrote:
On 02/19/2015 09:56 AM, Matthew Miller wrote:
On Fri, Feb 20, 2015 at 12:46:31AM +1030, Tim wrote:
Neither, it's a function of it being on tmpfs and being rebooted - it's not persistent. Whereas /var/tmp is managed by systemd-tmpfiles-clean.timer.
And on those systems that are left running 24 hours a day?
Note that systemd-tmpfiles also cleans /tmp in its default configuration. See /usr/lib/tmpfiles.d/tmp.conf, which contains (with some other stuff):
d /tmp 1777 root root 10d d /var/tmp 1777 root root 30dWhat about
/usr/bin/systemd-tmpfiles /usr/lib/tmpfiles.d /usr/lib/dracut/modules.d/98systemd/dracut-tmpfiles.conf /usr/lib/systemd/system/systemd-tmpfiles-clean.service /usr/lib/systemd/system/systemd-tmpfiles-clean.timer /usr/lib/systemd/system/systemd-tmpfiles-setup-dev.service /usr/lib/systemd/system/systemd-tmpfiles-setup.service /usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup-dev.service
/usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup.service /usr/lib/systemd/system/timers.target.wants/systemd-tmpfiles-clean.timer
Which of these should be disabled in order to make my /tmp files to survive reboot?
Generally it is the *.conf file which needs to be created/edited to change the default configuration settings for services. So it looks like /usr/lib/tmpfiles.d/tmp.conf is your friend for this objective.
'man systemd-tmpfiles' will help you with more information
Thank you Matthew, Thank you Rejy for your help. All is well now. systemctl mask tmp.mount and vi /usr/lib/tmpfiles.d/tmp.conf where I commented out those 2 lines outlibed by Matthew did the trick.
Will this change survive the updates?
On Thu, Feb 19, 2015 at 11:06:31AM -0700, jd1008 wrote:
Thank you Matthew, Thank you Rejy for your help. All is well now. systemctl mask tmp.mount and vi /usr/lib/tmpfiles.d/tmp.conf where I commented out those 2 lines outlibed by Matthew did the trick. Will this change survive the updates?
The former will -- the "mask" change alters configuration.
The second will survive until systemd is updated, at which point it will be overwritten. Use /etc/tmpfiles.d instead for local configuration.
(This is a really nice thing about systemd — defaults and user/admin configuration are neatly separated in this way, so you can know that if there are files in /etc, you know that they're changes to the default.)
On 02/19/2015 10:40 AM, Rejy M Cyriac wrote:
On 02/19/2015 11:04 PM, jd1008 wrote:
On 02/19/2015 09:56 AM, Matthew Miller wrote:
On Fri, Feb 20, 2015 at 12:46:31AM +1030, Tim wrote:
Neither, it's a function of it being on tmpfs and being rebooted - it's not persistent. Whereas /var/tmp is managed by systemd-tmpfiles-clean.timer.
And on those systems that are left running 24 hours a day?
Note that systemd-tmpfiles also cleans /tmp in its default configuration. See /usr/lib/tmpfiles.d/tmp.conf, which contains (with some other stuff):
d /tmp 1777 root root 10d d /var/tmp 1777 root root 30dWhat about
/usr/bin/systemd-tmpfiles /usr/lib/tmpfiles.d /usr/lib/dracut/modules.d/98systemd/dracut-tmpfiles.conf /usr/lib/systemd/system/systemd-tmpfiles-clean.service /usr/lib/systemd/system/systemd-tmpfiles-clean.timer /usr/lib/systemd/system/systemd-tmpfiles-setup-dev.service /usr/lib/systemd/system/systemd-tmpfiles-setup.service /usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup-dev.service
/usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup.service /usr/lib/systemd/system/timers.target.wants/systemd-tmpfiles-clean.timer
Which of these should be disabled in order to make my /tmp files to survive reboot?
Generally it is the *.conf file which needs to be created/edited to change the default configuration settings for services. So it looks like /usr/lib/tmpfiles.d/tmp.conf is your friend for this objective.
'man systemd-tmpfiles' will help you with more information
Interesting obeservation, after I disabled the creation and mount a tmpfs on /tmp TODAY. $ cd /tmp $ ls -ltr total 1264K drwx------ 2 jd jd 4096 Dec 31 1969 orbit-jd/ -rw-------. 1 root root 0 Oct 8 13:15 yum.log -rwx------. 1 root root 663 Oct 8 13:47 ks-script-DhSaAL* drwxr-xr-x. 2 root root 4096 Oct 8 14:50 hsperfdata_root/ -rw-------. 1 root root 1255957 Oct 8 15:35 yum_save_tx.2014-10-08.15-35.pQVxxn.yumtx -rw-r--r-- 1 jd jd 0 Feb 19 11:00 qtsingleapp-smplay-ca73-3f0-lockfile drwx------ 3 root root 4096 Feb 19 12:45 systemd-private-186b844601e2408eaf31371607e83295-rtkit-daemon.service-jSJb1H/ drwx------ 3 root root 4096 Feb 19 12:45 systemd-private-186b844601e2408eaf31371607e83295-cups.service-fz1pho/ drwx------ 3 root root 4096 Feb 19 12:45 systemd-private-186b844601e2408eaf31371607e83295-ntpd.service-p2YLgg/ drwx------ 3 root root 4096 Feb 19 12:45 systemd-private-186b844601e2408eaf31371607e83295-colord.service-4x8X99/ drwx------ 2 jd jd 4096 Feb 19 12:46 ssh-esVxvDC58XKz/ prw------- 1 root root 0 Feb 19 12:46 hogsuspend| srwxr-xr-x 1 jd jd 0 Feb 19 12:46 qtsingleapp-smplay-ca73-3f0= drwx------ 2 jd jd 4096 Feb 19 12:46 kde-jdiXm3Tn/
So, how come files dated from Oct 8th of 2014 and last Dec are still in /tmp, when I only disabled tmpfs for /tmp today?
Allegedly, on or about 19 February 2015, jd1008 sent:
Interesting obeservation, after I disabled the creation and mount a tmpfs on /tmp TODAY. $ cd /tmp $ ls -ltr total 1264K drwx------ 2 jd jd 4096 Dec 31 1969 orbit-jd/ -rw-------. 1 root root 0 Oct 8 13:15 yum.log -rwx------. 1 root root 663 Oct 8 13:47 ks-script-DhSaAL* drwxr-xr-x. 2 root root 4096 Oct 8 14:50 hsperfdata_root/ -rw-------. 1 root root 1255957 Oct 8 15:35 yum_save_tx.2014-10-08.15-35.pQVxxn.yumtx -rw-r--r-- 1 jd jd 0 Feb 19 11:00 qtsingleapp-smplay-ca73-3f0-lockfile drwx------ 3 root root 4096 Feb 19 12:45 systemd-private-186b844601e2408eaf31371607e83295-rtkit-daemon.service-jSJb1H/ drwx------ 3 root root 4096 Feb 19 12:45 systemd-private-186b844601e2408eaf31371607e83295-cups.service-fz1pho/ drwx------ 3 root root 4096 Feb 19 12:45 systemd-private-186b844601e2408eaf31371607e83295-ntpd.service-p2YLgg/ drwx------ 3 root root 4096 Feb 19 12:45 systemd-private-186b844601e2408eaf31371607e83295-colord.service-4x8X99/ drwx------ 2 jd jd 4096 Feb 19 12:46 ssh-esVxvDC58XKz/ prw------- 1 root root 0 Feb 19 12:46 hogsuspend| srwxr-xr-x 1 jd jd 0 Feb 19 12:46 qtsingleapp-smplay-ca73-3f0= drwx------ 2 jd jd 4096 Feb 19 12:46 kde-jdiXm3Tn/
So, how come files dated from Oct 8th of 2014 and last Dec are still in /tmp,when I only disabled tmpfs for /tmp today?
The most obvious guess would be that /tmp was an ordinary directory, back them, and more recently tmpfs was mounted over the top of it.
Was your current OS already installed back then?
On 02/19/2015 11:16 PM, Tim wrote:
Allegedly, on or about 19 February 2015, jd1008 sent:
Interesting obeservation, after I disabled the creation and mount a tmpfs on /tmp TODAY. $ cd /tmp $ ls -ltr total 1264K drwx------ 2 jd jd 4096 Dec 31 1969 orbit-jd/ -rw-------. 1 root root 0 Oct 8 13:15 yum.log -rwx------. 1 root root 663 Oct 8 13:47 ks-script-DhSaAL* drwxr-xr-x. 2 root root 4096 Oct 8 14:50 hsperfdata_root/ -rw-------. 1 root root 1255957 Oct 8 15:35 yum_save_tx.2014-10-08.15-35.pQVxxn.yumtx -rw-r--r-- 1 jd jd 0 Feb 19 11:00 qtsingleapp-smplay-ca73-3f0-lockfile drwx------ 3 root root 4096 Feb 19 12:45 systemd-private-186b844601e2408eaf31371607e83295-rtkit-daemon.service-jSJb1H/ drwx------ 3 root root 4096 Feb 19 12:45 systemd-private-186b844601e2408eaf31371607e83295-cups.service-fz1pho/ drwx------ 3 root root 4096 Feb 19 12:45 systemd-private-186b844601e2408eaf31371607e83295-ntpd.service-p2YLgg/ drwx------ 3 root root 4096 Feb 19 12:45 systemd-private-186b844601e2408eaf31371607e83295-colord.service-4x8X99/ drwx------ 2 jd jd 4096 Feb 19 12:46 ssh-esVxvDC58XKz/ prw------- 1 root root 0 Feb 19 12:46 hogsuspend| srwxr-xr-x 1 jd jd 0 Feb 19 12:46 qtsingleapp-smplay-ca73-3f0= drwx------ 2 jd jd 4096 Feb 19 12:46 kde-jdiXm3Tn/
So, how come files dated from Oct 8th of 2014 and last Dec are still in /tmp,when I only disabled tmpfs for /tmp today?
The most obvious guess would be that /tmp was an ordinary directory, back them, and more recently tmpfs was mounted over the top of it.
Was your current OS already installed back then?
Good guess. I fedup'ed from fc20. But fc20 was also using tmpfs for /tmp Prior to fc20, I had fdup'ed from fc18. So indeed it is very likely that those are remnants from fc18.
On Thu, Feb 19, 2015 at 10:34:31AM -0700, jd1008 wrote:
d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d
What about
[...]
Which of these should be disabled in order to make my /tmp files to survive reboot?
None of them. Files in /etc/tmpfiles.d override /usr/lib/tmpfiles.d, so create /etc/tmpfiles.d/tmp.conf with the line
d /tmp 1777 root root -
(with - replacing 10d) and that _should_ do it (untested but I strongly believe the theory).
But personally, I think I'd consider stashing non-temporary files somewhere else, and just leaving /tmp as-is.
On 02/18/2015 10:19 PM, Ed Greshko wrote:
You mean when not using tmpfs for /tmp?
On 02/18/2015 11:15 PM, Chris Murphy wrote:
Neither, it's a function of it being on tmpfs and being rebooted - it's not persistent. Whereas /var/tmp is managed by systemd-tmpfiles-clean.timer.
OK, I should have seen that :) Just not looking.
So,my next question, can I create a disk based permanent /tmp and prevent the tmpfs from being created at every boot? Preventing the creation of tmpfs for /tmp. Where is that done so I can revert back to using HD for /tmp?
On 02/19/2015 05:40 PM, jd1008 wrote:
On 02/18/2015 10:19 PM, Ed Greshko wrote:
You mean when not using tmpfs for /tmp?
On 02/18/2015 11:15 PM, Chris Murphy wrote:
Neither, it's a function of it being on tmpfs and being rebooted - it's not persistent. Whereas /var/tmp is managed by systemd-tmpfiles-clean.timer.
OK, I should have seen that :) Just not looking.
So,my next question, can I create a disk based permanent /tmp and prevent the tmpfs from being created at every boot? Preventing the creation of tmpfs for /tmp. Where is that done so I can revert back to using HD for /tmp?
By editing /etc/fstab for example.
Kind regards
Joachim Backes
On Thu, Feb 19, 2015 at 09:40:47AM -0700, jd1008 wrote:
So,my next question, can I create a disk based permanent /tmp and prevent the tmpfs from being created at every boot? Preventing the creation of tmpfs for /tmp. Where is that done so I can revert back to using HD for /tmp?
Run
sudo systemctl mask tmp.mount
This will change the configuration so that that mount isn't autogenerated, and it will remain part of the root filesystem.
-
Chris Murphy -
Ed Greshko -
Fran Tsao Santín -
JD -
Joachim Backes -
Matthew Miller -
Rejy M Cyriac -
Tim