[arch-general] Huge log file for SLiM
Dearest Arch Linux Mailing List, So I was installing a few packages on a fairly recent Arch install, when I got an error message from pacman: --------8<--------8<--------8<--------8<-------- : Retrieving packages from community... error: failed retrieving file '<package>' from <mirror1> : Failed writing body (1435 != 1448) error: failed retrieving file '<package>' from <mirror2> : Failed writing body (104 != 4344) error: failed retrieving file '<package>' from <mirror3> : Failed writing body (6 != 2896) warning: failed to retrieve some files from community error: failed to commit transaction (download library error) Errors occurred, no packages were upgraded. --------8<--------8<--------8<--------8<-------- I immediately thought of a full hard drive. `df` reported that my / partition was full. My root FS partition is around 33G in size: that's not huge, but since it is a fairly recent install, I thought there was no way it could be normally that full. I ran `du -sh` on things in my / drive, and it reported that /var/log was using up 27G of space. The culprit was SLiM's log: it was making up 99.99394 of all the space occupied by logs on my system. For some reason, log rotation does not occur with SLiM on my system. All other applications with logs work fine. Is anyone having this issue? I could not test it on other systems as it is the only one I have running SLiM. -- Sébastien Leblanc
Hi Sébastien
I have tried it once with SLiM, though the problem was that syslog-ng
wasn't placed in DAEMONS in rc.onf... So you could check that.
Sébastien Leblanc
Dearest Arch Linux Mailing List,
So I was installing a few packages on a fairly recent Arch install, when I got an error message from pacman:
--------8<--------8<--------8<--------8<--------
: Retrieving packages from community... error: failed retrieving file '<package>' from <mirror1> : Failed writing body (1435 != 1448) error: failed retrieving file '<package>' from <mirror2> : Failed writing body (104 != 4344) error: failed retrieving file '<package>' from <mirror3> : Failed writing body (6 != 2896) warning: failed to retrieve some files from community error: failed to commit transaction (download library error) Errors occurred, no packages were upgraded.
--------8<--------8<--------8<--------8<--------
I immediately thought of a full hard drive. `df` reported that my / partition was full. My root FS partition is around 33G in size: that's not huge, but since it is a fairly recent install, I thought there was no way it could be normally that full.
I ran `du -sh` on things in my / drive, and it reported that /var/log was using up 27G of space. The culprit was SLiM's log: it was making up 99.99394 of all the space occupied by logs on my system. For some reason, log rotation does not occur with SLiM on my system. All other applications with logs work fine.
Is anyone having this issue?
I could not test it on other systems as it is the only one I have running SLiM.
-- Mikkel
That might be somewhat of an issue as I am running systemd and not the
default initscripts, therefore there is no rc.conf file on my
system... Also, `ps` does not report a syslog process running.
Running `systemctl start syslog.service` responded that the syslog
service could not be found.
And this made me realise that only apps with self-managed logs are
currently leaving logs on my system. The last time kernel.log was
updated is on May 31... The only logs that are up-to-date are
'faillog', 'lastlog' and self-managed apps like pacman, X and SLiM.
`pacman -Ql slim` taught me that there's a file located in
/etc/logrotate.d/ that defines configuration for log rotation. This in
turn is used by logrotate(8) which is usually invoked automatically
through cron. This led me to the conclusion that cron(ie) was not
running on my system. Fortunately, cronie includes startup scripts for
systemd, and I was able to start cron through these commands:
# systemctl enable cronie.service
# systemctl start cronie.service
I deleted the /var/log/slim.log file, however the filesystem still
reports being full... That is weird. Sure, 27G files aren't a common
occurence. I hope my filesystem is not thrashed.
Thanks a lot Mikkel for your insight!
On 3 July 2012 16:05, Mikkel Kristiansen
Hi Sébastien I have tried it once with SLiM, though the problem was that syslog-ng wasn't placed in DAEMONS in rc.onf... So you could check that.
-- Sébastien Leblanc
Sébastien Leblanc wrote:
I deleted the /var/log/slim.log file, however the filesystem still reports being full... That is weird. Sure, 27G files aren't a common occurence. I hope my filesystem is not thrashed.
Have you restarted slim since deleting /var/log/slim.log? If not, the running process still has a handle on the file which prevents the space from being reclaimed. Jerome -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger@jabber.fr
2012/7/3 Sébastien Leblanc
That might be somewhat of an issue as I am running systemd and not the default initscripts, therefore there is no rc.conf file on my system... Also, `ps` does not report a syslog process running.
Running `systemctl start syslog.service` responded that the syslog service could not be found.
[ systemd/cronie ]
# systemctl enable cronie.service # systemctl start cronie.service
I deleted the /var/log/slim.log file, however the filesystem still reports being full... That is weird. Sure, 27G files aren't a common occurence. I hope my filesystem is not thrashed.
Restart the slim process, after that you'll have lots of free space. This may sound funny, but is actually a well standard mechanism in Unix. The space won't be freed as long as any process has it opened. mvg, Guus
On Jul 3, 2012 3:41 PM, "Sébastien Leblanc"
That might be somewhat of an issue as I am running systemd and not the default initscripts, therefore there is no rc.conf file on my system... Also, `ps` does not report a syslog process running.
Running `systemctl start syslog.service` responded that the syslog service could not be found.
I don't know if there is a proper systemctl way to do this, but syslog.service should be a symlink to your preferred logger, in my case it's rsyslog.service, but syslog-ng works as well. Put the symlink in multi user target or some other regularly invoked target. Since you don't have the link you probably have some red [FAIL] text at the very beginning of every boot. -- C Anthony
Read man pages of systemd. This will avoid a lot of struggling.
From "man 8 systemd-journald":
By default the journal stores log data in /run/log/journal/. Since /run/ is volatile log data is lost at reboot. To make the data persistent it is sufficient to create /var/log/journal/ where systemd-journald will then store the data.
systemd-journald automatically replace syslog-ng. And the new way of consulting logs is by using journalctl. Have fun. -- Alexandre Isoard
On Wed, Jul 4, 2012 at 3:13 AM, Alexandre Isoard
Read man pages of systemd. This will avoid a lot of struggling.
From "man 8 systemd-journald":
By default the journal stores log data in /run/log/journal/. Since /run/ is volatile log data is lost at reboot. To make the data persistent it is sufficient to create /var/log/journal/ where systemd-journald will then store the data.
systemd-journald automatically replace syslog-ng. And the new way of consulting logs is by using journalctl.
unless this changed in the last few weeks since i fixed it, systemd will whine if you don't have syslog.service set to *something*. journald is nice, but where is it designated as a complete replacement? i read some stuff about git/hash-chains (which is great, btw), but my [brief] expedition did not produce a clear message one way or the other. i did however surface these ... # pacman -Qql systemd | xargs zgrep syslog.service # vim /usr/lib/systemd/system/syslog.socket ---------------------------------------------- [...] The default syslog implementation should make syslog.service a symlink to itself, so that this socket activates the right actual syslog service. Examples: /etc/systemd/system/syslog.service -> /lib/systemd/system/rsyslog.service /etc/systemd/system/syslog.service -> /lib/systemd/system/syslog-ng.service [...] ---------------------------------------------- # man 7 systemd.special ---------------------------------------------- [...] syslog.service The syslog service if any. Implementations should create a symlink from the actual syslog implementation to this generic name for activating it. syslog.socket The socket unit where syslog implementations should listen on. All userspace log messages will be made available on this socket. [...] ---------------------------------------------- ... current-gen syslog daemons have many useful features/extensions and i expect will be supported for quite some time (if the intent is to 100% displace them) ... journald also has some great features, but they don't appear to be a superset of the traditional daemons AFAICS. -- C Anthony
On the arch wiki it tells how to setup journald with syslog https://wiki.archlinux.org/index.php/Systemd#Systemd_Journal and Sébastien Leblanc it also tells you how to enable syslog-ng in systemd on the link above it's systemctl enable syslog-ng.service Hope this helps abit :)
participants (7)
-
"Jérôme M. Berger"
-
Alexandre Isoard
-
Brock York
-
C Anthony Risinger
-
Guus Snijders
-
Mikkel Kristiansen
-
Sébastien Leblanc