trac-admin hotcopy corrupts source database if stdout is closed

[simon.fayer05@…]

While writing a backup script, I found that if I close stdout on the trac-admin hotcopy command, the source database gets partially overwritten with the usual output text (causing it to become corrupt).

A script to reproduce this is simply:

#!/bin/sh
trac-admin /path/to/myenv hotcopy /backups/trac >&-

(If you run it a second time, you should get OperationalError: unsupported file format due to the corrupt database).

My environment is standard CentOS7 with python 2.7.5.

I think this has appeared before in ticket #5222 (I didn't re-open that one as it was so old).

[Jun Omae]

It is not reproduced with SQLite. What database are you using?

I think stdout shouldn't be closed even if it can be reproduced. Why? I think the stdout should be redirected to /dev/null if you don't need stdout.

[simon.fayer05@…]

I am using SQLite, I tried it with the same trac version (1.0.10) on Fedora which doesn't show the issue.

Now I've had a more detailed look at it, I think I can see what's happening… Doing sys.stdout.write always writes to fd number 1, whatever file is open there. On my CentOS machine, that's the SQLite database during a hotcopy, but on Fedora fd 1 is closed and the database is number 3 (so nothing bad happens).

Yes, writing to /dev/null works fine, it was just surprising to find my database corrupt after running a backup the first time. In this instance the corruption is obvious as it happens to write over a bit of the database header, but there may be times when this happens elsewhere in the file and goes unnoticed.

Perhaps it would be possible to test if stdout or stderr are closed in the startup of trac-admin and print an error? That would at least prevent anyone getting caught out by this again.

[Jun Omae]

If stdout and stderr are closed, error messages cannot be printed to stdout/stderr. Closing as wontfix.