SQLite Forum

How to start a program that use SQLITE with SYSTEMD ?

How to start a program that use SQLITE with SYSTEMD ?

(1) By anonymous on 2022-01-26 03:47:11 [link] [source]

How to start a program that use SQLITE with SYSTEMD ?

I have a program use Sqlite3, and now need to use systemd

ExecStart=/usr/local/mine/server -c /usr/local/mine/server.json > /var/log/apiserver.log
ExecStart=sudo /bin/sh -c '/usr/local/mine/server -c /usr/local/mine/server.json'
ExecStart=/bin/sh -c '/usr/local/mine/server -c /usr/local/mine/server.json > /var/log/server.log 2>&1'
but the program alweays report error:
attempt to write a readonly database
if I execute in cmd, that is ok
/usr/local/mine/server -c /usr/local/mine/server.json
I think that is cause by user permission, So I tried adding a user
The part of /usr/lib/systemd/system/apiserver.service:
ExecStart=/usr/local/mine/server -c /usr/local/mine/server.json
The directory structure :
drwxr-xr-x. 3 server server    121 Jan 26 11:24 server
drwxrwxrwx. 2 server server     21 Jan 26 11:24 serverProgram
drwxrwxrwx. 2 server server     21 Jan 26 11:24 db
-rwxrwxrwx. 1 server server 20480 Jan 26 11:24 task.db
But not work. So, how to start a program that use SQLITE with SYSTEMD ? It's been bothering me for weeks.

(2.1) By Warren Young (wyoung) on 2022-01-26 04:39:36 edited from 2.0 in reply to 1 [link] [source]

I'm going to guess that this is RHEL or a derivative, where the problem isn't systemd but SELinux. In RHEL8, they tightened down a lot of the rules on use of directories to properly enforce the FHS rules.

The bottom line is that /usr/local isn't where user data is supposed to go, so SELinux was tuned to detect such attempts and flag them as likely bugs or security sandbox escape attempts.

The usual location for server databases is under /var somewhere. If this is used by only a single service, then /var/mine/db might be sensible.

Read up on FHS for more ideas.

Realize that you're way out past the topic for this forum. I responded only because it comes up in your use of SQLite, but SQLite can do nothing about these matters, nor should it try. Put your DB where your OS expects to allow background services to write files, and your symptom will go away.

(3) By anonymous on 2022-01-26 09:37:06 in reply to 2.1 [link] [source]

Thank you for your response.Your answer inspired me, and after more than ten minutes, I found the cause of the problem. That's the key:

I always thought ProtectSystem:false(def)/true/full just limit access to /boot & /etc, it actually contains /usr. I delete this configuration and it ok. OR If I keep ProtectSystem:full and place the database in the /opt directory, it will also be ok

(4) By Ryan Smith (cuz) on 2022-01-26 10:45:16 in reply to 3 [link] [source]

I've seen a lot of people (even long-time Linux users) mis-attribute the /usr folder as a "User" folder, which is why thinking it will not be under the umbrella of system protection is prevalent, but in fact it is very much a Linux system folder - if memory serves, "usr" = "Unix System Resource", which is why Warren said that it is really not the correct folder for these kinds of files.

While /usr is ok to add setup/static info into, config info should reside in /etc and any variable-data/DBs/logs/scratch-pad stuff should really be in /tmp and /var (variable-data-size folder I think).

These rules are not set in stone (at least not on all distros), but it will make it easier for your files to work as expected if you follow these preferences.

(5) By Warren Young (wyoung) on 2022-01-26 10:59:50 in reply to 4 [link] [source]

a lot of people…mis-attribute the /usr folder as a "User" folder

But it was. See the primary source linked from footnote 1.

"usr" = "Unix System Resource"

Sorry, but that's an ahistoric backronym.

it is really not the correct folder for these kinds of files.

It was back when /usr also contained the users' home directories. Thus the existence /usr/spool/mail on my UNIX V7 virtual machine.

However, rules change over time, many times, not just from RHEL 7 to RHEL 8.

(6.1) By Ryan Smith (cuz) on 2022-01-26 11:21:48 edited from 6.0 in reply to 5 [link] [source]

The rules/roles do indeed change over time.

Not sure stackexchange is an authority on any matter, but a cursory simple search of the authoritative sources basically all claim to be non-authoritative, thus I stand corrected on the name (I did say "I think"). It seems "User System Resources" is the prevailing identity, though you can find many views out there, but the sentiment remains, it is not for variable data, it is for typically User-side read-only System Resources (at least in modern times).

For more clarity, in case of interest - This from the Linux Document Project: tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html

And the Wikipedia on Folder Hierarchy: en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

(7.1) By Warren Young (wyoung) on 2022-01-26 11:49:20 edited from 7.0 in reply to 6.0 [link] [source]

Not sure stackexchange is an authority on any matter

I wrote that answer, and I pointed you to it so I don't have to rewrite that long answer here. I then took special care to point you to the SVR3.2 manual link, which I should think is an authoritative source on UNIX System V Release 3.2. If you don't believe AT&T on such matters, I don't know what you'll accept as authoritative.

If you're still feeling "right" about this, find me a first-party AT&T or BSD reference manual using the phrase "User System Resources". I've just searched my local archive of historical UNIX manuals, and I can't find one.

Since my collection is merely large, not comprehensive, I then tried to find that phrase with a full-text search on archive.org. Excepting either irrelevancies (e.g. something on Windows's GDI library) or repetitions of the TLDP document you linked to, I came up empty.

More, I was a Unix user at the time, and I assure you, we never used that backronym expansion. Until SVR4, /usr was the place where the users' files lived, as opposed to the system files. The first time I heard it used was probably in the mid to late 1990s, after a quarter century of Unix's history had already passed.

it is not for variable data

That is one of the many changes in SVR4, where /var was born.

The thing is, that change was made some 18 years into a history of such files properly living in /usr. As we have agreed, rules change.

This from the Linux Document Project:

Yes, that doc supports my contention: it's a backronym.

I'm not telling you that people don't use it. I'm telling you that it isn't what Ken Thompson and Dennis Ritchie had in mind when they named it /usr.

(8) By Ryan Smith (cuz) on 2022-01-26 12:23:34 in reply to 7.1 [source]

Warren, I'm sorry, that is the longest disseration defending a viewpoint to which I agreed to be wrong in the previous post already - what more do you want me to say? "I profusely apologize for being so very wrong master..."?

Most of my post (and certainly the links) was about the latest intended use for the folders, not the name.

So in the interest of avoiding any further backlash, let me be extremely clear about the statements I am making so that if there is any disagreement (which is welcome), that it should be on one of these points:

  • I was thinking wrong initially - /usr does not mean "Unix System Resource".
  • I believe Warren is correct - /usr was originally meant to be for any of the User's data, whatever the acronym (or sentiment) has become lately
  • Lately /usr is treated like a system folder, and although user-programs store some read-only types of data in there, the idea is to store any variable data (read-write stuff) in /tmp and /var rather (depending on longevity required).
  • This I believe is the "idea" on all distros I've used lately, but not enforced as it seems to be on some.
  • The OP is advised to "play ball" and not use /usr but indeed /var for the DB in question for best results universally across distros.