managing web2py logs under uwsgi

[Dave S]

I run web2py under nginx and uwsgi.  The latter runs in master mode (rather than emperor mode), and I think it is what drives my question:

How do I control the size of the web2py log files?

I have seen the files grow without bound (until I did a manual log rotate), but currently the web2py/logs/web2py.log file is being rotated for me after 1-3 requests.  The uwsg conf file web2py.ini specifies a log-maxsize, but that's for the uwsgi logs, and the web2py logs are being kept under 300 bytes.

(300 bytes x 6 rotations with a few requests per second means I don't have to capture error clues)

Versions:
web2py 2.1.5.4 for the moment, as I didn't jump on the .17 versions, and the .18s kept jumping every time I began to be less inert
nginx 1.14.1
uwsgi 2.0.15 (master=true, processes=4)

/dps

[Dave S]

Having had to restart the server recently, I studied this again.

It appears that when you start uwsgi, [web2py dir]/logs/web2py.log grows normally until it reaches a limit, and then each uwsgi worker starts autorotating it, and each rotation gives you 1-3 requests worth of logging, and this goes on until the next restart.

My uwsgi is set to autorotate logs, but I'd expect that to only deal with uwsgi's logs.  Is the behavior above controlled by appfactory() in gluon/main.py?

/dps

[Dave S]

In order to debug an issue, I've been using the "touch routes.py" trick, and that is a more graceful way of restarting the web2py.log.  It appears that autorotates start at about 1,000,000 bytes (but it's difficult to catch the actual turning point).  The file used for uwsgi configuration has a log size value of 2,000,000 which fits the size of the uwsgi.logs as rotated by uwsgi.

/dps


 

[Dave S]

On Tuesday, July 30, 2019 at 7:08:43 PM UTC-7, Dave S wrote:

On Monday, July 29, 2019 at 3:06:54 PM UTC-7, Dave S wrote:

On Tuesday, April 23, 2019 at 8:00:44 PM UTC-7, Dave S wrote:

I run web2py under nginx and uwsgi.  The latter runs in master mode (rather than emperor mode), and I think it is what drives my question:

How do I control the size of the web2py log files?

I have seen the files grow without bound (until I did a manual log rotate), but currently the web2py/logs/web2py.log file is being rotated for me after 1-3 requests.  The uwsg conf file web2py.ini specifies a log-maxsize, but that's for the uwsgi logs, and the web2py logs are being kept under 300 bytes.

(300 bytes x 6 rotations with a few requests per second means I don't have to capture error clues)

Versions:
web2py 2.1.5.4 for the moment, as I didn't jump on the .17 versions, and the .18s kept jumping every time I began to be less inert
nginx 1.14.1
uwsgi 2.0.15 (master=true, processes=4)

/dps

Having had to restart the server recently, I studied this again.

It appears that when you start uwsgi, [web2py dir]/logs/web2py.log grows normally until it reaches a limit, and then each uwsgi worker starts autorotating it, and each rotation gives you 1-3 requests worth of logging, and this goes on until the next restart.

My uwsgi is set to autorotate logs, but I'd expect that to only deal with uwsgi's logs.  Is the behavior above controlled by appfactory() in gluon/main.py?

 

In order to debug an issue, I've been using the "touch routes.py" trick, and that is a more graceful way of restarting the web2py.log.  It appears that autorotates start at about 1,000,000 bytes (but it's difficult to catch the actual turning point).  The file used for uwsgi configuration has a log size value of 2,000,000 which fits the size of the uwsgi.logs as rotated by uwsgi.

 
After spending more time looking at appfactory() and also the Python logging library, I can now report:

• the 1000000 comes from my own logging.conf (probably a default value)
  
• setting the delay parameter (= 1) in the args list for rotating file handlers has ameliorated the issue.  With that set, logs growing to the limit happens often enough that I can debug much more easily.

/dps