https://bugzilla.redhat.com/show_bug.cgi?id=1304882 --- Comment #36 from awilliam@xxxxxxxxxx <awilliam@xxxxxxxxxx> --- OK, so I worked this out, but it's a bit...icky. It's indeed caused by database.ini being not owned by geekotest. initdb has a `--user` argument used to run as a particular user. It switches UID to that user before reading the config file. It doesn't switch GID to that user's GID. So if the file is owned by root.geekotest and initdb is run with `--user geekotest`, it winds up not being able to read the file. We can 'fix' that by making initdb switch to the specified user's GID, but unfortunately that just causes another problem. If it's operating in SQLite mode, initdb then attempts to change uid and gid *again* later: it finds out the ownership of the directory where the sqlite file will be written, and tries to switch to that UID and GID before writing the file, in order to make the file have the same ownership. In the current case the directory is owned by geekotest.root - so we wind up with a process that has already change GID to geekotest's GID trying to change it back to root's GID. Which isn't allowed. And we blow up again. An 'obvious' fix for this is to continue only switching UID (not GID) based on --user, and do it *after* the config file is read. I tested that, it works. Drawbacks: * A bit more code is now run as root * This is still kind of ugly bad code, I hate it all Another fix, I guess, would be to have /var/lib/openqa/db owned by geekotest.geekotest , which would happen to work OK with the code as it exists, I think. I dunno if that's a good fix. Thoughts? -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review