apache logfile > 2 gigas

[Soupault François]

OS : HP-UX 11.0 64 bits
Apache 1.3.26
file system vxfs allow large file.
This week, my apache log file is 2 gigas bit large, and since, no more access are logged but there is no message in the error_log
Thanks

[Robert-Jan Goossens]

François,

I think your Apache logfile is limited to the large file parameter on your logical volume. To enable larger files

Online JVS

# fsadm -F vxfs -o largefiles /your_mount_point

Not online JVS

# umount your mount point
# fsadm -F vxfs -o largefiles /dev/rlvolxx

And add the largefiles option in the /etc/fstab.

Hope this helps,
Robert-Ja

[Robert-Jan Goossens]

Sorry,

Made a mistake,

Not online JVS

# umount your_file_system
# fsadm -F vxfs -o largefiles /dev/vgxx/rlvolxx

Robert-Jan

[Soupault François]

thanks, but my file system allow large file.

[RAC_1]

Is it really allowing files greater than 2gb?

Check -- mount -p. check your file system.

Is apache running properly? Hung etc?

[Robert-Jan Goossens]

Hi,

Just to be shure, could you check next command.

# fsadm -F vxfs /your_apache_filesystem
nomultifsets
largefiles

Robert-Jan

[Christopher Caldwell]

I'm a bit fuzzy on this, but I believe that 32 bit apps may have to make a provision to access largefiles on 64 bit systems.

See man creat64, which mentions

The standard POSIX interfaces may be used by 32-bit applications to
create and access large files if compiled with _FILE_OFFSET_BITS set
to 64.

and

For 64-bit applications, access to large files is automatic, as long
as the underlying file system is enabled for large files. The
interfaces on this man page are available to 64-bit applications, for
convenience in porting, but provide no additional capabilities. The
exception is O_LARGEFILE, which is not visible to 64-bit applications.


To figure out if your app is 32 bit or 64 bit, type
$file [name_of_your_app]
e.g.
$file httpd

If this app is 32 bit (the diagnostic might read something like PA-RISC1.1 shared executable dynamically linked -not stripped), then you've probably got a problem in the way Apache was built.

[Steven E. Protter]

I think you have a larger problem than expanding the filesystem.

Your website has a massive error_log that can possibly be managable. I can't see how it can be useful. Still for security audit purposes you probably need to keep it.

Run a script to archive it once in a while via cron:

cp logs/error_log /tmp/error_log
> error_log

Run this once a day or whatever to keep that log size down.

Also your apache is a bit out of date and needs to be updated to 1.3.27 to have some critical fixes.

If its on the public internet and their are cgi form scripts, make sure robots.txt exists.

SEP

[Elmar P. Kolkman]

Simplest solution, and to keep things managable, like SEP said, clean the logfiles. Your problem is with the access_log, but I would clean them all after making a copy.

For instance, run once a day:

for i in /*
do
cp $i $i.`date +%w`
>$i
done

This will keep a copy of the files, with the day-of-week as extension, making it possible to search your logfiles back for info. You could also use sequence numbers or things like that. It depends on the speed of growth what is best.

[Soupault François]

Thanks for all and specialy for Christopher Caldwell.
When i do "file httpd" the response is
PA-RISC1 shared ......
I will try to compile apache in 64 bits mode

[Andrew Cowan]

I know that your original question was regarding increasing the maximum filesize, however I think that you have the obvious here.

Why is your logfile (>2Gb) so massive?
Is this much logging effecting the performance of Apache itself?
Could you lower the level of logging, so as to remove any unnecessary messages?

With logs this massive you are in grave danger of missing vital clues to (attempted) attacks, and (potential) security problems.

If your log has to be this large I would suggest that you employ some automated log processing to filter out exceptional or important messages.