[Bug Report] Missing DB

[zero77]

Describe the bug:

Include the following information:

• OpenSnitch version: 1.7.2
• OS: Debian
• OS version: forky
• Window Manager: i3
• Kernel version: 6.16.7+deb14-amd64

To Reproduce:

I have set the db path to the below as its in memory but still provides a db file to query. But some times the db is missing and i need to go into settings again to create it

/dev/shm/opensnitch.db

Steps to reproduce the behavior:

1. Go settings
2. create db in /dev/shm/opensnitch.db
3. periodically check if its there
4. go back to settings and apply to create another one if it's not

Post error logs:

Expected behavior (optional):

Screenshots:

Additional context:

[ryan-steed-usa]

/dev/shm uses tmpfs on Debian but systemd-logind periodically clears its contents. Although it shouldn't affect active sessions according to the manual, perhaps the problem lies there. man logind.conf

RemoveIPC= Controls whether System V and POSIX IPC objects belonging to the user shall be removed when the user fully logs out. Takes a boolean argument. If enabled, the user may not consume IPC resources after the last of the user's sessions terminated. This covers System V semaphores, shared memory and message queues, as well as POSIX shared memory and message queues. Note that IPC objects of the root user and other system users are excluded from the effect of this setting. Defaults to "yes".

Added in version 212.

The /tmp mount on Debian also uses tmpfs by default, have you tried using it instead? This might rule out the possibility of a problem with OpenSnitch.

[zero77]

I believe that within Debian, by default /dev/shm runs in memory, whereas /tmp does not. Which is why I am using /dev/shm. I'm not certain, but I think this is only happening after a reboot, which is when /dev/shm is cleared. Which is when I have to go into settings and recreate the DB.

[ryan-steed-usa]

I believe that within Debian, by default /dev/shm runs in memory, whereas /tmp does not. Which is why I am using /dev/shm.

Freshly installed Debian testing (forky) uses tmpfs for /tmp. Perhaps this isn't your case if you've performed in-place upgrades over an installation prior to the release of Debian 13 when tmpfs was made the default. You can check with a command like this:

user@debian-testing:~$ grep '/dev/shm\|/tmp' /proc/mounts 
tmpfs /dev/shm tmpfs rw,nosuid,nodev,inode64 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,nr_inodes=1048576,inode64 0 0

The systemd tmp.mount unit activates this. You can inspect with systemctl status tmp.mount and systemctl cat tmp.mount.

I'm not certain, but I think this is only happening after a reboot, which is when /dev/shm is cleared. Which is when I have to go into settings and recreate the DB.

I've tested reboot and manual removal of /dev/shm/opensnitch.db. The opensnitch-ui component re-creates it as expected without failure using version 1.7.2 installed from this repository. I can only replicate a similar problem by manually removing opensnitch.db while opensnitch-ui is actively running. It would be a good idea to eliminate /dev/shm as a factor, either using /tmp (if applicable to your configuration), or by adding a custom tmpfs mount.

It's worth reading the manpage which provides a simple example:

$ sudo mount -t tmpfs -o size=10M tmpfs /mnt/mytmpfs

[zero77]

Thanks for the information, I will do some more investigating.