[arch-general] pacman/libalpm/libfetch do not honor TMPDIR

"Jérôme M. Berger" jeberger at free.fr
Wed Nov 30 13:49:08 EST 2011


Leonid Isaev wrote:
> On Tue, 29 Nov 2011 19:50:46 +0100
> "Jérôme M. Berger" <jeberger at free.fr> wrote:
>> 	And if your machine only boots very rarely (because it runs
>> continuously or because you hibernate it instead of rebooting) then
>> your "temporary" folder is never cleaned up. The solution that makes
>> the most sense is to have /tmp on a disk and to use tmpwatch [1][2]
>> in a cron job to clean it up regularly.
>>
>> 		Jerome
>>
>> [1] http://fedorahosted.org/tmpwatch/
>> [2] http://aur.archlinux.org/packages.php?ID=23510
> 
> I am not sure what you mean, but we have uptimes averaging 170 days on the
> cluster (arch/rhel/ubuntu) and never had a single problem with overfull
> ext2 /tmp (FS size ~10Gb).
> 
	You can afford to waste *10Gb of RAM* with files that are not
accessed for over 5 months? Man, you're rich :)

> Again, you are thinking pure desktop (even not workstation) -- the most
> important file in your /tmp is a youtube video. What about various backup
> solutions which run continuously over the above 5 month period? Or various
> user data which they put in /tmp? Or data from compilation? Or situations when
> RAM is a resource?
> 
	No, actually I'm thinking mostly server (with an average uptime of
6 months). The long uptime means that cleaning /tmp on boot makes no
sense since "booting" happens so rarely. Therefore some other means
of cleaning it is required and cron+tmpwatch is the best way to do
it (you could of course roll your own script to replace tmpwatch,
but why go to the trouble when someone else has already done it and
tested it in all the stupid corner cases with race conditions,
symlinks and so on).

	Another issue with force cleaning /tmp on boot is that those
twice-a-year reboots are often due to external problems (power
outage for example). In that case, it is often useful to still have
access to the files you were using 5 min before the reboot even if
those files will stop being useful in a day or two and can then
safely be removed.

> Hibernating is a purely windows concept, doing it on a linux machine is
> basically looking for trouble, especially because hibernation gives no benefits
> over shutting down.

	I never reboot my laptop unless I just upgraded the kernel and I
don't have any issues. Hibernation has two benefits over shutting down:
- Waking up is faster (ok, that's a small benefit because booting
Arch is very fast, but still...)
- When waking up from hibernation, you get your desktop exactly the
way you left it, including any open files and tasks in progress.
This is especially useful when using a laptop on the move: start
working on something in the train, hibernate when you arrive at your
station, then wake up when you reach your desk and immediately pick
up where you left off).

	This has nothing to do with windows (although I admit that
hibernating is a purely laptop concept: I don't hibernate my desktop
PC and even less my servers).

> And IMHO putting a simple hook into /etc/pm is much more
> rational than having yet another daemon.
>
	What other daemon? Cron is already running anyway, so all that is
needed is a simple hook in /etc/cron.daily.

		Jerome
-- 
mailto:jeberger at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20111130/134ffbbe/attachment.asc>


More information about the arch-general mailing list