why doesn't support actually "read" the technical request???

[sandy]

If you have been following the thread regarding access_log size, being unable to delete it, and, the size causes the 650 MB to be exceeded, with a site being shut down, the following exchange between myself and Tech Support is very disheartening. Per RocketJeff's help, and recommendations, I posted the whole thread in my post to Tech Support.

Response 1 from Tech Support was: have you tried a script or crontab to handle? I responded that in my post to them I even included the actual crontab file.

Response 2 from Tech Support, now suggests that I come to the forum since someone here may have an answer. Again, my post stated that the following was posted in the forum... including my post and RocketJeff's follow-up.

This is my response -- just sent back to the Tech Support person (I am NOT including his name). It amazes me that Tech Support can not tell me how one deletes their own access_log. The person who I am trying to help has their file sitting at 65MB right nwo, and growing steadily. The crontab can't handle it. Webstats stopped after the 4:22AM update and the Awstats stopped after the 11:22AM update.. Here is my response back:

Ummm... That is where I started.. I don't mean to be critical, BUT, my initial message
stated that the following were posts TO the forum, and, they suggested I go to
support. It surprises me that support can't tell me why we members have no control
whereby we can't delete the access_log. This is especially troubling when powweb
includes the access_log in the 650 MB limit. If we can't delete the file, how can we be
held accountable?

On 13 Jul 2003 at 15:50, Technical Support wrote:

> Hello,
>
> You might want to check out our user forums
> (http://forum.powweb.com). Many
> times you can get valuable advice from someone there who has > already dealt
> with similar issues.
>
> name removed
> Powweb Inc.
> http://support.powweb.com
========

OK... can't anyone,, powweb or otherwsie tell me how we members can delete our access_log, using the script
25 */3 * * * cat /dev/null > /www/u/uuuuuuu/logs/access_log
or otherwise????

Thanks....

[sandy]

Now my colleague's access_log is so large, can't even update Awstats manually. Results in Internal Server Error.

Thanks Tech Support. All you had to do, if you couldn't answer the simple question as to how to delete acces_logs by the owner,, was to kill it yourself.. Now my colleague has lost the past 7 hours of stats, and, since the access_log is still growing, they will lose an entire week.

Thanks again for "all" of your help :(

[tsn_radix]

25 */3 * * * cat /dev/null > /www/u/uuuuuuu/logs/access_log

wow??

would formatting a cron line like that really work??

where can i get a guideline/definition or official 'manpage' to formatting crontabs ??


Thanks..

[sandy]

25 */3 * * * cat /dev/null > /www/u/uuuuuuu/logs/access_log

wow??

would formatting a cron line like that really work??

where can i get a guideline/definition or official 'manpage' to formatting crontabs ??

It did,, all of yesterday.. after RocketJeff gave me the key command structure! You can search crontab commands,,, access_logs, etc.. but the manuals out there can be quite confusing. It raelly helps having such knowlegeable members here in the forum, who are willing to help. Sometimes they seem to know more than the tech support staff as well :)

The unfortunate thing is that after the rollover this morning, the access_log has been locked.. none of the commands work to delete it, or null it out. Powweb has done something to lock the file, and the log can't be deleted, over-written, edited or anything. In the meantime, the individuals I've helped have had both webstats and awstats stop working,, due to the large logfile. Can't eben manually update awstats,, it times out.. So far, 9.5 hours of stats lost,, and more I'm afraid :(

[btrook]

What is the access log file used for? I'm curious if this is something I should be worrying about.

[sandy]

What is the access log file used for? I'm curious if this is something I should be worrying about. The access_log maintains all of your site transactions. Anyone visiting your site leaves a fingerprint essentially, for every page and item that was viewed. It can also help you determine if unsavory things have happened to your site, IP address, etc. The access_log is used to build the webstats and awstats programs.

Unless your site has a lot of traffic, and, or you are losing stats,, there's nothing to worry about.

My colleague, who I built the crontab to generate webstats and awstats,, unfortunatley has about 500MB of transactiosn a week .. this shutdown their site yesterday, when they exceeded the 650 MB limit. Unfortunatley powweb has made some kind of change to their file management system, and we can not delete the access_log, after capturing the stats. In other words, we're held accountable for file management, yet we can't get rid of the culprit file that causes serious issues with the system management.

Figure that one out :(

[btrook]

So the file does get deleted eventually? It sounds like if you exceed 650mb before the file deletes itself, your site goes down for too much storage. Seems like a tricky way to limit bandwidth. I'm sure it wasn't intentional though.

[Naveen]

Turning off custom log will help your site not to go down, but then there is no option for it in ops as it used to be.

If for some reason powweb has denied the owner from deleting the access log, then in that case they should do the rollover everyday after the stats are updated.

[ElectricInkPen]

I agree that is is ridiculous to hold us accountable for something we have no power over. Furthermore, I can understand not allowing users to edit an option such as Powweb's default "webmail" CNAME entry in ops/dns because having a custom entry for EVERY user would place undue stress on their servers...but in this case, users want to DECREASE the load (if only the storage load) on the servers. Seems to me that through trickle-down (or up as the case may be), Powweb is causing themselves as many problems as some of their users seem to be having.

[edbot]

Sandy,

I will research the problem a bit further and coordinate with an ADMIN/ENGINEER for a solution.

[sandy]

Thanks Edbot.

It's frustarting for several reasons:

1) After all thw work to have the crontab work, to find both webstats and awstats dead in their tracks, all because of a large access_log, and

2) Inability to manage access_log to keep storage space down to a minimum.

Hope there is a reasonable solution, in order to help these individuals get their stats back once again.