New Feature: /tmp and /var RAM disks on Full installs; /tmp and /var resizing

[jimp]

New snapshots are up and it should be working OK for full installs.

I just found and fixed a bug that prevented the sizing from working on NanoBSD, so that will be OK on the next snapshot.
https://github.com/pfsense/pfsense/commit/efc0e29abc068b41f52a2d5d6ac89cb6c4791662

[MaxPF]

Would it make sense to use to use this feature on a Alix box with 256MB of ram?

[mdima]

Nice! Does the content of the ramdisk gets committed to the hard disk during a regular reboot/update?

Thanks,
    Michele

[jimp]

@MaxPF:

Would it make sense to use to use this feature on a Alix box with 256MB of ram?

Only if you need to slightly tweak the /tmp and /var slice sizes. There isn't much wiggle room on ALIX for that.

@mdima:

Nice! Does the content of the ramdisk gets committed to the hard disk during a regular reboot/update?

It works identically to NanoBSD. The RRD data and DHCP lease data are backed up on shutdown/reboot and restored at bootup. The options for periodic backup of those items also works on here. Also like NanoBSD, the pbi/pkg info is held in /root rather than /var/db/pkg

[phil.davis]

On Alix, on the console during boot, I get:

Mounting filesystems...
[: -gt: unexpected operator
[: -gt: unexpected operator
Setting up memory disks... done.[/code]
I think that spits out of rc.embedded when use_mfs_tmp_size and use_mfs_var_size have not been set in the config.
It still falls through the tests somehow and ends up with the default 40MB and 60MB memory disks.

[jimp]

@phil.davis:

On Alix, on the console during boot, I get:

Mounting filesystems...
[: -gt: unexpected operator
[: -gt: unexpected operator
Setting up memory disks... done.[/code]
I think that spits out of rc.embedded when use_mfs_tmp_size and use_mfs_var_size have not been set in the config.
It still falls through the tests somehow and ends up with the default 40MB and 60MB memory disks.

I think that's the bug I fixed with the commit I linked, make sure you've got that one (or try another snap after)

The problem was the config slice wasn't mounted when it tried to read the config, so the file wasn't there. The command should always get a number back from grep -c so long as the file exists, but I could add some extra protections just in case.

[phil.davis]

It needs a bit fancier checking for null values in rc.embedded - I just submitted a pull request. You might have a neater way of making it do the "-gt 0" check against a possibly empty variable.

[jimp]

Nah your check is fine, I merged it. Thanks!

[athurdent]

Great feature, thanks! Works fine so far.

[asterix]

Installed the latest snapshot, turned on this feature. Left blank for default space. Installed Squid3 and after reboot it gives me the below error on the login page and I am locked out as I cannot log into the system. The pfSense is a remote box and I don't have physical access to it. Darn !

Warning: session_start(): open(/var/tmp//sess_a5f98c219d39beb8a18480d9a81a2024, O_RDWR) failed: No space left on device (28) in /etc/inc/auth.inc on line 1316

[jimp]

Well what did you expect when you gave it a pittance for space in /tmp and /var and tried to install a package that used it all up?

Unfortunately there is no way to prevent foot-shooting there, but I suppose I could add even more stern warnings to the page.

[asterix]

I realized about the setting just the second after I clicked reboot. Any backdoor method to gain access to the system?

[jimp]

Hard to say for sure, if you can get it to the console menu at all you might be able to go back to an older version of the config, assuming any are there. It very well could have wiped out quite a bit if /tmp and/or /var filled up.

If you can get to a prompt, check /conf/backup/ and see if there are any old configs there, if there are, then copy one to /conf/config.xml, rm /tmp/config.cache, and reboot

[asterix]

Can't do much remotely. Only access I had to it was over WAN https.

[w0w]

Updated to the latest snapshot via automatic update. No option in System-Advanced-Mics.
What am I doing wrong?

[Oliver_]

is it possible to create a option for a third RamDisk?
So we can choose Squid/HAVP/etc for using this space for caching!
so the normal usage of  /tmp and /var is not affected?!

[phil.davis]

@w0w:

Updated to the latest snapshot via automatic update. No option in System-Advanced-Mics.
What am I doing wrong?

Which option is not there?
On nanobsd, the checkbox "Use memory file system for /tmp and /var" does not appear, because it is not optional - it always "Uses memory file system for /tmp and /var".

[jimp]

@Oliver_:

is it possible to create a option for a third RamDisk?
So we can choose Squid/HAVP/etc for using this space for caching!
so the normal usage of  /tmp and /var is not affected?!

No, there is no option for that, and probably won't be. Not something common enough to warrant doing. Just config squid to use more memory cache and not a disk cache in a RAM disk. That's a discussion for a different thread though.

[w0w]

@phil.davis:

@w0w:

Updated to the latest snapshot via automatic update. No option in System-Advanced-Mics.
What am I doing wrong?

Which option is not there?
On nanobsd, the checkbox "Use memory file system for /tmp and /var" does not appear, because it is not optional - it always "Uses memory file system for /tmp and /var".

I have full install done on ssd disk about a half of year ago
Now it shows
2.1-BETA1 (i386)
built on Wed Apr 3 04:19:20 EDT 2013
FreeBSD 8.3-RELEASE-p7

This what I have in System: Advanced: Miscellaneous  (see attached image)

[jimp]

You must have some other issue preventing that page from getting updated, but it's not relevant to this thread. Start a fresh thread and someone can help you investigate why a firmware update isn't updating that file.