### Background Unix convention and the Linux Filesystem Hierarchy standard define several paths under which processes look for certain information, or use to write certain information. When one needs to setup a user-specific environment, as a non-root user - most of those locations are either inaccessible, or readable but without the ability to write to files or create new ones. So, one must use alternatives. In principle, we could just treat a user's home directory like another /; however, that's not common practice. There is also the custom of creating a $HOME/.my_app directory. Most apps which create those use those for configuration, but some also for other kinds of data (Eclipse, Firefox, Thunderbird come to mind as hiding gobs of data in there). But that means we may have dozens if not hundreds of .something in the home directory, which is quite unseemly. Finally, it has also become common for some apps to write into $HOME/.local and $HOME/.config, which does not "litter" the home directory itself: $HOME/.config can be seen as an equivalent of /etc and $HOME.local of /usr; so, quite useful, but - it doesn't cover /var and its subdirectories. ### Actual question Where, under a user's home directory, should we, or should a program we write, store the data which a system-level program would store in /var, or subdirectories of /var? That is to say: "files whose content is expected to continually change during normal operation of the system, such as logs [and] spool... files" (to quote the FHS), as well as cache, non-static databases, lock files, run files and log files?

I just installed Ubuntu 24.04, and I made a mistake: I put the /var directory on its own partition, and its size is 10 GB. After a few days it is already full. Is there a way to fix this problem without reinstalling the OS from scratch? Is it possible to resize a partition, even loosing its contents? What is a suggested size for the /var directory? This is my partition table: Model: WD_BLACK SN850X 2000GB (nvme) Disk /dev/nvme0n1: 2000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 8 1049kB 1075MB 1074MB fat32 boot boot, esp 1 1075MB 323GB 322GB xfs / 2 323GB 426GB 103GB linux-swap(v1) swap swap 3 426GB 437GB 10.7GB ext4 var 4 437GB 439GB 2147MB ext4 temp 6 439GB 547GB 107GB xfs 3rdp 5 547GB 1406GB 859GB ext4 home 7 1406GB 1427GB 21.5GB ext4 crypt This is the contents of my /var directory: ~> sudo bash -c 'shopt -s dotglob; du -hxs /var/*' 7.0M /var/backups 661M /var/cache 4.0K /var/crash 8.9G /var/lib 4.0K /var/local 0 /var/lock 49M /var/log 16K /var/lost+found 4.0K /var/mail 4.0K /var/metrics 4.0K /var/opt 0 /var/run 13M /var/snap 52K /var/spool 108K /var/tmp 4.0K /var/.updated Here are more details about my partitions: ~> df -h Filesystem Size Used Avail Use% Mounted on tmpfs 5.9G 2.7M 5.9G 1% /run /dev/nvme0n1p1 300G 29G 272G 10% / tmpfs 30G 180M 30G 1% /dev/shm tmpfs 5.0M 12K 5.0M 1% /run/lock efivarfs 148K 62K 81K 44% /sys/firmware/efi/efivars /dev/nvme0n1p6 100G 2.5G 98G 3% /opt /dev/nvme0n1p7 20G 24K 19G 1% /crypt /dev/nvme0n1p4 2.0G 103M 1.7G 6% /tmp /dev/nvme0n1p3 9.8G 9.6G 0 100% /var /dev/nvme0n1p5 787G 13G 734G 2% /home /dev/nvme0n1p8 1022M 41M 982M 4% /boot/efi tmpfs 5.9G 196K 5.9G 1% /run/user/1000

I've noticed that Flatpak, a popular package manager for Linux, installs applications in the /var directory instead of the traditional /usr directory. While /usr has been the conventional location for installing applications, Flatpak opts for /var, a directory used for variable data such as logs, spools, and temporary files. What are the reasons behind this decision? Does it offer any advantages over the traditional approach?

