It will be great if we can also show the database name (in case there are multiple databases this is usefull) and also the user who triggered the user.

Do you think it's possible to log also this information?
I suspect the users won't be available on cron or workers but for me it's not a big issue if we leave it empty.

Thanks a lot for the work. That looks pretty cool!

The last version is based on a unix socket to which all processes write periodically the status if the socket exists. And a trytond-stat curses command creates the socket and display a sorted list of the requests, see:

Maybe we should consider implementing a kind of trytond-monitor or trytond-top cli tool.

trytond instances could send a "start" and "end" message to a socket (or the existing log files), for each request, which could be captured and interpreted by trytond-monitor.

There is one problem with this design, it is that when run under µwsgi it is not possible to send the SIGUSR1 signal to the workers. I tried also by activating the option py-call-osafterfork but µwsgi keep catching the signal and output its own statistics.

Sometimes on production we may have database lock due to a long request or resource exhaustion which slow down the server etc. When such thing happens it is sometimes very difficult to find which request is causing the problem. For database lock, it is possible to find the database session but it may be very hard to link it to a specific request. This is mainly because we can not know which requests are processed now (and the cron jobs or tasks).
I propose to use a signal (SIGUSR1) to request a trytond process to dump to the log file the currently running requests, cron jobs and tasks with their starting time.
For request it will include the username if authorized, the remote address, the path, method and params (size limited from issue8101).
For cron job it will include the database, the cron id and method.
For tasks it will include the database, the task id.