Unable to boot due to no space in /

[caprus]

sudo rm messages* warn*

that deleted all the huge files and allowed me to boot


journalctl -f_1.txt


sudo dmesg_1.txt

:~> balooctl status 
Baloo File Indexer is running 
Indexer state: Indexing file content 
Total files indexed: 200,393 
Files waiting for content indexing: 1 
Files failed to index: 0 
Current size of index is 1.31 GiB

:~> balooctl failed 
All Files were indexed successfully

journalctl output was rapidly filling up with similar entries, and /var/log/messages had reappeared and grown to almost one Gb in the space of 5 minutes + after boot. so I ran

balooctl disable

The PC is now useable.

Question: I have a very fast SSD in this laptop. Do I really need baloo indexing? This PC is no longer used for any demanding functions that require terrific performance.

[dcurtisfra]

I have a very fast SSD in this laptop. Do I really need baloo indexing?

You seem to have content indexing enabled – why?

---

Please check with “balooctl config show contentIndexing” – for most people this could be set to “no” …
When in the KDE System Settings → Workspace → Search (Plasma Search, File Search) – you should be seeing that, /srv/ and /var/ are not being indexed.

• “balooctl config show includeFolders” should be indicating that, your home directory is included in the list of Folders being indexed …

Your Baloo user configuration should be something like this:

 > cat .config/baloofilerc 
[Basic Settings]
Indexing-Enabled=true

[General]
dbVersion=2
exclude filters=.pch,*.pyo,cmake_install.cmake,*.vm*,.svn,*.rcore,*.moc,.git,*.class,*.lo,litmain.sh,*.csproj,*.pc,CMakeCache.txt,*.fasta,*.orig,nbproject,confdefs.h,.moc,*.gmo,.uic,CVS,.npm,*.jsc,.yarn-cache,*.qmlc,CTestTestfile.cmake,node_packages,*.omf,*.pyc,config.status,__pycache__,.xsession-errors*,autom4te,libtool,*.qrc,.bzr,*.init,CMakeTmpQmake,*.rej,*.aux,po,*.faa,*.map,node_modules,*.elc,conftest,*~,.obj,*.so,*.po,*.m4,CMakeTmp,*.fastq,*.tmp,CMakeFiles,Makefile.am,*.swap,core-dumps,*.gb,ui_*.h,qrc_*.cpp,*.la,*.o,moc_*.cpp,*.ini,.hg,*.fna,confstat,.histfile.*,*.gbff,lost+found,*.db,*.a,*.nvram,*.part,*.fq,_darcs,lzo,.yarn,*.loT
exclude filters version=4
exclude folders[$e]=/srv/,/var/
first run=false
folders[$e]=$HOME/
 > 
 > cat .config/baloofileinformationrc 
[Misc]
version=11

[Show]
channels=false
comment=false
contentCreated=false
contentSize=false
created=false
depends=false
embeddedRating=false
fileName=false
fileSize=false
kfileitem#group=false
kfileitem#owner=false
kfileitem#permissions=false
lastModified=false
lyrics=false
mimeType=false
photoMeteringMode=false
photoPixelXDimension=false
photoPixelYDimension=false
photoSaturation=false
photoSharpness=false
photoWhiteBalance=false
replayGainAlbumGain=false
replayGainAlbumPeak=false
replayGainTrackGain=false
replayGainTrackPeak=false
url=false
 > 
 > cat /etc/xdg/baloofilerc
[General]
only basic indexing=true
 >

[dcurtisfra]

Do I really need baloo indexing?

The file search functions in the KDE Desktop applications are using this utility.

• A quick search of “the Net” indicates that, Baloo is either “love it and use it” or “absolutely hate it – get rid of it” – for example this Reddit post: <https://www.reddit.com/r/kde/comment...sma_but_baloo/> – the last comment made is “love it” …

Please note that, digiKam took more than a few years to properly integrate Baloo into it's photo management database functionality.

---

Personally, I have Baloo enabled only for file searching within KDE applications – for content searching I tend to use command line utilities …

• Yes, I can understand that, those people who haven't managed to get their data sorted into relevant directories need content searching functionality – if all your data is in a single directory, you'll need such functionality to access the correct files …

I am aware of at least one Mainframe computer which had only one directory – for all users – a “very flat” directory structure …

[caprus]

You seem to have content indexing enabled – why?

I've disabled for now

Please check with “balooctl config show contentIndexing” – for most people this could be set to “no” …

:~ # balooctl config show contentIndexing
no

When in the KDE System Settings → Workspace → Search (Plasma Search, File Search) – you should be seeing that, /srv/ and /var/ are not being indexed.

no entries are present

• “balooctl config show includeFolders” should be indicating that, your home directory is included in the list of Folders being indexed

the only entry is /home/ (??)

Your Baloo user configuration should be something like this:

 > cat .config/baloofilerc 
[Basic Settings]
Indexing-Enabled=true

