Long timeout when modifying a ticket

[Jean-Marc Lasgouttes]

Daer Trac users,

We have a trac installation that worked well until fairly recently. Now,
every time one tries to modify a ticket, nothing happens for a minute or
so, and then the modification is done.

This is not a matter of load on the server, it looks more like a timeout
somewhere.

I see nothing of interest in trac.log. Have you already experienced such
a situation? Where should I look?

Any idea welcome.

JMarc

[Jun Omae]

Hi,

Hmm, I have not encountered similar issues.

Please describe your environment which Trac is running with:

* Trac version
* Python version
* Database and the version
* Version control (svn, git, hg)
* Installed plugins and enabled plugins

Please share entire of trac.ini and trac.log after enabling logging
with DEBUG and reproducing it, if possible.

--
Jun Omae <jun...@gmail.com> (大前 潤)

[Jean-Marc Lasgouttes]

Le 04/03/2026 à 00:25, Jun Omae a écrit :
> Hmm, I have not encountered similar issues.
>
> Please describe your environment which Trac is running with:
>
> * Trac version
> * Python version
> * Database and the version
> * Version control (svn, git, hg)
> * Installed plugins and enabled plugins
>
> Please share entire of trac.ini and trac.log after enabling logging
> with DEBUG and reproducing it, if possible.

Hello,

Thanks for your answer, and sorry for my own timeout. Here is some
information

Server is: Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-101-generic x86_64)

trac version 1.6

Python 3.12.3

root@www:/home/lyx/www# file trac/db/trac.db
trac/db/trac.db: SQLite 3.x database, last written using SQLite version
3045001, page size 1024, file counter 6603671, database pages 478423,
1st free page 351893, free pages 4643, cookie 0x3d, schema 1, UTF-8,
version-valid-for 6603671

version control is git

Enabled plugins are indicated here if I am not mistaken. I am not sure
what the correct information is
[components]
acct_mgr.admin.* = enabled
acct_mgr.api.* = enabled
acct_mgr.db.sessionstore = disabled
acct_mgr.guard.accountguard = enabled
acct_mgr.htfile.htdigeststore = disabled
acct_mgr.htfile.htpasswdstore = enabled
acct_mgr.http.* = disabled
acct_mgr.notification.* = enabled
acct_mgr.pwhash.* = disabled
acct_mgr.register.* = disabled
acct_mgr.register.basiccheck = enabled
acct_mgr.register.bottrapcheck = enabled
acct_mgr.register.emailcheck = enabled
acct_mgr.register.emailverificationmodule = enabled
acct_mgr.register.regexpcheck = enabled
acct_mgr.register.registrationmodule = disabled
acct_mgr.register.usernamepermcheck = enabled
acct_mgr.web_ui.* = enabled
acct_mgr.web_ui.resetpwstore = disabled
trac.web.auth.loginmodule = disabled
trackeywords.web_ui.* = enabled
tracopt.ticket.deleter = enabled
tracopt.versioncontrol.git.* = enabled


trac.ini is in attachment and trac.log (which is quite large) is at
https://who.paris.inria.fr/Jean-Marc.Lasgouttes/trac.log.xz

This has been obtained by adding a single comment to a ticket. It looks
like trac restarted >100K times!

I hope that this information makes sense to you.

Regards,
JMarc

[Jun Omae]

Thanks for the sharing trac.ini and trac.log. Investigating the
trac.log, I found many "OperationalError: database is locked" in the
log.

First, I consider that "PRAGMA journal_mode WAL" and "PRAGMA
synchronous NORMAL" might help it. The parameters can be set in [trac]
database option like the following:

[trac]
database = sqlite:db/trac.db?journal_mode=wal&synchronous=normal

I recommend to use PostgreSQL rather than SQLite for internet-facing Trac.

[Clemens Feige]

In our TRAC (on Linux) we can sometimes (not always) see long delays on
ticket creation / modification which seem to be related to TRAC
notification via e-mail.

Check if you have enabled notification via e-mail or "CC" field in your
ticket.

Clemens

[Jean-Marc Lasgouttes]

Le 03/04/2026 à 12:17, Clemens Feige a écrit :
>
> 'Jean-Marc Lasgouttes' via Trac Users wrote on 03.03.2026 at 16:38:
>> Daer Trac users,
>>
>> We have a trac installation that worked well until fairly recently.
>> Now, every time one tries to modify a ticket, nothing happens for a
>> minute or so, and then the modification is done.
>>
>> This is not a matter of load on the server, it looks more like a
>> timeout somewhere.
>>
>> I see nothing of interest in trac.log. Have you already experienced
>> such a situation? Where should I look?>

> In our TRAC (on Linux) we can sometimes (not always) see long delays on
> ticket creation / modification which seem to be related to TRAC
> notification via e-mail.
>
> Check if you have enabled notification via e-mail or "CC" field in your
> ticket.

Thank you for your answer that makes me follow up on this subject as I
should have done earlier. It turned out that the issue was that

It seems the "lock" was a mailing problem, i.e., for whatever reason
smtp.osuosl.org started to be resolved in ipv6 way, that freezes
for 10 mins and then switches back to ipv4.

We switched the glibc resolver to prefer IPv4 over IPv6 for
all applications. Mail seems to work fine again and trac is back.

Sorry for not letting you know earlier. Thanks to Jun for suggesting
creating a fill debug log, that was useful.

JMarc

[Clemens Feige]

So we can conclude that TRAC may "hang" or appear "locked" for a longer
time period (minutes) in case of certain e-mail issues when attempting
to send ticket notifications via mail.

Of course the mail problems are not the fault of TRAC. But I would
expect that the TRAC server should not be blocked in such cases.

I am not a TRAC developer and cannot judge if this is worth a ticket.
Also I do not know how to reproduce.

Clemens