You are not logged in.
Hi!
So, without notice the flawless logic that cleared /tmp/ during boot-up has been altered/removed. If I got that correctly instead we should use tmpfiles.d now.
So, here's my copied-and-modified /etc/tmpfiles.d/tmp.conf:
d /tmp 1777 root root 1d
d /var/tmp 1777 root root 3d
Result:
$ rc.d restart nginx
:: Checking nginx configuration [BUSY] nginx: [emerg] mkdir() "/var/tmp/nginx/client-body" failed (2: No such file or directory)
nginx: configuration file /etc/nginx/nginx.conf test failed
I would have been surprised if this time some "delete old/unused files" logic would have work and since /tmp symlinks to /var/tmp/ I don't have a clue why this didn't happen before (directory was created during boot and tmpfiles.d runs periodically, maybe?) but why the fuck do you guys trifle with fundamentals like that?!
Offline
/tmp is supposed to symlink to /var/tmp? Ooops…
EDIT:
I am completely confused now. /tmp has been a tmpfs per default for quite some time now. There is an entry in the /etc/fstab and I am certain I did not put it there manually.
Last edited by Awebb (2012-07-26 16:14:21)
Offline
(/tmp is actually --bind)
Yeah, me, too.
I also read posts that it was recommended to be mounted as tmpfs. Then somebody complained that he's actually putting data in there (hey, why's that?!). I read even recommendations to increate swap for that case.... In the end tmpfs was dropped and tmpfiles.d was suggested. That's at least what I tediously reconstructed so far. Well, and then again:
"19. removes various leftover/temporary files, such as /tmp/*."
https://wiki.archlinux.org/index.php/Ar … rc.sysinit
Boy, first time I reminisce about gentoo...
Last edited by tcn (2012-07-26 16:54:45)
Offline
Isn't tmpfiles.d only for systemd?
-edit-
Okay, I've found out that rc.sysinit indirectly runs systemd-tmpfiles indeed.
Last edited by lucke (2012-07-26 18:26:32)
Offline
What do you mean by "/tmp is actually --bind"?
https://projects.archlinux.org/svntogit … filesystem
/tmp is a tmpfs, and has been for a very long time now. /var/tmp is a separate directory, and neither symlinks or binds to the other.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
So, here's my copied-and-modified /etc/tmpfiles.d/tmp.conf:
d /tmp 1777 root root 1d
d /var/tmp 1777 root root 3dResult:
$ rc.d restart nginx
:: Checking nginx configuration [BUSY] nginx: [emerg] mkdir() "/var/tmp/nginx/client-body" failed (2: No such file or directory)
nginx: configuration file /etc/nginx/nginx.conf test failed
So that fragment means any files older than 3 days in /var/tmp will be cleared on boot. So /var/tmp/nginx is probably cleared, which would explain the failure. If this is the case, that's a bug in nginx (probably in the rc script, or your config, I don't know the package, so wouldn't know).
Before we would not clear /var/tmp at all. If you want that behavior back then remove the /var/tmp line from the tmp.conf you pasted above.
since /tmp symlinks to /var/tmp/ I don't have a clue why this didn't happen before
Hm, this is non-standard. If you want help you should attach your fstab and "ls -la / /var | grep tmp".
but why the fuck do you guys trifle with fundamentals like that?!
There are reasons, but with language like that, why should I (or anyone else) explain them to you, let alone help you with your original problem?
Offline
Hi!
So, without notice the flawless logic that cleared /tmp/ during boot-up has been altered/removed. If I got that correctly instead we should use tmpfiles.d now.
It happened like 3 months ago...
So, here's my copied-and-modified /etc/tmpfiles.d/tmp.conf:
d /tmp 1777 root root 1d
d /var/tmp 1777 root root 3dResult:
$ rc.d restart nginx
:: Checking nginx configuration [BUSY] nginx: [emerg] mkdir() "/var/tmp/nginx/client-body" failed (2: No such file or directory)
nginx: configuration file /etc/nginx/nginx.conf test failedI would have been surprised if this time some "delete old/unused files" logic would have work and since /tmp symlinks to /var/tmp/ I don't have a clue why this didn't happen before (directory was created during boot and tmpfiles.d runs periodically, maybe?) but why the fuck do you guys trifle with fundamentals like that?!
/tmp has never been a symbolic link to /var/tmp -- you made it. Similarly, we have never used --bind for both dirs. I don't know why nginx fails (its rc script does not attempt to write to /var/tmp or /tmp), but you should investigate this.
In any case, I don't understand why do you think your problem has anything to do with initscripts? With both old and new behavior, /tmp would have been empty after a successfull boot.
Arch Linux is more than just GNU/Linux -- it's an adventure
pkill -9 systemd
Offline
It happened like 3 months ago...
I usually reboot only for kernel update. Therefore 3 month if far from being "very long time"...
In any case, I don't understand why do you think your problem has anything to do with initscripts? With both old and new behavior, /tmp would have been empty after a successfull boot.
Whatever. It used to work (as described here: https://wiki.archlinux.org/index.php/Ar … c.sysinit)
Offline
There are reasons, but with language like that, why should I (or anyone else) explain them to you, let alone help you with your original problem?
You shouldn't. Thanks for not disturbing.
Offline