[General]
dbVersion=2
exclude filters=.pch,*.pyo,cmake_install.cmake,*.vm*,.svn,*.rcore,*.moc,.git,*.class,*.lo,litmain.sh,*.csproj,*.pc,CMakeCache.txt,*.fasta,*.orig,nbproject,confdefs.h,.moc,*.gmo,.uic,CVS,.npm,*.jsc,.yarn-cache,*.qmlc,CTestTestfile.cmake,node_packages,*.omf,*.pyc,config.status,__pycache__,.xsession-errors*,autom4te,libtool,*.qrc,.bzr,*.init,CMakeTmpQmake,*.rej,*.aux,po,*.faa,*.map,node_modules,*.elc,conftest,*~,.obj,*.so,*.po,*.m4,CMakeTmp,*.fastq,*.tmp,CMakeFiles,Makefile.am,*.swap,core-dumps,*.gb,ui_*.h,qrc_*.cpp,*.la,*.o,moc_*.cpp,*.ini,.hg,*.fna,confstat,.histfile.*,*.gbff,lost+found,*.db,*.a,*.nvram,*.part,*.fq,_darcs,lzo,.yarn,*.loT
exclude filters version=4
exclude folders[$e]=/srv/,/var/
first run=false
0folders[$e]=$HOME/ 
 > cat .config/baloofileinformationrc 
[Misc]
version=11

[Show]
channels=false
comment=false
contentCreated=false
contentSize=false
created=false
depends=false
embeddedRating=false
fileName=false
fileSize=false
kfileitem#group=false
kfileitem#owner=false
kfileitem#permissions=false
lastModified=false
lyrics=false
mimeType=false
photoMeteringMode=false
photoPixelXDimension=false
photoPixelYDimension=false
photoSaturation=false
photoSharpness=false
photoWhiteBalance=false
replayGainAlbumGain=false
replayGainAlbumPeak=false
replayGainTrackGain=false
replayGainTrackPeak=false
url=false
 > 
 > cat /etc/xdg/baloofilerc
[General]
only basic indexing=true
 >

[/QUOTE]
all are the same

[caprus]

I am aware of at least one Mainframe computer which had only one directory – for all users – a “very flat” directory structure …

ouch, one can only imagine...

[dcurtisfra]

ouch, one can only imagine...

The colleague who informed me of the mainframe with a flat directory structure did mention that, they had a search function – they needed it …

[dcurtisfra]

Any idea what wrote these and/or what they mean?

It's a little bit strange that, in /var/log/ the archived ‘messages’ and ‘warn’ are not being compressed – “.xz” extension …
Is the systemd “logrotate” Timer service enabled on your system?

 > systemctl list-unit-files | grep -i 'rotate'
logrotate.service                                                static         
logrotate.timer                                                  enabled        
 >

What does ‘/etc/logrotate.conf’ look like?

• The default content looks like this –

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
compress

# comment these to switch compression to use gzip or another
# compression scheme
compresscmd /usr/bin/xz
uncompresscmd /usr/bin/xzdec

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

The contents of the directory ‘/etc/logrotate.d/’ should look something like this –

 > ls /etc/logrotate.d/
apache2  dracut    mariadb  net-snmp  quagga  samba          snapper  vsftpd          wtmp  zypper.lr        zypp-refresh.lr
chrony   iscsiuio  mcelog   pbl       rsync   samba-winbind  syslog   wpa_supplicant  xdm   zypp-history.lr
 >

You may have to execute “rpm --verify --all” to work out which packages have to be forcibly re-installed in order that, the logrotate configuration has been set-up properly on your system …

[dcurtisfra]

Any idea what wrote these and/or what they mean?

If you look into those text files, you'll see a load of system messages and application warnings – the KDE Plasma applications write an awful amount of warnings to ‘/var/log/warn’ …

• One day we'll convince software developers to stop tracing to user's system logs – we'll need to re-program their teachers before that'll happen …

Unfortunately, the systemd Journal also suffers from this malady …

• As well as ensuring that “logrotate” has it's default settings and, that the “logrotate” timer service has been enabled, please check the systemd Journal status –

 # journalctl --disk-usage
 # journalctl --verify                             ## Simply delete any user journals which are corrupt …
 # journalctl --flush
 # journalctl --rotate
 # journalctl --vacuum-size=50M                ## for example …
 # journalctl --vacuum-time=1weeks          ## for example …

[tckosvic]

Posted additionally on prior related thread

I was getting warnings about limited free disk space from (df) disk free (df said 93g used out of 100g) in root (/) but (du) disk usage said only 20% disk usage. This was after I had just increased root (/) partition from 40G to 100g based upon previous df warnings.

Further investigation showed large image files that I had deleted were still on the disk in /var/.Trash-0. There were two 35g image files I had been experimenting with on virtual machines and later deleted. Their filenames included word (deleted) but they were still occupying disk space per df command. Furthermore I found more deleted files still on disk in /opt/.Trash-0.

I manually deleted all these files as root and my df and du lined up at about only 20% disk usage.

I think many people have enlarged root partitions and maybe even changed out disk drives based upon erroneous data from df warnings not knowing that supposedly deleted files were still on their disks.
Check for deleted files still occupying disk space in .Trash-0 in root directories such as /var and /opt before you go and resize root.

btrfs file system was used for root at that time. I have since gone back to ext4.