#tmpfs — Public Fediverse posts

damn is this tmpfs thing on #macOS stupid.

turns out:
> sudo mount -t tmpfs -- -i ~/tmp

as well as
> sudo mount -t tmpfs -- -- ~/tmp

WORK. They currently pass the arguments along as is to the mount_tmpfs command and that one doesn't like the string "tmpfs" as its first argument.

And apple for whatever reason assumed that this would work (maybe it did in the past, don't know):
> sudo mount -t tmpfs ~/tmp

but it doesn't as mount doesn't allow that syntax.

#tmpfs #mount

damn is this tmpfs thing on #macOS stupid.

turns out:
> sudo mount -t tmpfs -- -i ~/tmp

as well as
> sudo mount -t tmpfs -- -- ~/tmp

WORK. They currently pass the arguments along as is to the mount_tmpfs command and that one doesn't like the string "tmpfs" as its first argument.

And apple for whatever reason assumed that this would work (maybe it did in the past, don't know):
> sudo mount -t tmpfs ~/tmp

but it doesn't as mount doesn't allow that syntax.

#tmpfs #mount

damn is this tmpfs thing on #macOS stupid.

turns out:
> sudo mount -t tmpfs -- -i ~/tmp

as well as
> sudo mount -t tmpfs -- -- ~/tmp

WORK. They currently pass the arguments along as is to the mount_tmpfs command and that one doesn't like the string "tmpfs" as its first argument.

And apple for whatever reason assumed that this would work (maybe it did in the past, don't know):
> sudo mount -t tmpfs ~/tmp

but it doesn't as mount doesn't allow that syntax.

#tmpfs #mount

damn is this tmpfs thing on #macOS stupid.

turns out:
> sudo mount -t tmpfs -- -i ~/tmp

as well as
> sudo mount -t tmpfs -- -- ~/tmp

WORK. They currently pass the arguments along as is to the mount_tmpfs command and that one doesn't like the string "tmpfs" as its first argument.

And apple for whatever reason assumed that this would work (maybe it did in the past, don't know):
> sudo mount -t tmpfs ~/tmp

but it doesn't as mount doesn't allow that syntax.

#tmpfs #mount

Finally read the reply #Apple sent me to my report of #tmpfs mounts being broken there.

Well appears they're a bit confused about the mount syntax themselves but there is a working alternative:

> sudo mount_tmpfs ~/tmp

#podman #docker #container

Editando! Después de dos días grabando para el canal de Youtube de #juncotic, y para el curso de Hardening Linux, tocó el moment de editar.

Pronto nuevo video en el canal!

¿Que no se han suscrito todavía? 👇

https://youtube.com/juncotic

#juncotic #gnu #linux #video #clase #educacion #curso #youtube #tmpfs #hardening #optimization

Editando! Después de dos días grabando para el canal de Youtube de #juncotic, y para el curso de Hardening Linux, tocó el moment de editar.

Pronto nuevo video en el canal!

¿Que no se han suscrito todavía? 👇

https://youtube.com/juncotic

#juncotic #gnu #linux #video #clase #educacion #curso #youtube #tmpfs #hardening #optimization

Editando! Después de dos días grabando para el canal de Youtube de #juncotic, y para el curso de Hardening Linux, tocó el moment de editar.

Pronto nuevo video en el canal!

¿Que no se han suscrito todavía? 👇

https://youtube.com/juncotic

#juncotic #gnu #linux #video #clase #educacion #curso #youtube #tmpfs #hardening #optimization

Editando! Después de dos días grabando para el canal de Youtube de #juncotic, y para el curso de Hardening Linux, tocó el moment de editar.

Pronto nuevo video en el canal!

¿Que no se han suscrito todavía? 👇

https://youtube.com/juncotic

#juncotic #gnu #linux #video #clase #educacion #curso #youtube #tmpfs #hardening #optimization

Sigo jugando con la memoria en #linux 😃

En un sistema con 16GiB de RAM he configurado un mountpoint con #tmpfs para la cache de #firefox.

En otro sistema, con 8GiB de RAM, he configurado un mountpoint con #zram para la cache de #brave, porque la memoria es más escasa.

Por el momento ambos van súper fluidos!

Lo voy a testear, y luego sacaré mis conclusiones, y publicaré resultados en el blog de #juncotic y en el canal de youtube.

Por si quieren sumarse 👇

:youtube: https://www.youtube.com/juncotic

Spotify taking too much disk space? Here's how to fix Spotify cache bloat using tmpfs (RAM) on Debian and Ubuntu Linux.

Step-by-Step Guide: https://ostechnix.com/move-spotify-cache-tmpfs-debian-ubuntu/

#Spotify #tmpfs #RAM #CacheDirectory #Debian #Ubuntu #Linux

Spotify taking too much disk space? Here's how to fix Spotify cache bloat using tmpfs (RAM) on Debian and Ubuntu Linux.

Step-by-Step Guide: https://ostechnix.com/move-spotify-cache-tmpfs-debian-ubuntu/

#Spotify #tmpfs #RAM #CacheDirectory #Debian #Ubuntu #Linux

Spotify taking too much disk space? Here's how to fix Spotify cache bloat using tmpfs (RAM) on Debian and Ubuntu Linux.

Step-by-Step Guide: https://ostechnix.com/move-spotify-cache-tmpfs-debian-ubuntu/

#Spotify #tmpfs #RAM #CacheDirectory #Debian #Ubuntu #Linux

Spotify taking too much disk space? Here's how to fix Spotify cache bloat using tmpfs (RAM) on Debian and Ubuntu Linux.

Step-by-Step Guide: https://ostechnix.com/move-spotify-cache-tmpfs-debian-ubuntu/

#Spotify #tmpfs #RAM #CacheDirectory #Debian #Ubuntu #Linux

Spotify taking too much disk space? Here's how to fix Spotify cache bloat using tmpfs (RAM) on Debian and Ubuntu Linux.

Step-by-Step Guide: https://ostechnix.com/move-spotify-cache-tmpfs-debian-ubuntu/

#Spotify #tmpfs #RAM #CacheDirectory #Debian #Ubuntu #Linux

Why #GIMP #AppImage #crashes on #Linux then trying to export / #save files to #tmpfs? A #bug ?

/tmp/.mount_GIMP-3ChpMMA/usr/lib/x86_64-linux-gnu/gimp/3.0/plug-ins/script-fu/script-fu: fatal error: GIMP crashed

(script-fu:34154): LibGimp-WARNING **: 13:15:26.695: script-fu: gimp_flush(): error: Broken pipe
fish: Job 1, 'GIMP-3.0.4-x86_64.AppImage --ve…' terminated by signal SIGSEGV (Address boundary error)

After some testing, and getting crazy about it, I debugged moar. It seems that the problem is a .json file in the tmpfs dir, it seems to crash GIMP. There’s clearly something very wrong.

Just for fun I created this file: gimp-denial-of-service-attack.json

Feel free to use that to troll colleagues. Place it is some directory they’re likely going to use with GIMP, just for lulz. - Don’t ask me, why it crashes GIMP. #json #gimp #crash

How to Stretch a 10GB VPS Disk: Compressed Folders, tmpfs, and Space-Saving Magic https://lowendbox.com/blog/how-to-stretch-a-10gb-vps-disk-compressed-folders-tmpfs-and-space-saving-magic/ #Editorial&News #btrfs #linux #tmpfs

A Deep Dive Into Debian 13’s /tmp: What’s New, And What To Do If You Don’t Like It https://lowendbox.com/blog/a-deep-dive-into-debian-13s-tmp-whats-new-and-what-to-do-if-you-dont-like-it/ #Tutorials #debian13 #debian #trixie #tmpfs

For those who need this:

#tmp on #tmpfs #ultras

LXC теряли память и падали. И при чем же здесь tmpfs и journald?

Старый добрый Proxmox с его контейнерами и виртуалками - по-прежнему рабочая лошадка многих компаний. И если нарезать много-много мелких контейнеров, то может случиться, что память куда-то девается со временем, а контейнеры падают в OOM без очевидной причины. Причем не все. Причем иногда. И зачастую проще перезапустить и ехать дальше чем разбираться. А причина есть, и она оказалось довольно проста.

https://habr.com/ru/articles/883562/

#proxmox #lxc #tmpfs #journald #oom #oom_killer #systemd

I haven't followed closely what happens under the development of SystemD, neither the news about it.
Today after doing my timely backup of my whole hard drive I have noticed a bunch of tmpfs created by SystemD. What's going on, does anyone have any info on why suddenly there's a bunch of tmpfs shown up under the "df" command?

#linux #systemd #tmpfs #linuxquestions

I haven't followed closely what happens under the development of SystemD, neither the news about it.
Today after doing my timely backup of my whole hard drive I have noticed a bunch of tmpfs created by SystemD. What's going on, does anyone have any info on why suddenly there's a bunch of tmpfs shown up under the "df" command?

#linux #systemd #tmpfs #linuxquestions

Have you ever received an HTTP 418 status code while browsing? If so, it may be because you were trying to put a square peg in a round hole, or vice versa.

Indeed, RFC 2324 Lays out the specification, and Oopsies! It turns out that an April Fools joke was canonized, albeit with some utility. Turns out, even if someone's not trying to pull your leg, by telling you "I'm a Teapot", it's likely you're gently being encouraged to look for a resource other than the way in which you're asking.

For example, you ask for a coffeemaker and receive the error, HTTP 418 (I'm a Teapot). It's certainly nicer that a 404 and yet indicates that there is content where the page you've just asked for exists.

This is in some ways a concern that many have dug their heels in over, clinging as intransigent as ever when it comes to #tmpfs discussions beginning twelve years ago on the #Debian Dev list.

Often, in practice, cron is used to clean out unneeded clutter in /tmp or /var/tmp, as well as other methods. An issue I have is with the systemd defaults including /var/tmp in tmpfs on some implementations because temporary files here are intended to be persistent across reboots.

By default, systemd cleans out files in /var/tmp by default after 30 days, and this can be problematic, while the default is 10 days for /tmp. /var/run and /var/lock are also Incorporated - But I digress.

After well over a decade, about half of the major Linux distros have migrated to tmpfs: Arch, Fedora, and some versions of SuSE number among the most familiar. Others have not: Redhat, SLES, and other "Enterprise" focused distros, along with Debian, ... Until just recently, when much to my surprise during routine updates I noticed the switch to tmpfs has now occurred.

w00t 🤘🤠🤘

With respect to Slackware, does it use the traditional disk based method or the RAM based tmpfs? The answer to that of course, is "Yes, of course, it absolutely does!"

"Which one did you say?" I actually didn't, lolz. As is usually the case with Slackware (and Arch and Gentoo), it's really however you want it!

In Slackware, the implementation is much more elegant however. You simply mount /tmp on a ramdisk (again, leave /var/tmp alone - these files are intended to be persistent across reboots, and for possibly much, much longer than a mere 30 days).

Okay so back to Debian. If you're one of those fraidy cats that doesn't believe, or rather, isn't competent or confident enough to run Enterprise production machines on rolling distros, I've got good news for you! You won't be needing to concern yourself with this until Debian 13 is officially released or you're forced to upgrade to it in the next few years. Lucky you!

For the rest of us however, already running #Trixie, it has indeed arrived. Welcome! Here's the problems...

You may, depending on what daemons you run in production, want to tweak your defaults. i.e., 10 days may be less than appropriate for your company's needs. Remember, #cron is your friend. It's also why Slackware's approach was referred to as elegant, because you have to take into account what it is you want or need before you implement it.

For example, since you already know that you don't want temp files to survive reboots in /tmp, there's really nothing faster than disk space residing in RAM anyway.

On the other hand, Poettering doesn't make up the rules for the developers of this world or sysadmins. If you're not careful you can wind up right back on a spinning disk platter again, since the default for #systemd is to allocate 50‰ of your RAM for tmpfs, if you don't have ample memory, you go to SWAP.

Oh, the irony :p

When you're in an HA environment where your UNIX boxes have uptimes exceeding 800+ days, and the only reason to reboot is to install a new kernel, Poettering's 30 day default storage for tempfiles in /var/tmp, or for that matter, a default for files in /var/lock or /var/run, ... is absolutely absurd - this is why we have cron and shell scripts (and Perl/Python).

tl;dr: This is why I started of with that amusing simile about HTTP 418, because if you just trust systemd to hold your hand, you just may find that one of your mission critical Enterprise services informs you that it's been told it's a #Teapot 🫖

That's not a good thing when 5, 500, or 50,000 people expect their shit to just work without ever having to know your name as the person who makes that happen for them.

Disk based storage is the safe bet; that's why #Redhat still does it that way. But it's certainly not the most performant, and requires the steady fingers of a competent systems administrator for the care and feeding of the tmp file systems - otherwise, like so many n00bs have discovered (in the days when hard drives didn't exceed a Gigabyte in capacity), you may wake up one day to find that you've hammered your filesystem, everything is running, but nothing is doing anything it's supposed to be doing - now, rm and du have become your best friends until the moment you discover that rotating your log files and keeping /tmp clean is actually part of your job...

Even as a casual workstation user on your personal laptop. It's your job.

For those interested, here's an example of the systemd defaults for tmps should you wisely consider the beneficial consequences of responsible planning for managing the size of your growing tempfile directories, from the Arch Wiki:

/etc/tmpfiles.d/tmp.conf
# see tmpfiles.d(5)
# always enable /tmp directory cleaning
D! /tmp 1777 root root 0

# remove files in /var/tmp older than 10 days
D /var/tmp 1777 root root 10d

# namespace mountpoints (PrivateTmp=yes) are excluded from removal
x /tmp/systemd-private-*
x /var/tmp/systemd-private-*
X /tmp/systemd-private-*/tmp
X /var/tmp/systemd-private-*/tmp

Umm... 10 days, /var/tmp? IMNSHO, that's maybe just a tad (way more than a tad) aggressive.

Although I've so far only alluded to it, I actually do recommend that you consider removing /var/tmp from any cleanup schedule too, instead using cron and shell scripts, along with a little proactive monitoring to keep that part of your tempfile systems clean.

And remember: "You may be short, and you may be stout, but unless it's April 1st, don't let anyone call you a Teapot." 🫖

For further reading you can checkout the [LWN article here] (https://lwn.net/Articles/975565/?ref=news.itsfoss.com).

As always, feel free to boost and share this with others (sharing is love), and I'm always interested in hearing your thoughts and suggestions in the comments.

I hope that helps. All the best!

#tallship #FOSS #Linux #Slackware #Arch #Gentoo #SuSE #Fedora

⛵

.

I'm still worried about Debian's plan to move /tmp to tmpfs and auto cleaning it every so often. There are too many things stored in /tmp like SSH connections and tmux sessions. I know there is a way to stop the cleanup, but having to remember to do this on every Debian machine is going to be troubling.

https://lwn.net/SubscriberLink/975565/bcce68a68d82d63a/

#Debian #tmpfs

@RustyCrab @zero You can experiment mounting the location it writes files to to a RAM based filesystem like #tmpfs.

Any thoughts or experiences on using #ProfileSyncDaemon in production?

(Daemon that syncs your browser's profile & cache to RAM to reduce SSD wear and increase performance)

🌐 https://github.com/graysky2/profile-sync-daemon#profile-sync-daemon

#linux #ram #tmpfs #performance #ssd

Any thoughts or experiences on using #ProfileSyncDaemon in production?

(Daemon that syncs your browser's profile & cache to RAM to reduce SSD wear and increase performance)

🌐 https://github.com/graysky2/profile-sync-daemon#profile-sync-daemon

#linux #ram #tmpfs #performance #ssd

Any thoughts or experiences on using #ProfileSyncDaemon in production?

(Daemon that syncs your browser's profile & cache to RAM to reduce SSD wear and increase performance)

🌐 https://github.com/graysky2/profile-sync-daemon#profile-sync-daemon

#linux #ram #tmpfs #performance #ssd

Any thoughts or experiences on using #ProfileSyncDaemon in production?

(Daemon that syncs your browser's profile & cache to RAM to reduce SSD wear and increase performance)

🌐 https://github.com/graysky2/profile-sync-daemon#profile-sync-daemon

#linux #ram #tmpfs #performance #ssd

Any thoughts or experiences on using #ProfileSyncDaemon in production?

(Daemon that syncs your browser's profile & cache to RAM to reduce SSD wear and increase performance)

🌐 https://github.com/graysky2/profile-sync-daemon#profile-sync-daemon

#linux #ram #tmpfs #performance #ssd

I personally use #tmpfs as root file system and my home folder is on #btrfs using zstd compression.

Note: in #nixos you can boot using only /boot and /nix this is how i run tmpfs as rootfs

My #Slimbook / new laptop adventure continues! And with it a new blog post:

https://matija.suklje.name/installation-plans-for-my-new-laptop

TL;DR:

• why I decided for #EndeavourOS on a #Btrfs #RAID-1 on two #LUKS encrypted SSDs and not something else
• how I intend to mitigate the challenges this combination brings with it
• how to leverage #Tmpfs to make your SSD live longer and make your browser much faster
• #Borg is a great backup tool
• #Wayland … I hope

Do you know your Linux file systems? Sandra Henry-Stocker looks at several file systems to help you understand the differences https://www.fosslife.org/know-your-linux-file-systems #FileSystem #Linux #btrfs #XFS #ext4 #tmpfs #OpenSource #FOSS

@ebn
I'm glad you've found a [new/old] home, and it's good you can tell us why you didn't like #NixOS. And thank you for sharing that #tmpfs and #ZFS root@blank link, it is a fascinating way to run your operating system! ✌️😎

How To Sync Browser Profile Into Tmpfs (RAM) In Linux #WebBrowser #Tmpfs #Psd #ProfileSyncDaemon #Rsync #Linux
https://ostechnix.com/how-to-sync-browser-profile-into-tmpfs-ram-in-linux/

How To Sync Browser Profile Into Tmpfs (RAM) In Linux #WebBrowser #Tmpfs #Psd #ProfileSyncDaemon #Rsync #Linux
https://ostechnix.com/how-to-sync-browser-profile-into-tmpfs-ram-in-linux/

Due to popular demand, here's a legacy boot / MBR edition of my blogpost "NixOS ❄️: tmpfs as root": https://elis.nu/blog/2021/03/nixos-tmpfs-as-root-legacy-boot-edition/

#nixos #tmpfs #linux

How To Write Log Files In RAM Using Log2ram In Linux #log2ram #logfiles #linux #tmpfs #ram #memory #Linux
https://www.ostechnix.com/how-to-write-log-files-in-ram-using-log2ram-in-linux/

Sync Browser Profile Into Tmpfs (RAM) Using Profile-sync-daemon In Linux To Improve Browser Speed And Responsiveness #ProfileSyncDaemon #psd #BrowserProfile #BrowserSpeed #Linux #BashScript #tmpfs
https://www.ostechnix.com/how-to-sync-browser-profile-into-tmpfs-ram-in-linux/

Logging to persistent tmpfs on Raspbian “jessie”

At the end of Using a Raspberry Pi 2 Model B as a router/firewall for the home LAN I wrote that I decided not to put /var/log into tmpfs, because:

1. I wanted the logs to be persistent
2. I thought that the wear would result in less and less of the sd card to become available (and 16GB for logs should last a loong time)

As it turned out the sd card died after one month.

I don’t know if the cause was excessive logging, the use of ntopng (which did write quite a lot, both in the number of files, the number of files, and in the total storage used, which was approximately 0,5GB after 30 days of uptime) or simply a bad sd card.

However, going forward with a new sd card, I’ve done the following:

1. Removed ntopng
2. Put /var/log on tmpfs (limited to 100MB in size), synced to a backing store on the sd card using rsync

For setting up the logging I found some existing web pages that took me part of the way, but not all the way:

• Raspberry Pi: Extending the life of the SD card (this is where I got the fstab line from)
• Observium persistent ramdisk (this is where I got the script and the crontab settings from)
• Setting up overlayFS on Raspberry Pi (this is the where I got the systemctl command to set up the init.d script, as well as the script headers to make it work)
• How does systemd use /etc/init.d scripts? (more information about how systemd uses /init.d scripts)

Here is what I did:

1. Logged in as root and did everything below as root
2. Edited /etc/fstab and added the following line:

   tmpfs    /var/log    tmpfs    defaults,noatime,nosuid,mode=0755,size=100m    0 0

3. Created an /etc/init.d/ramdiskvarlog file with the following contents

   #!/bin/sh### BEGIN INIT INFO# Provides:          ramdiskvarlog# Required-Start:    $local_fs $time# X-Stop-After:      $time# Required-Start:    $local_fs $time# Required-Stop:     $local_fs# Default-Start:     S# Default-Stop:      0 1 6# Short-Description: Restore to and save logs from tmpfs filesystem# Description:       Restore to and save logs from tmpfs filesystem### END INIT INFO# /etc/init.d/ramdiskvarlog#case "$1" in  start)    echo "Copying files to ramdisk"    rsync -av /var/backup/log/ /var/log/    echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk Synched from HD >> /var/log/ramdisk_sync.log    ;;  sync)    echo "Synching files from ramdisk to Harddisk"    echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk Synched to HD >> /var/log/ramdisk_sync.log    rsync -avy --delete --recursive --force /var/log/ /var/backup/log/    ;;  stop)    echo "Synching logfiles from ramdisk to Harddisk"    echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk Synched to HD >> /var/log/ramdisk_sync.log    rsync -av --delete --recursive --force /var/log/ /var/backup/log/    ;;  *)    echo "Usage: /etc/init.d/ramdisk {start|stop|sync}"    exit 1    ;;esacexit 0

4. Made /etc/init.d/ramdiskvarlog executable:

   chmod +x /etc/init.d/ramdiskvarlog

5. Created a directory to store the logs persistently, and populated it initially with the contents of the existing /var/log with the following command line commands :

   mkdir -p /var/backup/log/etc/init.d/ramdiskvarlog sync

6. Made the /etc/init.d/ramdiskvarlog script be run at boot time and during orderly shutdown with the following command line command

   systemctl enable ramdiskvarlog

7. Made the /etc/init.d/ramdiskvarlog script copy the contents of /var/log to the sd card once every 24 hours
   1. At the command line gave the command

      crontab -e

   2. In the editor that opened on the crontab, added a line with the following contents

      2 7 * * * /etc/init.d/ramdiskvarlog sync >> /dev/null 2>&1

8. Created a test file with “touch /var/log/test.log”, rebooted the raspberry pi with “sync; reboot”, and then:
   1. Checked with the mount command that /var/log was on tmpfs, found the following line in the output, which meant that /var/log was on tmpfs

      tmpfs on /var/log type tmpfs (rw,nosuid,noatime,size=102400k,mode=755)

   2. Checked that the /var/log/test.log file was present (and the file was present, which meant that it had been synced to persistent storage on shutdown and restored on boot)

After completing the setup, I popped the sd card out and put it into a card reader on a debian desktop computer. Then I made an image of the working sd card, so that if/when the sd card dies, getting a working router again should be as quick as just dd’ing the image to a new sd card and then switching sd card on the raspberry Pi.

Lesson learned!

#jessie #logging #persistentRamdisk #raspbian #raspbian8 #raspbianJessie #rsync #tmpfs

Logging to persistent tmpfs on Raspbian “jessie”

At the end of Using a Raspberry Pi 2 Model B as a router/firewall for the home LAN I wrote that I decided not to put /var/log into tmpfs, because:

1. I wanted the logs to be persistent
2. I thought that the wear would result in less and less of the sd card to become available (and 16GB for logs should last a loong time)

As it turned out the sd card died after one month.

I don’t know if the cause was excessive logging, the use of ntopng (which did write quite a lot, both in the number of files, the number of files, and in the total storage used, which was approximately 0,5GB after 30 days of uptime) or simply a bad sd card.

However, going forward with a new sd card, I’ve done the following:

1. Removed ntopng
2. Put /var/log on tmpfs (limited to 100MB in size), synced to a backing store on the sd card using rsync

For setting up the logging I found some existing web pages that took me part of the way, but not all the way:

• Raspberry Pi: Extending the life of the SD card (this is where I got the fstab line from)
• Observium persistent ramdisk (this is where I got the script and the crontab settings from)
• Setting up overlayFS on Raspberry Pi (this is the where I got the systemctl command to set up the init.d script, as well as the script headers to make it work)
• How does systemd use /etc/init.d scripts? (more information about how systemd uses /init.d scripts)

Here is what I did:

1. Logged in as root and did everything below as root
2. Edited /etc/fstab and added the following line:

   tmpfs    /var/log    tmpfs    defaults,noatime,nosuid,mode=0755,size=100m    0 0

3. Created an /etc/init.d/ramdiskvarlog file with the following contents

   #!/bin/sh### BEGIN INIT INFO# Provides:          ramdiskvarlog# Required-Start:    $local_fs $time# X-Stop-After:      $time# Required-Start:    $local_fs $time# Required-Stop:     $local_fs# Default-Start:     S# Default-Stop:      0 1 6# Short-Description: Restore to and save logs from tmpfs filesystem# Description:       Restore to and save logs from tmpfs filesystem### END INIT INFO# /etc/init.d/ramdiskvarlog#case "$1" in  start)    echo "Copying files to ramdisk"    rsync -av /var/backup/log/ /var/log/    echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk Synched from HD >> /var/log/ramdisk_sync.log    ;;  sync)    echo "Synching files from ramdisk to Harddisk"    echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk Synched to HD >> /var/log/ramdisk_sync.log    rsync -avy --delete --recursive --force /var/log/ /var/backup/log/    ;;  stop)    echo "Synching logfiles from ramdisk to Harddisk"    echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk Synched to HD >> /var/log/ramdisk_sync.log    rsync -av --delete --recursive --force /var/log/ /var/backup/log/    ;;  *)    echo "Usage: /etc/init.d/ramdisk {start|stop|sync}"    exit 1    ;;esacexit 0

4. Made /etc/init.d/ramdiskvarlog executable:

   chmod +x /etc/init.d/ramdiskvarlog

5. Created a directory to store the logs persistently, and populated it initially with the contents of the existing /var/log with the following command line commands :

   mkdir -p /var/backup/log/etc/init.d/ramdiskvarlog sync

6. Made the /etc/init.d/ramdiskvarlog script be run at boot time and during orderly shutdown with the following command line command

   systemctl enable ramdiskvarlog

7. Made the /etc/init.d/ramdiskvarlog script copy the contents of /var/log to the sd card once every 24 hours
   1. At the command line gave the command

      crontab -e

   2. In the editor that opened on the crontab, added a line with the following contents

      2 7 * * * /etc/init.d/ramdiskvarlog sync >> /dev/null 2>&1

8. Created a test file with “touch /var/log/test.log”, rebooted the raspberry pi with “sync; reboot”, and then:
   1. Checked with the mount command that /var/log was on tmpfs, found the following line in the output, which meant that /var/log was on tmpfs

      tmpfs on /var/log type tmpfs (rw,nosuid,noatime,size=102400k,mode=755)

   2. Checked that the /var/log/test.log file was present (and the file was present, which meant that it had been synced to persistent storage on shutdown and restored on boot)

After completing the setup, I popped the sd card out and put it into a card reader on a debian desktop computer. Then I made an image of the working sd card, so that if/when the sd card dies, getting a working router again should be as quick as just dd’ing the image to a new sd card and then switching sd card on the raspberry Pi.

Lesson learned!

#jessie #logging #persistentRamdisk #raspbian #raspbian8 #raspbianJessie #rsync #tmpfs

Logging to persistent tmpfs on Raspbian “jessie”

At the end of Using a Raspberry Pi 2 Model B as a router/firewall for the home LAN I wrote that I decided not to put /var/log into tmpfs, because:

1. I wanted the logs to be persistent
2. I thought that the wear would result in less and less of the sd card to become available (and 16GB for logs should last a loong time)

As it turned out the sd card died after one month.

I don’t know if the cause was excessive logging, the use of ntopng (which did write quite a lot, both in the number of files, the number of files, and in the total storage used, which was approximately 0,5GB after 30 days of uptime) or simply a bad sd card.

However, going forward with a new sd card, I’ve done the following:

1. Removed ntopng
2. Put /var/log on tmpfs (limited to 100MB in size), synced to a backing store on the sd card using rsync

For setting up the logging I found some existing web pages that took me part of the way, but not all the way:

• Raspberry Pi: Extending the life of the SD card (this is where I got the fstab line from)
• Observium persistent ramdisk (this is where I got the script and the crontab settings from)
• Setting up overlayFS on Raspberry Pi (this is the where I got the systemctl command to set up the init.d script, as well as the script headers to make it work)
• How does systemd use /etc/init.d scripts? (more information about how systemd uses /init.d scripts)

Here is what I did:

1. Logged in as root and did everything below as root
2. Edited /etc/fstab and added the following line:

   tmpfs    /var/log    tmpfs    defaults,noatime,nosuid,mode=0755,size=100m    0 0

3. Created an /etc/init.d/ramdiskvarlog file with the following contents

   #!/bin/sh### BEGIN INIT INFO# Provides:          ramdiskvarlog# Required-Start:    $local_fs $time# X-Stop-After:      $time# Required-Start:    $local_fs $time# Required-Stop:     $local_fs# Default-Start:     S# Default-Stop:      0 1 6# Short-Description: Restore to and save logs from tmpfs filesystem# Description:       Restore to and save logs from tmpfs filesystem### END INIT INFO# /etc/init.d/ramdiskvarlog#case "$1" in  start)    echo "Copying files to ramdisk"    rsync -av /var/backup/log/ /var/log/    echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk Synched from HD >> /var/log/ramdisk_sync.log    ;;  sync)    echo "Synching files from ramdisk to Harddisk"    echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk Synched to HD >> /var/log/ramdisk_sync.log    rsync -avy --delete --recursive --force /var/log/ /var/backup/log/    ;;  stop)    echo "Synching logfiles from ramdisk to Harddisk"    echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk Synched to HD >> /var/log/ramdisk_sync.log    rsync -av --delete --recursive --force /var/log/ /var/backup/log/    ;;  *)    echo "Usage: /etc/init.d/ramdisk {start|stop|sync}"    exit 1    ;;esacexit 0

4. Made /etc/init.d/ramdiskvarlog executable:

   chmod +x /etc/init.d/ramdiskvarlog

5. Created a directory to store the logs persistently, and populated it initially with the contents of the existing /var/log with the following command line commands :

   mkdir -p /var/backup/log/etc/init.d/ramdiskvarlog sync

6. Made the /etc/init.d/ramdiskvarlog script be run at boot time and during orderly shutdown with the following command line command

   systemctl enable ramdiskvarlog

7. Made the /etc/init.d/ramdiskvarlog script copy the contents of /var/log to the sd card once every 24 hours
   1. At the command line gave the command

      crontab -e

   2. In the editor that opened on the crontab, added a line with the following contents

      2 7 * * * /etc/init.d/ramdiskvarlog sync >> /dev/null 2>&1

8. Created a test file with “touch /var/log/test.log”, rebooted the raspberry pi with “sync; reboot”, and then:
   1. Checked with the mount command that /var/log was on tmpfs, found the following line in the output, which meant that /var/log was on tmpfs

      tmpfs on /var/log type tmpfs (rw,nosuid,noatime,size=102400k,mode=755)

   2. Checked that the /var/log/test.log file was present (and the file was present, which meant that it had been synced to persistent storage on shutdown and restored on boot)

After completing the setup, I popped the sd card out and put it into a card reader on a debian desktop computer. Then I made an image of the working sd card, so that if/when the sd card dies, getting a working router again should be as quick as just dd’ing the image to a new sd card and then switching sd card on the raspberry Pi.

Lesson learned!

#jessie #logging #persistentRamdisk #raspbian #raspbian8 #raspbianJessie #rsync #tmpfs

Logging to persistent tmpfs on Raspbian “jessie”

At the end of Using a Raspberry Pi 2 Model B as a router/firewall for the home LAN I wrote that I decided not to put /var/log into tmpfs, because:

1. I wanted the logs to be persistent
2. I thought that the wear would result in less and less of the sd card to become available (and 16GB for logs should last a loong time)

As it turned out the sd card died after one month.

I don’t know if the cause was excessive logging, the use of ntopng (which did write quite a lot, both in the number of files, the number of files, and in the total storage used, which was approximately 0,5GB after 30 days of uptime) or simply a bad sd card.

However, going forward with a new sd card, I’ve done the following:

1. Removed ntopng
2. Put /var/log on tmpfs (limited to 100MB in size), synced to a backing store on the sd card using rsync

For setting up the logging I found some existing web pages that took me part of the way, but not all the way:

• Raspberry Pi: Extending the life of the SD card (this is where I got the fstab line from)
• Observium persistent ramdisk (this is where I got the script and the crontab settings from)
• Setting up overlayFS on Raspberry Pi (this is the where I got the systemctl command to set up the init.d script, as well as the script headers to make it work)
• How does systemd use /etc/init.d scripts? (more information about how systemd uses /init.d scripts)

Here is what I did:

1. Logged in as root and did everything below as root
2. Edited /etc/fstab and added the following line:

   tmpfs    /var/log    tmpfs    defaults,noatime,nosuid,mode=0755,size=100m    0 0

3. Created an /etc/init.d/ramdiskvarlog file with the following contents

   #!/bin/sh### BEGIN INIT INFO# Provides:          ramdiskvarlog# Required-Start:    $local_fs $time# X-Stop-After:      $time# Required-Start:    $local_fs $time# Required-Stop:     $local_fs# Default-Start:     S# Default-Stop:      0 1 6# Short-Description: Restore to and save logs from tmpfs filesystem# Description:       Restore to and save logs from tmpfs filesystem### END INIT INFO# /etc/init.d/ramdiskvarlog#case "$1" in  start)    echo "Copying files to ramdisk"    rsync -av /var/backup/log/ /var/log/    echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk Synched from HD >> /var/log/ramdisk_sync.log    ;;  sync)    echo "Synching files from ramdisk to Harddisk"    echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk Synched to HD >> /var/log/ramdisk_sync.log    rsync -avy --delete --recursive --force /var/log/ /var/backup/log/    ;;  stop)    echo "Synching logfiles from ramdisk to Harddisk"    echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk Synched to HD >> /var/log/ramdisk_sync.log    rsync -av --delete --recursive --force /var/log/ /var/backup/log/    ;;  *)    echo "Usage: /etc/init.d/ramdisk {start|stop|sync}"    exit 1    ;;esacexit 0

4. Made /etc/init.d/ramdiskvarlog executable:

   chmod +x /etc/init.d/ramdiskvarlog

5. Created a directory to store the logs persistently, and populated it initially with the contents of the existing /var/log with the following command line commands :

   mkdir -p /var/backup/log/etc/init.d/ramdiskvarlog sync

6. Made the /etc/init.d/ramdiskvarlog script be run at boot time and during orderly shutdown with the following command line command

   systemctl enable ramdiskvarlog

7. Made the /etc/init.d/ramdiskvarlog script copy the contents of /var/log to the sd card once every 24 hours
   1. At the command line gave the command

      crontab -e

   2. In the editor that opened on the crontab, added a line with the following contents

      2 7 * * * /etc/init.d/ramdiskvarlog sync >> /dev/null 2>&1

8. Created a test file with “touch /var/log/test.log”, rebooted the raspberry pi with “sync; reboot”, and then:
   1. Checked with the mount command that /var/log was on tmpfs, found the following line in the output, which meant that /var/log was on tmpfs

      tmpfs on /var/log type tmpfs (rw,nosuid,noatime,size=102400k,mode=755)

   2. Checked that the /var/log/test.log file was present (and the file was present, which meant that it had been synced to persistent storage on shutdown and restored on boot)

After completing the setup, I popped the sd card out and put it into a card reader on a debian desktop computer. Then I made an image of the working sd card, so that if/when the sd card dies, getting a working router again should be as quick as just dd’ing the image to a new sd card and then switching sd card on the raspberry Pi.

Lesson learned!

#jessie #logging #persistentRamdisk #raspbian #raspbian8 #raspbianJessie #rsync #tmpfs

Logging to persistent tmpfs on Raspbian “jessie”

At the end of Using a Raspberry Pi 2 Model B as a router/firewall for the home LAN I wrote that I decided not to put /var/log into tmpfs, because:

1. I wanted the logs to be persistent
2. I thought that the wear would result in less and less of the sd card to become available (and 16GB for logs should last a loong time)

As it turned out the sd card died after one month.

I don’t know if the cause was excessive logging, the use of ntopng (which did write quite a lot, both in the number of files, the number of files, and in the total storage used, which was approximately 0,5GB after 30 days of uptime) or simply a bad sd card.

However, going forward with a new sd card, I’ve done the following:

1. Removed ntopng
2. Put /var/log on tmpfs (limited to 100MB in size), synced to a backing store on the sd card using rsync

For setting up the logging I found some existing web pages that took me part of the way, but not all the way:

• Raspberry Pi: Extending the life of the SD card (this is where I got the fstab line from)
• Observium persistent ramdisk (this is where I got the script and the crontab settings from)
• Setting up overlayFS on Raspberry Pi (this is the where I got the systemctl command to set up the init.d script, as well as the script headers to make it work)
• How does systemd use /etc/init.d scripts? (more information about how systemd uses /init.d scripts)

Here is what I did:

1. Logged in as root and did everything below as root
2. Edited /etc/fstab and added the following line:

   tmpfs    /var/log    tmpfs    defaults,noatime,nosuid,mode=0755,size=100m    0 0

3. Created an /etc/init.d/ramdiskvarlog file with the following contents

   #!/bin/sh### BEGIN INIT INFO# Provides:          ramdiskvarlog# Required-Start:    $local_fs $time# X-Stop-After:      $time# Required-Start:    $local_fs $time# Required-Stop:     $local_fs# Default-Start:     S# Default-Stop:      0 1 6# Short-Description: Restore to and save logs from tmpfs filesystem# Description:       Restore to and save logs from tmpfs filesystem### END INIT INFO# /etc/init.d/ramdiskvarlog#case "$1" in  start)    echo "Copying files to ramdisk"    rsync -av /var/backup/log/ /var/log/    echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk Synched from HD >> /var/log/ramdisk_sync.log    ;;  sync)    echo "Synching files from ramdisk to Harddisk"    echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk Synched to HD >> /var/log/ramdisk_sync.log    rsync -avy --delete --recursive --force /var/log/ /var/backup/log/    ;;  stop)    echo "Synching logfiles from ramdisk to Harddisk"    echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk Synched to HD >> /var/log/ramdisk_sync.log    rsync -av --delete --recursive --force /var/log/ /var/backup/log/    ;;  *)    echo "Usage: /etc/init.d/ramdisk {start|stop|sync}"    exit 1    ;;esacexit 0

4. Made /etc/init.d/ramdiskvarlog executable:

   chmod +x /etc/init.d/ramdiskvarlog

5. Created a directory to store the logs persistently, and populated it initially with the contents of the existing /var/log with the following command line commands :

   mkdir -p /var/backup/log/etc/init.d/ramdiskvarlog sync

6. Made the /etc/init.d/ramdiskvarlog script be run at boot time and during orderly shutdown with the following command line command

   systemctl enable ramdiskvarlog

7. Made the /etc/init.d/ramdiskvarlog script copy the contents of /var/log to the sd card once every 24 hours
   1. At the command line gave the command

      crontab -e

   2. In the editor that opened on the crontab, added a line with the following contents

      2 7 * * * /etc/init.d/ramdiskvarlog sync >> /dev/null 2>&1

8. Created a test file with “touch /var/log/test.log”, rebooted the raspberry pi with “sync; reboot”, and then:
   1. Checked with the mount command that /var/log was on tmpfs, found the following line in the output, which meant that /var/log was on tmpfs

      tmpfs on /var/log type tmpfs (rw,nosuid,noatime,size=102400k,mode=755)

   2. Checked that the /var/log/test.log file was present (and the file was present, which meant that it had been synced to persistent storage on shutdown and restored on boot)

After completing the setup, I popped the sd card out and put it into a card reader on a debian desktop computer. Then I made an image of the working sd card, so that if/when the sd card dies, getting a working router again should be as quick as just dd’ing the image to a new sd card and then switching sd card on the raspberry Pi.

Lesson learned!

#jessie #logging #persistentRamdisk #raspbian #raspbian8 #raspbianJessie #rsync #tmpfs