Symlink /var to another disk (non usb-thumb-drive) so that openmediavault-flashmemory plugin not necessary possible?

Zitat von oopenmediavault

As I understood the usb-flashmemory plugin is taking frequently writing processes and writes them to a tmpfs and then syncing them to disk after it accumulated a while.

The flashmemory plugin is just mounting various mountpoints in /var to tmpfs. It only syncs those back to the location on disk on shutdown unless you schedule it to be more often.

Zitat von oopenmediavault

My OMV-System for some reason was crashing in the last days. But I cannot visit logs, since they are not synced to disk and when it crashes, nothing is synced.

Run folder2ram -syncall every few hours from scheduled tasks.

Zitat von oopenmediavault

I was anyways thinking to symlink /var to a ssd drive, so that it is not on my OMV-System usb drive to make the USB-stick survive longer.

I think this is avoiding the problem. If you have an ssd, why not put the entire OS on it? If you are killing usb drives, maybe you need to move the load causing all of the writes to another disk. The OS is not doing this if you have the flashmemory plugin installed. I current have a system running on a usb stick for four years.

Zitat von oopenmediavault

So when I move logs somewhere else, will there still be some processes like that write a lot to the OMV-System so that I still shouldnt disable the flashmemory plugin even after having the logs somewhere else?

There is no reason to disable the flashmemory plugin. I use it even with nvme.

Zitat von oopenmediavault

Also: Is there some manual how to revert what has been done in the beginning when setting up the flashmemory plugin? I cannot find the procedures anymore that were shown when setting up the flashmemory plugin (where it shows you also how to disable the swap etc)

Uninstalling the plugin will revert the changes. If you followed the optional instructions on how to disable swap, there is no need to re-enable unless your system is running out of memory. swap isn't really related to flashmemory plugin. Those instructions were just another way to reduce writes to the system disk.

Zitat von oopenmediavault

even when OMV crashes

OMV isn't crashing though. Linux is.

Zitat von oopenmediavault

Syncing them via a cronjob is possible, but every hour would surely not be enough, and probably even when setting the cronjob to sync every minute , then it somehow defeats the purpose of what the flashmemory plugin does as I assume, while the last minute of logs that may have lead to the crash will still be gone, since they will not be synced.

I only recommended that because it seemed like it wasn't an instant crash and you could see logs leading up to the crash.

If only the OS is on the usb stick and other things like docker are running from data disks/ssds and the flashmemory plugin is installed, the only reason the system should crash is a junk usb stick or running out or memory or hardware is unstable.

Zitat von oopenmediavault

Thats why I want to see the logs to determine what would use up the RAM.

There are no logs showing individual process ram use. You will need to look at top periodically to see that. It may not be one process but many small processes as well.

Zitat von oopenmediavault

Anyways, so if I will symlink /var to another drive, the flashmemory plugin will still create the folder2ram fs, is that correct? So in order to have them written directly, I would still have to disable the plugin ( may it even just be for the period until I found out what crashes my "linux"

If you make the symlink, I recommend removing the flashmemory plugin before that.

What kind of system? What are you running on the system?

Zitat von oopenmediavault

yes, but sometimes it is possible to see that a process was tried to be killed because it uses too much ram or other things,

The OOMkiller doesn't always kill the process using the most ram especially when docker is involved.

Zitat von oopenmediavault

I'm using pretty many containers (around 30-40) so maybe one of them is doing something it shouldnt.

Are any of them java-based?

Zitat von oopenmediavault

Im still pretty sure it was a RAM issue

Then add swap back. This is what swap is supposed to protect you from. Just don't put it on cheap flash based storage.

Zitat von oopenmediavault

My solution to check what could be the cause now, is to periodically write the output of the top command of the top 5 memory consuming processes via cron to another server. With this I may be able to determine what could be the cause if it happens again

I would do more than 5. No need to write to another server if the server reboots fine. Just don't write to tmpfs filesystem.