Re: Disable whatever is cleaning /tmp

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Presumably, removing all the files in those directories would do the same but it appears that it's still purging /tmp.  Does systemd-tmpfiles require a reload/restart before it picks up changes?  If so, that conveniently requires a reboot since it ignores manual anything.  I'd love to be able to completely kill it but my familiarity with systemd is very limited.  Anyone care to venture a guess about what would happen if I removed the executable bit from the binary?

For now I've symlinked all of the files in the tmpfiles.d directories to /dev/null.  Let's see what happens...


On Thu, Apr 17, 2014 at 4:00 PM, poma <pomidorabelisima@xxxxxxxxx> wrote:
On 17.04.2014 23:19, Tucker wrote:
> Hello,
>
> Since installing FC20, I've been struggling to deal with the fact that
> something is eating files in /tmp before I'm done with them.  (I'm not
> talking about reboots.)  If I create a file in /tmp, within N minutes, it
> is deleted.  This is problematic since I have quite a few tools/tasks that
> require creating transient files in /tmp that need to exist for the
> duration of the process that creates them.  I removed tmpwatch, assuming
> that was the problem but that did nothing.
>
> After some research I've found tmpfiles.d, which can't be removed because
> it is wrapped in the systemd package.  I attempted to disable cleaning of
> /tmp and /var/tmp by making the following change to
> /usr/lib/tmpfiles.d/tmp.conf but no dice:
>
> -----------------------
> #  This file is part of systemd.
> #
> #  systemd is free software; you can redistribute it and/or modify it
> #  under the terms of the GNU Lesser General Public License as published by
> #  the Free Software Foundation; either version 2.1 of the License, or
> #  (at your option) any later version.
>
> # See tmpfiles.d(5) for details
>
> # Clear tmp directories separately, to make them easier to override
> #d /tmp 1777 root root 10d
> #d /var/tmp 1777 root root 30d
>
> # Exclude namespace mountpoints created with PrivateTmp=yes
> x /tmp
> x /var/tmp
> X /tmp
> X /var/tmp
> x /tmp/*
> x /var/tmp/*
> X /tmp/*
> X /var/tmp/*
> #x /tmp/systemd-*.service-*
> #x /var/tmp/systemd-*.service-*
> #X /tmp/systemd-*.service-*/tmp
> #X /var/tmp/systemd-*.service-*/tmp
> #x /tmp/systemd-*.socket-*
> #x /var/tmp/systemd-*.socket-*
> #X /tmp/systemd-*.socket-*/tmp
> #X /var/tmp/systemd-*.socket-*/tmp
> #x /tmp/systemd-*.mount-*
> #x /var/tmp/systemd-*.mount-*
> #X /tmp/systemd-*.mount-*/tmp
> #X /var/tmp/systemd-*.mount-*/tmp
> #x /tmp/systemd-*.swap-*
> #x /var/tmp/systemd-*.swap-*
> #X /tmp/systemd-*.swap-*/tmp
> #X /var/tmp/systemd-*.swap-*/tmp
> ## keep those for compatibility during upgrades
> #x /tmp/systemd-private-*
> #x /var/tmp/systemd-private-*
> #X /tmp/systemd-private-*/tmp
> #X /var/tmp/systemd-private-*/tmp
> -----------------------
>
> Can someone point me to the correct way to fix this problem?
>
>
>

man 5 tmpfiles.d
...
Files in /etc/tmpfiles.d override files with the same name in
/usr/lib/tmpfiles.d and /run/tmpfiles.d.
Files in /run/tmpfiles.d override files with the same name in
/usr/lib/tmpfiles.d.
Packages should install their configuration files in
/usr/lib/tmpfiles.d.
Files in /etc/tmpfiles.d are reserved for the local administrator,
who may use this logic to override the configuration files
installed by vendor packages.
All configuration files are sorted by their filename in lexicographic
order, regardless of which of the directories they reside in.
If multiple files specify the same path, the entry in the file with the
lexicographically earliest name will be applied, all all other
conflicting entries logged as errors.

If the administrator wants to disable a configuration file
supplied by the vendor, the recommended way is
to place a symlink to /dev/null in /etc/tmpfiles.d/
bearing the same filename.


# ln -s /dev/null /etc/tmpfiles.d/tmp.conf
# file /etc/tmpfiles.d/tmp.conf
/etc/tmpfiles.d/tmp.conf: symbolic link to `/dev/null'

Working?


poma


--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
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



--

--tucker
-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
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
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux