Hi.

I'm using fossil 2.10 on OpenBSD 6.7 with httpd and cgi script. Everything seems to work fine so far.

However, when I look in the error.log via the administration web interface I see the following error message repetitively added (some information is retracted for privacy):

---

...

------------- 2020-06-18 22:49:19 UTC ------------
warning: SQLITE_WARNING(28): attempt to open "/db/mydomain.org.fossil" as file descriptor 0
HTTP_HOST=scm.mydomain.org
HTTP_REFERER=https://scm.mydomain.org/errorlog
HTTP_USER_AGENT=Mozilla/5.0 (X11; OpenBSD amd64; rv:77.0) Gecko/20100101 Firefox/77.0
PATH_INFO=/errorlog
REMOTE_ADDR=X.X.X.X
REQUEST_METHOD=GET
REQUEST_URI=/errorlog
------------- 2020-06-18 22:49:19 UTC ------------
warning: SQLITE_WARNING(28): cannot open file at line 38757 of [c20a353364]
HTTP_HOST=scm.mydomain.org
HTTP_REFERER=https://scm.mydomain.org/errorlog
HTTP_USER_AGENT=Mozilla/5.0 (X11; OpenBSD amd64; rv:77.0) Gecko/20100101 Firefox/77.0
PATH_INFO=/errorlog
REMOTE_ADDR=X.X.X.X
REQUEST_METHOD=GET
REQUEST_URI=/errorlog
------------- 2020-06-18 22:49:19 UTC ------------
warning: SQLITE_CANTOPEN(14): os_unix.c:38757: (9) open(/db/mydomain.org.fossil) - Bad file descriptor
HTTP_HOST=scm.mydomain.org
HTTP_REFERER=https://scm.mydomain.org/errorlog
HTTP_USER_AGENT=Mozilla/5.0 (X11; OpenBSD amd64; rv:77.0) Gecko/20100101 Firefox/77.0
PATH_INFO=/errorlog
REMOTE_ADDR=X.X.X.X
REQUEST_METHOD=GET
REQUEST_URI=/errorlog

...

---

What could be the problem here?

Some info details regarding fossil/sqlite version:

---

This is fossil version 2.10 [9d9ef82234] 2019-10-04 21:41:13 UTC
Compiled on May  8 2020 16:29:47 using clang-8.0.1 (tags/RELEASE_801/final) (64-bit)
Schema version 2015-01-24
Detected memory page size is 4096 bytes
zlib 1.2.3, loaded 1.2.3
hardened-SHA1 by Marc Stevens and Dan Shumow
SSL (LibreSSL 3.1.1)
libfuse 2.6, loaded unknown
FOSSIL_ENABLE_LEGACY_MV_RM
UNICODE_COMMAND_LINE
FOSSIL_DYNAMIC_BUILD
HAVE_PLEDGE
SQLite 3.30.0 2019-10-04 15:03:17 c20a353364
SQLITE_DEFAULT_FILE_FORMAT=4
SQLITE_DEFAULT_WAL_SYNCHRONOUS=1
SQLITE_ENABLE_DBSTAT_VTAB
SQLITE_ENABLE_FTS4
SQLITE_ENABLE_FTS5
SQLITE_ENABLE_JSON1
SQLITE_ENABLE_LOCKING_STYLE=0
SQLITE_ENABLE_STMTVTAB
SQLITE_LIKE_DOESNT_MATCH_BLOBS
SQLITE_MAX_EXPR_DEPTH=0
SQLITE_OMIT_DECLTYPE
SQLITE_OMIT_DEPRECATED
SQLITE_OMIT_GET_TABLE
SQLITE_OMIT_LOAD_EXTENSION
SQLITE_OMIT_PROGRESS_CALLBACK
SQLITE_OMIT_SHARED_CACHE
SQLITE_THREADSAFE=0
SQLITE_USE_ALLOCA

---

Thank you very much for your feedback!

Bob

Please try:

• Visit the Admin/Settings page
• Click the "backoffice-disable" button and press "Apply"

Let us know whether or not this helps.

After following your instructions the error messages have disappeared.

I'm very new to Fossil and still learning. It would be interesting to learn what exactly caused the errors and why.

Thank you greatly for this amazing work!

It would be interesting to learn what exactly caused the errors and why.

If I knew what caused it, I'd fix it :-)

Background: Fossil sometimes needs to do some administrative work in the background, after a webpage runs, such as send email notifications about changes. This is accomplished using a mechanism we call "the backoffice".

After a webpage runs and has delivered it's content, if there is backoffice work to be done, the Fossil process that computed the webpage will launch a separate Fossil process to run in the background to take care of the administrative stuff. There is an elaborate dance to ensure that there is never more than one background process running, even if there are dozens of webpage processes per second.

The backoffice works great on Linux. But for some reason (still unknown to me) it gives problems on OpenBSD. And the issues you were seeing are symptomatic of the kinds of problems it causes.

Fortunately, the only thing backoffice is (currently) used for is to send email notifications. So if you don't have email notifications enabled, the solution is to simply disable the backoffice.

Corrupted content. The page you are trying to view cannot be shown because an error in the data transmission was detected.

That message is coming either from your browser or from some agent which sits between yourself and fossil. We've never had a report of such a message here before, the implication being...

As there are no errors on fossil log...

... that the problem is not fossil but some service sitting between it and you.

(any ways to see SQL logs)

There are no general-purpose logs in fossil. You can trace the SQL as it passes through fossil, but that's only useful in CLI mode:

fossil command -sqltrace ...arguments...

with the caveat that that can generate tons of output.

After that warning going back to previous page I was logged as user, same goes for ticket creation though it throws error going back changes are made (so permission are ok), but cannot create wiki page or redirect /home page.

It sounds like only pages which POST lead to that error?

It sounds like only pages which POST lead to that error?

Yeah, just checked with wikiedit
Though it throws same error the edit was successful.

My setup is almost similar to doc,
I'll look further into httpd+fastcgi (I had problem with fastcgi parameters, created a thread eariler)

Thanks for insight.

I think I also saw the warnings about fd 0 on OpenBSD when running in a chroot. The problem turned out to be missing /dev/null in the chroot.

That said, if fossil uses fd 0 and something wants to close stdin, then it might end up closing the SQLite databse. I'd try adding /dev/null to the chroot.

Oh, and build a newer Fossil from source - there's security issues.

I do have /dev/null and /dev/urandom in place in the chroot. I created them using MAKEDEV command.

That said, if fossil uses fd 0 and something wants to close stdin, then it might end up closing the SQLite databse.

sqlite (or was it fossil?) was patched several years ago after an assert() in fossil sent output to the stderr file ID and ended up writing the message to the sqlite handle used by the core fossil repository. Thankfully, it only corrupted the user table, not any of the "real" content. When that was discovered, sqlite (or perhaps fossil's use of sqlite) was patched to never open a db on a file ID less than (IIRC) 2.

That episode is mentioned briefly in the "How To Corrupt An SQLite Database" document. A bug in stunnel4 was causing it to launch Fossil without stderr (file descriptor 2) open. So when the repository database opened, it opened on fd 2. But then a bug happened in Fossil - an assertion fault. And when an assert() fails, it blindly writes the error to fd 2 before calling panic(). But fd 2 was connected to the database file, not to stderr, hence a few bytes of the database were overwritten with the "assertion fault" error message.

FWIW,

I've got /var/www/dev/null, random and urandom and its working fine with trunk on 6.7. I'll have a more detailed look tonight when I get back.