I'd just do "ls -lahS /var/log", which is long/all/human/sort, and
should put the biggest files at the top, Looked like syslog, messages,
user.log were huge. Just delete them and run fsck.ext4(is ext4 right?)
on it from single-user, or unmounting it first if mounted. I've had
this happen, that should fix the inode problem, and reboot after fsck if
not.
Might want to cat the file prior to deletion and have a lookie to see
what is filling your logs. The fact it's in user.log too, it's likely a
userland app spewing bonkers - make it happy or reduce runtime syslog
verbosity. Pulseaudio was always a pita for this.
For this reason alone, I usually build /var/log or /var even as a
separate lvm or partition. If it fills, usually only syslog daemon dies
as a result. Learn how to use lvm lv's, they're quite helpful for these
sorts of issues and way more flexible than raw partitions. I also
generally don't get inode issue persistence if it fills like I do with a
raw partition.
-mb
On 09/04/2012 08:05 PM, Lisa Kachold wrote:
> Glad you got into it Joe - see below,
>
> On Tue, Sep 4, 2012 at 8:45 AM, <joe@actionline.com
> <mailto:joe@actionline.com>> wrote:
>
>
> Thanks Lisa. Deleting some of the /var/log/messages files did free up
> enough space that I was able to boot into kde. But questions
> remain: why
> did the system create about 3-gig of messages? And that only reduced the
> root partition from 12-gigs to 9-gigs when there is actually only
> 3.5-gigs
> of valid content in the root partition?
>
>
> > You can check your free inodes via: # df -i
> > or via: # tune2fs -l /dev/sdb1 | grep *Free
>
> df -i shows 770K Inodes available 162K used and 608K available, so
> that is
> not the problem.
>
> Okay that's all good!
>
>
> tune2fs does not work.
>
> > and delete all the files in;
> > /var/spool/mail/root
> > /var/log/messages
> > /var/log/mail*
> > /var/log/mess*
>
> /var/log/messages did have enormous files and /var/log/syslog also has
> more enormous files which seem to be identical in size to
> /var/log/messages. Why are these duplicated?
>
>
> Your /etc/syslog.conf will show you what you are logging and why,
>
> > Look for core files
>
> locate core <E> generates a huge list of files that contain 'core'
> as part
> of the file names, but none that I can identify as core dumps. How can I
> find only core dumps?
>
> > You can also use yum or apt-get to remove a package to quickly
> get some
> > diskspace frree
>
> |find / -name core -exec rm {} \;
> |
>
> I have been able to 'rm' some files (i.e. messages), but what packages
> could I safely remove?
>
> > Use locate (find-utils) to identify and remove core files, iso's and
> > Virtualbox images. But you can't find or locate without /tmp file
> space.
>
> > removing the root mail spool (be sure to create it again with
> > "touch /var/spool/mail/root | chown root:mail /var/spool/mail/root"
>
> > You can also determine what files were modified 2 days ago:
> > touch -t 201209172359 dummy
> > find / -name 'DS*' -newer dummy
>
>
> You can also run:
>
> du -h
>
> to see what is populated with what.
>
> df -h
>
> is also good
>
> locate *,iso
>
> locate *,gz
>
> locate *.rpm
>
>
>
> --
> (503) 754-4452 Android
> (623) 239-3392 Skype
> (623) 688-3392 Google Voice
> **
> <http://it-clowns.com>Safeway.com
> Automation Engineer
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)