So, unless one is writing software that directly interacts with the init system ...
If you are writing code that will run as one or more server processes, you will likely also want to provide scripts/config to manage those processes. For systemd, that could be service definition files.
On 3/13/24 22:55, Lawrence D'Oliveiro wrote:
If you are writing code that will run as one or more server processes,
you will likely also want to provide scripts/config to manage those
processes. For systemd, that could be service definition files.
... to my understanding, that might be better managed by distribution /
OS maintainers, rather than developers.
I was thinking more about code being written for in-house use by
particular customers--I should have made that clear.
However, what you say is true for open-source code that is being
published. Though I suspect it would still be helpful to provide some info about how interlocking processes are supposed to fit together, and
systemd .service files could serve as a lingua franca for that, even for distros that don’t use systemd. The declarative systemd unit-file syntax should be easier to translate to other forms than perhaps going the other way.
If you are, for example, a maintainer for devuan (a systemd less debian)
I imagine you will appreciate those being there for documentation rather
than not.
After they’ve recovered from an apoplectic fit at having to deal with the kind of systemd-related stuff they specifically set up Devuan to get away from.
The declarative systemd unit-file syntax should be easier to translate to other forms than perhaps going the other way.
The declarative systemd unit-file syntax should be easier to translate
to other forms than perhaps going the other way.
I can't see how non portable unit files backed by c code are more
helpful than atleast more portable scripts with less c per command to interpret, to be honest.
Scripts need an interpreter. Being Turing-complete, in general information
cannot be extracted from them except by running them. Unit files have a
fixed vocabulary of keyword entries, which can be easily enumerated,
looked up, whatever. That’s what’s meant by “declarative”.
On Tue, 19 Mar 2024 22:29:50 -0000 (UTC), Lawrence D'Oliveiro wrote:
Scripts need an interpreter. Being Turing-complete, in general
information cannot be extracted from them except by running them. Unit
files have a fixed vocabulary of keyword entries, which can be easily
enumerated, looked up, whatever. That’s what’s meant by “declarative”.
Sorry but that is nonsense. The code behind those unit files is a lot of disparate C.
In my experience init scripts are made entirely of simple commands that
are documented and editable, piece by piece.
That’s purely down to how you choose to implement it--it has nothing to do
with the format--and meaning--of those unit files themselves. Nobody can
stop you from writing bad code to parse a good format.
In my experience init scripts are made entirely of simple commands that
are documented and editable, piece by piece.
sysvinit scripts are full of boilerplate sections that users regularly
copy and paste from one to the next, without thinking too much about what >they do.
I'm skeptical of the flexibility being lost.
SysV init scripts are quite horrid but OpenBSDs rc system is far more
transparent, flexible and nicer to work with than systemd.
So now you have moved on to inventing issues in search of
justifications.
One of which is concurrent startup of which there is no need at all and
actually causes a number of problems...
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 360 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 129:20:02 |
| Calls: | 7,686 |
| Files: | 12,828 |
| Messages: | 5,711,155 |