history_d (Channel logging daemon) needs limitation in logging amounts

Bug #406082 reported by Emraef
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Sapidlib
Won't Fix
Undecided
Unassigned

Bug Description

The history_d produced logs in the amount of 700+MB in just over one month on a server that is still in development. That is to say with a peek user count of 3 our mud libs footprint reached nearly 1GB 90% of it being logs.

The problem is two fold.

- The history_d has no check for the amount of HD space is being taken up by its logs.
- The history_d moves logs into lib/log/archives (note I'm unsure when this happens)

Revision history for this message
Richard Thomas Harrison (harrison-rt) wrote :

I took the decision that it wouldn't be the job of the history daemon to take care of HD space because that really is the job of the root/admin user. The history daemon's job is to just log stuff for future access.

If you look near the end of /adm/obj/master.c you will see the function log_file() which moves stuff into the archive directory when the log file gets too big.

I have this in my crontab to make the archive directory smaller...

-- crontab --

# At 5 minutes to midnight each day run this.
# bzip2's all un-compressed files.
55 23 * * * find /usr/local/muds/sapid/main/lib/log/archive -type f ! -name "*.bz2" -exec bzip2 -9f {} \; 2>&1 > /dev/null

# On the 1st day of the month at midnight run this.
# Removes all files over 28 days old.
0 0 1 * * find /usr/local/muds/sapid/main/lib/log/archive/* -maxdepth 0 -mtime +28 -exec rm -rf {} \;

-- crontab --

Changed in sapidlib:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.