Improve the quality of log messages

[Fr0d0Beutl1n]

Problem

I recently installed the server, and had issues with the config (#11), because I specified a wrong database location (?). To be honest, I don't really know what exactly was the issue.

Unfortunately, the log messages didn't really help troubleshooting, and were a bit misleading. When I tried adding a connection, the log message told me, that the connection was successfully added, even though it was not.

Proposed Solution

• At startup, check whether the database works, and initate a crash in case it doesn't
• When accessing the database, print a log message with details about the success of the operation

[fl0bo]

I might have had a similar issue. I've put the database in a directory called /var/lib/mollysocket and the systemd unit used here runs mollysocket as part of a corresponding user and group. In order to run correctly the directory /var/lib/mollysocket requires explicit read access. Only providing access for the group wasn't sufficient, otherwise it paniced with: Error code 1544: SQLITE_READONLY_DIRECTORY

# ls -la /var/lib/mollysocket/
total 20
drwxr-xr-x  2 mollysocket mollysocket  4096 Nov 27 13:12 .
drwxr-xr-x 27 root        root         4096 Nov  3 15:20 ..
-rw-r-----  1 mollysocket mollysocket 12288 Nov 27 13:12 mollysocket.db

In order to avoid confusion, the given path names in this example do refer to a custom setup on my own, it's not about the predefined Docker image discussed elsewhere.

[p1gp1g]

@Fr0d0Beutl1n

I recently installed the server, and had issues with the config (#11), because I specified a wrong database location (?). To be honest, I don't really know what exactly was the issue.

You were writing to a db in a non-persistent directory. That's how docker works. I've changed the working dir to avoid that : https://github.com/mollyim/mollysocket/commit/d6cbbaadb1e48de6dc9bd8ffc37325a3a05a6aa5

Note that mollysocket can't know that it writes on a non-persistent directory.

BTW, the conf is being rewritten

---

@fl0bo

I think your directory wasn't writable for the group the systemd service was running as.

---

I'm closing this issue, since it is not related to logging :)