**Scenario** I am on an embedded Linux system. As usual /var/log/ is the directory when all the logs are stored. I have a directory called /safepath which is created during image creation and it is on persistent memory. It means that whatever I place under /safepath persists across reboot sessions. I want the logs in /var/log/ to not be lost on every reboot and wish to make it persistent through the reboots. So I thought to mount /var/log/ on to /persists by doing a mount --bind /var/log /safepath which I read from this interesting discussion [here](https://unix.stackexchange.com/questions/198590/what-is-a-bind-mount) **Question:** But doing this still causes me to lose the data in /var/log/. Is this correct? How can one force /var/log/ to persist across reboot sessions?

UPDATE: No, it is not safe to delete these snaps. I deleted them and can no longer open three of my applications. Attempt at opening Visual Studio Code:

~$ code
internal error, please report: running "code" failed: cannot find installed snap "code" at revision 33: missing file /snap/code/33/meta/snap.yaml

The snaps in /var/lib/snapd/snaps are taking up 2.0 GB of space on my disk right now. I want to clear up space, but I'm not sure if deleting these snaps is safe (if so, can I just run sudo rm -rf *?) This is what I see when I run snap list:

code_32.snap              gnome-3-28-1804_116.snap   gnome-logs_93.snap
code_33.snap              gnome-3-34-1804_27.snap    gnome-system-monitor_135.snap
core18_1705.snap          gnome-3-34-1804_33.snap    gnome-system-monitor_145.snap
core18_1754.snap          gnome-calculator_730.snap  gtk-common-themes_1502.snap
core_8935.snap            gnome-calculator_748.snap  gtk-common-themes_1506.snap
core_9066.snap            gnome-characters_495.snap  partial
discord_109.snap          gnome-characters_539.snap  spotify_36.snap
gnome-3-28-1804_110.snap  gnome-logs_100.snap        spotify_41.snap

What are the gnome, code, and core snaps? I've installed Discord and Spotify. Will deleting the discord and spotify snaps lead to any issues with opening those applications? I'm using Ubuntu 18.04.3 LTS.

I'm trying to execute a command on a new tmux window. A simple console/terminal pdf reader. The script needs argument, a PDF file, the file name may include spaces. I've tried this:

#!/bin/bash

tmux new-window "pdftotext -layout -nopgbrk "${1}" - | less"

It works on files without spaces, eg 1.pdf. I've tried sh instead of bash, $1, "$1" instead of "${1}", no effect.

Today i had powered on my PC, and it powered off few times, while power-on workflow. I had check in log, but didn't find the reason, I had powered it on about 14:00 or near, (few times until was successfully powered it on). The excidental power off was happened at the various moments: after system loaded and GRUB menu on screen or after password was entered and X-Window manager loaded, and old browser session restarted, or when new internet page started to open. Then it continued to work until now. in a listing below it show few lines after 14:13 boot, and few lines before the new boot in 14:19, it works about 6 min before exidental power-off so it may concluded the reasons, but i'm has not find error messages like : because of ... reason PC power-off or smth else. I had read man journalctl, just i don't know, what subject i need to find? **How to find the proper exidental power-off reason ?** Below i had listed the log from first power on today which has included all shorts periods in a start and normal workflow until evening > sudo journalctl -S "today" -U "17:00" ov 04 04:40:26 debian systemd: Reached target shutdown.target - System Shutdown. Nov 04 04:40:26 debian systemd: Reached target final.target - Late Shutdown Services. Nov 04 04:40:26 debian systemd: systemd-poweroff.service: Deactivated successfully. Nov 04 04:40:26 debian systemd: Finished systemd-poweroff.service - System Power Off. Nov 04 04:40:26 debian systemd: Reached target poweroff.target - System Power Off. Nov 04 04:40:26 debian systemd: Shutting down. Nov 04 04:40:26 debian systemd-shutdown: Syncing filesystems and block devices. Nov 04 04:40:26 debian systemd-shutdown: Sending SIGTERM to remaining processes... Nov 04 04:40:26 debian systemd-journald: Received SIGTERM from PID 1 (systemd-shutdow). Nov 04 04:40:26 debian systemd-journald: Journal stopped -- Boot 5e8abe8207f54af483786970a32bfdb1 -- Nov 04 14:13:53 debian kernel: microcode: microcode updated early to revision 0x22, date = 2022-0> Nov 04 14:13:53 debian kernel: Linux version 6.1.0-13-amd64 (debian-kernel@lists.debian.org) (gcc> Nov 04 14:13:53 debian kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-13-amd64 root=UUID=a4> Nov 04 14:13:53 debian kernel: BIOS-provided physical RAM map: Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009b3ff] usable Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x000000000009b400-0x000000000009ffff] reserved Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x0000000000100000-0x000000000fffffff] usable Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x0000000010000000-0x0000000012150fff] reserved Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x0000000012151000-0x00000000771abfff] usable Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x00000000771ac000-0x0000000079a73fff] reserved Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x0000000079a74000-0x0000000079aadfff] ACPI data Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x0000000079aae000-0x0000000079e7cfff] ACPI NVS Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x0000000079e7d000-0x000000007a23dfff] reserved Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x000000007a23e000-0x000000007aa2cfff] usable Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x000000007aa2d000-0x000000007aa2dfff] ACPI NVS Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x000000007aa2e000-0x000000007aa2ffff] reserved Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x000000007aa30000-0x000000007aae4fff] usable Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x000000007aae5000-0x000000007ab94fff] reserved Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x000000007ab95000-0x000000007affffff] usable Nov 04 14:13:53 debian kernel: BIOS-e820: [mem 0x000000007b000000-0x000000007fffffff] reserved Nov 04 14:13:53 d this is the lines before the next boot, so it's may be concluded the power-off reason, but i don't understand, which? There aren't any error messages ov 04 14:17:54 debian systemd: Finished systemd-remount-fs.service - Remount Root and Kernel > Nov 04 14:17:54 debian systemd: systemd-firstboot.service - First Boot Wizard was skipped beca> Nov 04 14:17:54 debian systemd: systemd-pstore.service - Platform Persistent Storage Archival > Nov 04 14:17:54 debian systemd: Starting systemd-random-seed.service - Load/Save Random Seed... Nov 04 14:17:54 debian systemd: Starting systemd-sysusers.service - Create System Users... Nov 04 14:17:54 debian kernel: lp: driver loaded but no devices found Nov 04 14:17:54 debian kernel: ppdev: user-space parallel port driver Nov 04 14:17:54 debian systemd: Finished systemd-random-seed.service - Load/Save Random Seed. Nov 04 14:17:54 debian systemd: first-boot-complete.target - First Boot Complete was skipped b> Nov 04 14:17:54 debian systemd: Finished systemd-modules-load.service - Load Kernel Modules. Nov 04 14:17:54 debian systemd: Starting systemd-sysctl.service - Apply Kernel Variables... Nov 04 14:17:54 debian systemd: Finished systemd-sysusers.service - Create System Users. Nov 04 14:17:54 debian systemd: Starting systemd-tmpfiles-setup-dev.service - Create Static De> Nov 04 14:17:54 debian systemd: Finished systemd-sysctl.service - Apply Kernel Variables. Nov 04 14:17:54 debian systemd-journald: Journal started Nov 04 14:17:54 debian systemd-journald: Runtime Journal (/run/log/journal/337f99dad83d4d2fb> Nov 04 14:17:53 debian systemd-modules-load: Inserted module 'lp' Nov 04 14:17:53 debian systemd-modules-load: Inserted module 'ppdev' Nov 04 14:17:53 debian systemd-modules-load: Inserted module 'parport_pc' Nov 04 14:17:54 debian systemd: Started systemd-journald.service - Journal Service. Nov 04 14:17:54 debian systemd: Starting systemd-journal-flush.service - Flush Journal to Pers> Nov 04 14:17:54 debian systemd: Finished systemd-tmpfiles-setup-dev.service - Create Static De> Nov 04 14:17:54 debian systemd: Starting systemd-udevd.service - Rule-based Manager for Device> Nov 04 14:17:54 debian systemd-journald: Time spent on flushing to /var/log/journal/337f99da> -- Boot 59ee50dd793649a3b9022074301768ee -- ov 04 14:19:07 debian kernel: microcode: microcode updated early to revision 0x22, date = 2022-0> Nov 04 14:19:07 debian kernel: Linux version 6.1.0-13-amd64 (debian-kernel@lists.debian.org) (gcc> Nov 04 14:19:07 debian kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-13-amd64 root=UUID=a4> Nov 04 14:19:07 debian kernel: BIOS-provided physical RAM map: Nov 04 14:19:07 debian kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009b3ff] usable Nov 04 14:19:07 debian kernel: BIOS-e820: [mem 0x000000000009b400-0x000000000009ffff] reserved Nov 04 14:19:07 debian kernel: BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved Nov 04 14:19:07 debian kernel: BIOS-e820: [mem 0x0000000000100000-0x000000000fffffff] usable Nov 04 14:19:07 debian kernel: BIOS-e820: [mem 0x0000000010000000-0x0000000012150fff] reserved Nov 04 14:19:07 debian kernel: BIOS-e820: [mem 0x0000000012151000-0x00000000771abfff] usable Nov 04 14:19:07 debian kernel: BIOS-e820: [mem 0x00000000771ac000-0x0000000079a73fff] reserved Nov 04 14:19:07 debian kernel: BIOS-e820: [mem 0x0000000079a74000-0x0000000079aadfff] ACPI data BIOS Information Vendor: American Megatrends Inc. Version: 5.13 Release Date: 10/19/2020 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 5 MB Characteristics: PCI is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) ACPI is supported USB legacy is supported BIOS boot specification is supported Targeted content distribution is supported UEFI is supported BIOS Revision: 5.13

I have a fresh install of Debian 9.0.0. It has a separate 1 GB partition for /var formatted at ext4. When I shutdown from the terminal, using shutdown -h now, there is a bright-red error message stating "failed unmounting /var". What is the fix for this error?

Clearing the apt packages cache does not help, neither do I have any extra update packages. Whenever I try to apt install something, it tells me I have no space left. df -h says my /var/ is full, so I'm trying to resize it, but neither fdisk or lvextend seem to work. Do I need a reinstall? edit: df output

Filesystem       Size  Used Avail Use% Mounted on
udev             7.8G     0  7.8G   0% /dev
tmpfs            1.6G  1.8M  1.6G   1% /run
/dev/nvme0n1p6    23G   15G  7.3G  67% /
tmpfs            7.8G     0  7.8G   0% /dev/shm
tmpfs            5.0M     0  5.0M   0% /run/lock
/dev/nvme0n1p9   1.8G  156K  1.7G   1% /tmp
/dev/nvme0n1p7   9.1G  8.6G   23M 100% /var
/dev/nvme0n1p10  864G   46G  775G   6% /home
tmpfs            1.6G   80K  1.6G   1% /run/user/1000

I am running CentOS 7. I have /var on a separate hard drive, and smartctl shows that it has some read error. Hence, I would like to move /var to another hard drive. For the new hard drive, I used gparted to create two partitions (1MB alignment). Then, I mounted one partition to /mnt/var_new and then rsync -avHPSAX --filter='-x security.selinux' /var/ /mnt/var_new/. And as expected, one file was failed to sync (that just confirmed why smartctl got read errors): WARNING: cache/yum/x86_64/7/centos-sclo-sclo/gen/primary_db.sqlite failed verification -- update discarded (will try again). cache/yum/x86_64/7/centos-sclo-sclo/gen/primary_db.sqlite 1,607,680 100% 2.81MB/s 0:00:00 (xfr#3, ir-chk=1309/1607) rsync: read errors mapping "/var/cache/yum/x86_64/7/centos-sclo-sclo/gen/primary_db.sqlite": Input/output error (5) ERROR: cache/yum/x86_64/7/centos-sclo-sclo/gen/primary_db.sqlite failed verification -- update discarded. And no other file was failed to sync (I re-ran rsync again to confirm). Then, I correctly removed the entry that mounted the old /var and added a new entry to mount the new /var. Then, I rebooted and then it failed to start with tons of failures (just plain black screen). Then, I booted into emergency mode, and the new /var did mount correctly that I could see the related files there. I did read some articles that /var needed to be in 755 mode and /var/tmp needed to have the sticky bit set. I had both. What did I do wrong? Thanks!

I have a RHEL 7.9 virtual machine without GUI, and I would like to make updates via the yum update command but it tells me that the disk is full, especially on the **/var** folder. I thought I'd take 10GB/20GB from the **/home** partition and transfer it to **/var**. It's possible ? If so, what steps should I take so as not to damage the machine? I have seen this post but it seems to me the ideal solution: Change size of /home partition and move /var/www on new partition

I have been attempting to move my /var folder to a new partition. I am using Debian 10.7 and have an 8GB processor so am trying to save space. I have tried several things but part of the data always seems to disappear. Here is what I have tried: 1. Create new partition /dev/sda7 2. mount /dev/sda7 to /mnt/newvar in /etc/fstab 3. boot into single user mode 4. mount / -rw -o remount 5. cp -arpPv /var/* /mnt/newvar (when I examine the /mnt/newvar folder, it is the same size as the /var folder so I assume the copy worked correctly, all folders appear to be there) 6. mv /var /var.old 7. mkdir /var 8. edit /etc/fstab and mount /dev/sda7 on /var 9. restart system When the system comes up, several folders are not viewable in /var, but if I boot to a rescue USB I can see all the folders on /var from there. Can I delete the /mnt/newvar folder? and the /var.old folder? If I do that then I seem to permanently lose the unviewable folders/files. I wanted to move this folder to a new partition in order to make the rest of the system read-only and would like to conserve space. if I can't delete the old folders then using a different partition does not help much with that. Can anyone tell me why some folders are not viewable and how do I keep from losing my data permanently?

I'm running a python application that keeps crashing with

.OperationalError: database or disk is full

, even though I have 300G in the partition where this is installed and from where I'm running it. However, I noticed my

/var

partition is being filled and emptied while the application is running, and that it is 90% full. I saw this with System Monitor. Turns out that when I see the partitions with Baobab, I see only 6G available of 50G in that partition. However... $ sudo du -sh /var/ 8.4G /var/ I simply cannot see the files/directories saturating my

/var

directory, Any ideas what could be happening?

I am running out of disk space with /var system file and noticed /var/log/jenkins/jenkins.log file is occupied 7 GB. Can i safely remove this log file ?

the /var/cache directory keeps filling frequently due to yum metadata in centos 7.5 server. most of the space utilized by the below files. i have set keep cache to 0 in /etc/yum.conf as well. but still not resolved. someone please throw somelight on this issue to rectify the same.

[4.0K]  centos7-x86_64-updates
[   0]  cachecookie
[ 52M]  filelists.xml.gz
[4.0K]  gen
[535M]  filelists.xml
[252M]  filelists.xml.sqlite
**[2.7G]  other.xml
[2.8G]  other.xml.sqlite**
[201M]  primary.xml
[255M]  primary.xml.sqlite
[716M]  other.xml.gz

/var/tmp is not defined in POSIX, but is defined in FHS : 5.15. /var/tmp : Temporary files preserved between system reboots 5.15.1. Purpose The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp. Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp. This is a very difficult definition for real life situations. A package does not use /tmp, because the files should not be deleted on reboot for some reason. If a package fails to cleanup its remains in /tmp the distribution/admin can safely clean at reboot. When and how should we clean up /var/tmp? What can packages and software developers expect from /var/tmp? Do we have to clean /var/tmp after n reboots? (see also https://unix.stackexchange.com/questions/86297/what-can-go-wrong-if-var-tmp-is-on-a-temporary-filesystem and https://unix.stackexchange.com/questions/30489/what-is-the-difference-between-tmp-and-var-tmp)

myVAR='myArr' . ./myArraysFile # external file with all my arrays, one of the arrays is myArr=('one' 'two' 'three') ---------- I need to use this arrey with further scripting Examples: echo ${!myVAR} # I want it to print 'two' or for here in 'place.one' 'place.two';do ssh ${!myVAR}@$here done and so one

For certain reasons I have to delete all files that might indicate that the syatem has once been linked to the internet. I have deleted all the records in browser, and the internet ethernet address. What else I can do, such that no one is able to know that the system has linked to the internet? Can I delete all files in var/log? This is a new system with only the anaconda and relavant pachakges been installed.

I moved the /var directory to a new disk/partition, this part worked well, but I forgot to delete/move the old /var path and it is still using space on / (root) partition. How could I delete the old /var without redo all the process? Any ideas? This is what I did so far: fdisk -l mount /dev/sdb /mnt/newvar/ df -h /mnt/newvar/ rsync -aqxP /var/* /mnt/newvar/ umount /mnt/newvar/ /mnt/var/ umount /mnt/newvar/ umount /disk2/ umount /mnt/newvar/ ls -la /mnt/newvar/ df -h vim /etc/fstab fstab content: UUID=c7c73822-b6e8-4aa4-a4b2-41a70c29568f /boot ext2 defaults 0 2 /dev/mapper/zabbix--vg-swap_1 none swap sw 0 0 /dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0 UUID="3195ad53-3aaa-418c-bdc0-d341e33d76d3" /var ext3 defaults 0 2 Result of the above command: df -P / /var Filesystem 1024-blocks Used Available Capacity Mounted on /dev/mapper/zabbix--vg-root 11758232 10103908 1033988 91% / /dev/sdb 25671996 8720916 15640360 36% /var

Ran into an issue today where Apache would not load because /var/run/httpd was missing. After much hunting to find that cause of the error I was getting ([Tue Jul 25 00:06:31.574386 2017] [auth_digest:error] [pid 6179] (2)No such file or directory: AH01760: failed to initialize shm - all nonce-count checking, one-time nonces, and MD5-sess algorithm disabled). Then I saw that MariaDB was missing its /var/run/mysql directory, and PostgreSQL was missing its directory. What would cause those to not be made on system start-up / saved between reboots? I would not *expect* to need to modify init scripts as suggested in this question . ### Edit: outputs of ls -dl /var/run & ls -dl /run lrwxrwxrwx. 1 root root 6 Dec 15 2015 /var/run -> ../run drwxr-xr-x 25 root root 800 Jul 26 03:40 /run