Service file format

[SoftExpert]

Hello,

Simple question for a complex topic: since the number of parameters and their options are increasing, the service description files will become more complex and will look less intelligible.
Some options have very specific syntax, meaning that there are less chances to find out there syntactic highlighters, analyzers, validators and so on.

Could it be a good idea to switch to TOML 1.0 format instead ?

There is a parser (tomlc99, written in C99 and TOML 1.0 compliant), under MIT license, that can help with the low level parsing.

The service file could look similar to this:

[dinit]
name = "my_process"
description = "this is my example process"
version = "1.2.3"
enabled = true
# [ "process", "bgprocess", "scripted", "internal", "triggered" ]
type = "process"

[dinit.depends]
depends-on = [ "network.target" ]
depends-ms = [ "aaa" ]
waits-for = [ "ccc" ]
after = ""
before = ""
chain-to = ""

[dinit.depends.d]
depends-on = ["", "", ""]

[dinit.depends.ms]
depends-ms = ["", "", ""]

[dinit.depends.waits]
waits-for = ["", "", ""]

[dinit.process]
command = "`id -user`\\$environment_variable\\$[local-variable1]\\${system_variable}"
command-extra = 'a\b'
stop-command = ""
stop-command-extra = ""
working-dir = ""
pid-file = ""
# {none | signal-name}
term-signal = "none"
# {pipefd:fd-number | pipevar:env-var-name}
ready-notification = 'pipefd:5'

[dinit.process.socket]
socket-listen = "path"
socket-permission = 600
socket-uid = "1000"
socket-gid = "user"

[dinit.process.scheduling]
# ["yes", "true", "on-failure", "no", "false"]
restart = true
# smooth-recovery ["true", "false", "yes", "no"]
smooth-recovery = false
restart-delay = 1.2
restart-limit-interval = 123.45
restart-limit-count = 5
start-timeout = 30
stop-timeout = 30

[dinit.process.identity]
# identity
run-as = ""

[dinit.process.logging]
# {file | buffer | pipe | none}
log-type = "buffer"
logfile = "log-file-path"
logfile-permissions = 644
#{numeric-user-id | username}
logfile-uid = "1000"
# {numeric-group-id | group-name}
logfile-gid = "users"
log-buffer-size = 65535


[dinit.environment]
env-file = [""]

[dinit.environment.variables]
local-variable1="`id -user`"

[dinit.options]

Thank you for the great work already done, I'm really enjoying the serenity that comes with dinit !

[davmac314]

Hi,

I did at some stage consider some different "standard" formats for the service description files, including TOML (and YAML and one or two others). However, none really seemed satisfactory to me. I didn't want the command to be have to be specified as an "array" and so need quotes to passed through to Dinit so that it can do its own word-splitting on command lines, for example (I don't think there's an existing format that "naturally" does this). I also wanted to keep the punctuation needs minimal and leave open the possibility of metacommands (such as the recently implemented @include).

The current format is pretty good for what it does I think, with the one downside that it's a bespoke format. So, I'm not really interested at this stage on taking on the work to integrate a new format, introduce a new library dependency, and introduce backwards incompatibility which would be forced on the distributions that are already using Dinit, etc.

I hope you understand,
Davin

[SoftExpert]

Hi Davin,

It was just a thought and not at all criticism, apologies if it was perceived otherwise !
I also thought that since parameter parsing is complex, it probably takes a lot of time to test when introducing changes, so relying on an already tested and stable parser (which comes as source code) would shift the burden and liberate your time for the core of the project.

As a total beginner with dinit I felt a bit disoriented with the format of the parameters when creating my first service definition and I felt that a more "familiar" format would have been easier to assimilate.

Perhaps offering more concrete examples in the documentation would help with the "adoption" - one of the reasons being that people migrating from systemd (to name the one that should not be named, lol) or other init systems will miss the structure of the units and find it harder to understand and follow the logic of dinit.

What could help even more would be to create some sort of "generator" - a UI (or TUI) tool that will ask the right questions and produce a service definition file.

Another useful tool would be a service manager - either as a text console UI or as a full blown UI - that will show the hierarchy of the services and their status, and would allow to start, stop, enable, disable them.
A first step in this direction will be a diagram of dependencies of the services and of the different targets.

Other than that, I'm really impressed with the speed of dinit; I have even managed to launch services in the userspace at login in my KDE session.

Yesterday I received the update to v0.19 on my Artix and it was flawless !

Overall it has been a really pleasant experience so far, and I thank you for it !

Best regards,
SoftExpert

[davmac314]

No problem, it was not taken as criticism. However one of the key points I was trying to make (though I made it badly) is that doing anything on Dinit takes time, which I don't have a lot of, and when I do have time to work on Dinit I usually have a pretty good idea of what my priorities are. Some of the things you've suggested would be great, but implementing them would take quite a lot of time away from doing some of the fundamental improvements that really need to be done first.

Putting it another way - I don't have any shortage of ideas, what I do have shortage of is time. Someone else would probably have to step up to do the things you've suggested, and that's only likely to happen if they are things that they are personally interested in, because that's how open-source development works (unless bounties are offered etc).

Of course it's fine to discuss your ideas, I just want to make it clear that, in general, suggestions like this won't ever be implemented unless you implement them yourself, or you fund their development, or you luck out and someone else wants the same thing.