Re: Latest Jessie doesn't respond to /etc/default/tmpfs RAMTMP=yes
On Jul 28, 2014, at 4:59 PM, Rick Thomas rbtho...@pobox.com wrote: On Jul 28, 2014, at 3:16 PM, Michael Biebl bi...@debian.org wrote: In this particular case that would mean creating a directory /etc/systemd/system/tmp.mount.d/, then placing a .conf file in there setting your custom options. That all said, using /etc/fstab is perfectly fine if you need to tweak the /tmp tmpfs settings. An entry from /etc/fstab will override any existing tmp.mount unit. so I would: mkdir /etc/systemd/system/tmp.mount.d/ echo “[Mount]” /etc/systemd/system/tmp.mount.d/tmp.mount.conf echo “Options=mode=1777,strictatime,size=20%” /etc/systemd/system/tmp.mount.d/tmp.mount.conf then reboot. Right? I tried this and it seems to work… Rick On the other hand, I can accomplish the same thing in a more obvious way with a line in /etc/fstab listing the same options. The thing I miss most from the old /etc/default/tmpfs is the possibility to set the size of /tmp on tmpfs based on a percentage of the total available virtual memory (real RAM plus swap). Of course, it’s a one-time calculation that I can do myself when I’m customizing after installing, but it is nice to have the option of having the calculation made for me. Also, if I’m installing a lot of similar systems (with e.g. different amounts of RAM) it’s nice to have something that can be pre-seeded and doesn’t need to be tailored differently for each system. Just thinking… Enjoy! Rick -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0feb975d-4754-4c14-8fc3-151f0bdc9...@pobox.com
Re: Latest Jessie doesn't respond to /etc/default/tmpfs RAMTMP=yes
On Lu, 28 iul 14, 16:34:14, Rick Thomas wrote: mode=1777 sets all accesses allowed (it is “/tmp” after all…) and also sets the “sticky bit” which (according to stat(2)) “on a directory means that a file in that directory can be renamed or deleted only by the owner of the file, by the owner of the directory, and by a privileged process.” Right, makes sense for /tmp and I kind of ignored that anyway. What I meant (and failed to explain)... “strictatime” (according to mount(8)) Allows to explicitly requesting full atime updates. This makes it possible for kernel to defaults to reltime or native but still allow userspace to override it.” So in an embedded system with root on flash, but /tmp in RAM, we get standard semantics for atime (no need to be nice to flash since the whole filesystem is in RAM) and the usual expected behavior for deletion/rename operations in /tmp. ... was the reason for strictatime (vs. relatime which is default, or the more aggressive noatime). Sure, it's a tmpfs, and the penalty for updating atime is probably much lower than any other conventional storage (though /tmp contents might end up being swapped), but is there any software that actually relies on atime for files in /tmp? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: [OT] Latest Jessie doesn't respond to /etc/default/tmpfs RAMTMP=yes
On Jul 29, 2014, at 2:05 AM, Andrei POPESCU wrote: Sure, it's a tmpfs, and the penalty for updating atime is probably much lower than any other conventional storage (though /tmp contents might end up being swapped), but is there any software that actually relies on atime for files in /tmp? I didn't know that the default had been changed to relatime. I can see the logic, of course. There certainly is no harm in specifying strictatime (and it's cheap) for tmpfs. You're right that tmpfs may get swapped, but I think the metadata would be the last thing to be forced out to swap, since it's very frequently updated. Enjoy! Rick PS: This is an interesting discussion, but it has wandered a bit OT. So I added [OT] to the subject. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/fea45d86-a287-4a07-b39e-3c58218d5...@pobox.com
Re: Latest Jessie doesn't respond to /etc/default/tmpfs RAMTMP=yes
On Du, 27 iul 14, 17:31:37, Rick Thomas wrote: I still can’t figure out how to exercise control over the size and other mount options, the way I used to be able to do under sysvinit using options in /etc/default/tmpfs . Create /etc/systemd/system/tmp.mount with something like: .include /lib/systemd/system/tmp.mount [Mount] Options=... (your options) It's not entirely clear from the documentation if your options replace or just add to the ones in the included unit, but I'd be interested to know as well. All of the above is a) untested b) based on information found in systemd.unit(5) and systemd.mount(5). For the options relevant for tmpfs you'll have to check mount(8). As a side note, I'd also be interested in the reasons for the default options set by the systemd tmp.mount unit (mode=1777,strictatime), a superficial web search did not find anything. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Latest Jessie doesn't respond to /etc/default/tmpfs RAMTMP=yes
Am 28.07.2014 22:00, schrieb Andrei POPESCU: On Du, 27 iul 14, 17:31:37, Rick Thomas wrote: I still can’t figure out how to exercise control over the size and other mount options, the way I used to be able to do under sysvinit using options in /etc/default/tmpfs . Create /etc/systemd/system/tmp.mount with something like: .include /lib/systemd/system/tmp.mount [Mount] Options=... (your options) Just a quick comment: .include is discouraged nowadays. The recommended way is to use drop-in snippets. So, please don't use .include anymore! As for drop-ins, see [1] * Configuration of unit files may now be extended via drop-in files without having to edit/override the unit files themselves. More specifically, if the administrator wants to change one value for a service file foobar.service he can now do so by dropping in a configuration snippet into /etc/systemd/systemd/foobar.service.d/*.conf. The unit logic will load all these snippets and apply them on top of the main unit configuration file, possibly extending or overriding its settings. Using these drop-in snippets is generally nicer than the two earlier options for changing unit files locally: copying the files from /usr/lib/systemd/system/ to /etc/systemd/system/ and editing them there; or creating a new file in /etc/systemd/system/ that incorporates the original one via .include. Drop-in snippets into these .d/ directories can be placed in any directory systemd looks for units in, and the usual overriding semantics between /usr/lib, /etc and /run apply for them too. In this particular case that would mean creating a directory /etc/systemd/system/tmp.mount.d/, then placing a .conf file in there setting your custom options. That all said, using /etc/fstab is perfectly fine if you need to tweak the /tmp tmpfs settings. An entry from /etc/fstab will override any existing tmp.mount unit. [1] http://lists.freedesktop.org/archives/systemd-devel/2013-March/009496.html -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Latest Jessie doesn't respond to /etc/default/tmpfs RAMTMP=yes
On Jul 28, 2014, at 1:00 PM, Andrei POPESCU andreimpope...@gmail.com wrote: As a side note, I'd also be interested in the reasons for the default options set by the systemd tmp.mount unit (mode=1777,strictatime), a superficial web search did not find anything. Just a guess… mode=1777 sets all accesses allowed (it is “/tmp” after all…) and also sets the “sticky bit” which (according to stat(2)) “on a directory means that a file in that directory can be renamed or deleted only by the owner of the file, by the owner of the directory, and by a privileged process.” “strictatime” (according to mount(8)) Allows to explicitly requesting full atime updates. This makes it possible for kernel to defaults to reltime or native but still allow userspace to override it.” So in an embedded system with root on flash, but /tmp in RAM, we get standard semantics for atime (no need to be nice to flash since the whole filesystem is in RAM) and the usual expected behavior for deletion/rename operations in /tmp. It’s what I would have done, if I had thought about the issue. In general, I’m glad there are so many nice folks out there thinking about these issues, so I don’t have to! (-; Rick -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/0826730e-604c-45fe-bac5-aaa5d4aad...@pobox.com
Re: Latest Jessie doesn't respond to /etc/default/tmpfs RAMTMP=yes
On Jul 28, 2014, at 3:16 PM, Michael Biebl bi...@debian.org wrote: In this particular case that would mean creating a directory /etc/systemd/system/tmp.mount.d/, then placing a .conf file in there setting your custom options. That all said, using /etc/fstab is perfectly fine if you need to tweak the /tmp tmpfs settings. An entry from /etc/fstab will override any existing tmp.mount unit. so I would: mkdir /etc/systemd/system/tmp.mount.d/ echo “[Mount]” /etc/systemd/system/tmp.mount.d/tmp.mount.conf echo “Options=mode=1777,strictatime,size=20%” /etc/systemd/system/tmp.mount.d/tmp.mount.conf then reboot. Right? I tried this and it seems to work… Rick -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/9c781fba-35d9-404a-b822-59d89ca70...@pobox.com
Re: Latest Jessie doesn't respond to /etc/default/tmpfs RAMTMP=yes
Am 29.07.2014 01:59, schrieb Rick Thomas: so I would: mkdir /etc/systemd/system/tmp.mount.d/ echo “[Mount]” /etc/systemd/system/tmp.mount.d/tmp.mount.conf echo “Options=mode=1777,strictatime,size=20%” /etc/systemd/system/tmp.mount.d/tmp.mount.conf The file name is arbitrary, the only requirement is, that it has a .conf extension. You can also have more then one drop-in conf files. So naming it size.conf or local.conf would be more natural to me. But in the end, that's just cosmetics. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Latest Jessie doesn't respond to /etc/default/tmpfs RAMTMP=yes
On Jul 23, 2014, at 2:50 AM, Michael Biebl bi...@debian.org wrote: Hi Rick Am 23.07.2014 um 09:12 schrieb Rick Thomas: I’m trying to get /tmp on tmpfs, so I put “RAMTMP=yes” in /etc/default/tmpfs. But I don’t get /tmp/mounted on tmpfs. /etc/default/tmpfs is a sysvinit specific config file. If you are running systemd, enabling /tmp on tmpfs is as simple as “systemctl enable tmp.mount OK, this is my Jessie test VM, so I read-up on systemd and systemctl. Then I did systemctl enable tmp.mount and rebooted. As advertised, I had /tmp mounted on tmpfs. Cool! But… I still can’t figure out how to exercise control over the size and other mount options, the way I used to be able to do under sysvinit using options in /etc/default/tmpfs . Yes, I know I can do all that in /etc/fstab. But I’m testing here, so I’m trying to verify apparent functionality regressions, not look for workarounds. I’m happy to RTFM, but which FM tells me how to do this? Thanks! Rick PS: Yes, definitely, I’m planning to submit a documentation bugreport against initscripts as Michael suggested… but I want to explore the full ramifications of the change before I do — so I don’t ask for the impossible, or ask for something that’s already there that I just didn’t see. PPS: Don’t take this comment the wrong way — I’m all for change, especially if, as with systemd, it improves flexibility, manageability, auditability, speed and security for my systems — but I’m thinking that there will be a lot of folks who stick with Wheezy for a long time because the systemd change is too big for them to swallow. Wheezy may wind up being the “XP” of Debian releases. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/eb417f38-23c6-4bfa-aa38-511219ef3...@pobox.com
Re: Latest Jessie doesn't respond to /etc/default/tmpfs RAMTMP=yes
On Jul 24, 2014, at 10:49 AM, Andrei POPESCU andreimpope...@gmail.com wrote: On Mi, 23 iul 14, 00:12:25, Rick Thomas wrote: I’m trying to get /tmp on tmpfs, so I put “RAMTMP=yes” in /dev/default/tmpfs . But I don’t get /tmp/mounted on tmpfs. What's wrong with fstab? Kind regards, Andrei Nothing wrong with fstab, of course. I was, as all good debianistas should when they have a bit of spare time, testing the latest release — and reporting that the documented way using /dev/default/tmpfs wasn’t working. It seems that this is just another example of the documentation for systemd not having caught up with the the reality of the implementation. I guess I’ll file a bugreport requesting that the docs be updated… Rick -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8ba45276-cc61-41a9-b89a-033982949...@pobox.com
Re: Latest Jessie doesn't respond to /etc/default/tmpfs RAMTMP=yes
Am 25.07.2014 22:19, schrieb Rick Thomas: On Jul 24, 2014, at 10:49 AM, Andrei POPESCU andreimpope...@gmail.com wrote: On Mi, 23 iul 14, 00:12:25, Rick Thomas wrote: I’m trying to get /tmp on tmpfs, so I put “RAMTMP=yes” in /dev/default/tmpfs . But I don’t get /tmp/mounted on tmpfs. What's wrong with fstab? Kind regards, Andrei Nothing wrong with fstab, of course. I was, as all good debianistas should when they have a bit of spare time, testing the latest release — and reporting that the documented way using /dev/default/tmpfs wasn’t working. It seems that this is just another example of the documentation for systemd not having caught up with the the reality of the implementation. I guess I’ll file a bugreport requesting that the docs be updated… It would probably make sense to file a bug report against the initscripts package (which provides /etc/default/tmpfs) and clarify that this file is sysvinit specific. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Latest Jessie doesn't respond to /etc/default/tmpfs RAMTMP=yes
On Mi, 23 iul 14, 00:12:25, Rick Thomas wrote: I’m trying to get /tmp on tmpfs, so I put “RAMTMP=yes” in /dev/default/tmpfs . But I don’t get /tmp/mounted on tmpfs. What's wrong with fstab? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Latest Jessie doesn't respond to /etc/default/tmpfs RAMTMP=yes
I’m trying to get /tmp on tmpfs, so I put “RAMTMP=yes” in /dev/default/tmpfs . But I don’t get /tmp/mounted on tmpfs. I’ve got plenty of ram and swap: rbthomas@jessie:~$ cat /proc/meminfo | egrep '^(Mem|Swap)Total:' MemTotal:1017648 kB SwapTotal: 2928636 kB Here’s my /etc/default/tmpfs file: # Configuration for tmpfs filesystems mounted in early boot, before # filesystems from /etc/fstab are mounted. For information about # these variables see the tmpfs(5) manual page. # /run is always mounted as a tmpfs on systems which support tmpfs # mounts. # mount /run/lock as a tmpfs (separately from /run). Defaults to yes; # set to no to disable (/run/lock will then be part of the /run tmpfs, # if available). #RAMLOCK=yes # mount /run/shm as a tmpfs (separately from /run). Defaults to yes; # set to no to disable (/run/shm will then be part of the /run tmpfs, # if available). #RAMSHM=yes # mount /tmp as a tmpfs. Defaults to no; set to yes to enable (/tmp # will be part of the root filesystem if disabled). /tmp may also be # configured to be a separate mount in /etc/fstab. RAMTMP=yes # Size limits. Please see tmpfs(5) for details on how to configure # tmpfs size limits. TMPFS_SIZE=50%VM #RUN_SIZE=10% #LOCK_SIZE=5242880 # 5MiB #SHM_SIZE= TMP_SIZE=20%VM # Mount tmpfs on /tmp if there is less than the limit size (in kiB) on # the root filesystem (overriding RAMTMP). #TMP_OVERFLOW_LIMIT=1024 The same config works on Wheezy… Rick -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/9e4f302e-61a1-41ad-b7f3-8a9ec2d17...@pobox.com
Re: Latest Jessie doesn't respond to /etc/default/tmpfs RAMTMP=yes
Hi Rick Am 23.07.2014 um 09:12 schrieb Rick Thomas: I’m trying to get /tmp on tmpfs, so I put “RAMTMP=yes” in /dev/default/tmpfs . But I don’t get /tmp/mounted on tmpfs. /etc/default/tmpfs is a sysvinit specific config file. If you are running systemd, enabling /tmp on tmpfs is as simple as systemctl enable tmp.mount Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Latest Jessie doesn't respond to /etc/default/tmpfs RAMTMP=yes
Hello, First, Michael thank for your Debian work, On Wed, Jul 23, 2014 at 11:50 AM, Michael Biebl bi...@debian.org wrote: Hi Rick Am 23.07.2014 um 09:12 schrieb Rick Thomas: I’m trying to get /tmp on tmpfs, so I put “RAMTMP=yes” in /dev/default/tmpfs . But I don’t get /tmp/mounted on tmpfs. /etc/default/tmpfs is a sysvinit specific config file. If you are running systemd, enabling /tmp on tmpfs is as simple as systemctl enable tmp.mount Is it possible to add this comment to tmpfs manpage (initscripts package), or maybe to have a alternative configure option (tmpfs.sysvinit and tmpfs.systemd), so you can read the correct man page about tmpfs in the system where you are running ? I'm not sure which of both options is better Thank you ! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAL5yMZRiVq1=7k7jzhqhcz6hp_nnqtrgrap6lvmkd_eaowz...@mail.gmail.com
