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.
systemd service definitions let you state dependencies between services. Furthermore, it separates them into ordering dependencies versus
requirement dependencies.
E.g. an application that uses a MariaDB database requires MariaDB to be running before it can be started (ordering + requirement dependency).
An application that can (but doesn’t have to) make use of network services should be started after the network stack is up (ordering dependency).
I’m not aware of any other service-management system that provides this level of control.
You should define a depend function for the service so that openrc-run
will start and stop it in the right order in relation to other
services. As it's a function it can be very flexible, see the example
below. Here is a list of the functions you can use in a depend
function. You simply pass the names of the services you want to add to
that dependency type to the function, or prefix the names with ! to
remove them from the dependencies.
need
The service will attempt to start any services it needs regardless of
whether they have been added to the runlevel. It will refuse to start
until all services it needs have started, and it will refuse to stop
until all services that need it have stopped.
use
The service will attempt to start any services it uses that have been
added to the runlevel.
want
The service will attempt to start any services it wants, regardless of whether they have been added to the runlevel.
after
The service will start after these services and stop before these services.
before
The service will start before these services and stop
after these services.
provide
The service provides this virtual service. For example, named provides
dns. Note that it is not legal to have a virtual and real service
with the same name. If you do this, you will receive an error message,
and you must rename either the real or virtual service.
The declarative systemd unit-file syntax should be easier to translate
to other forms than perhaps going the other way.
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: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,030 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 41:08:08 |
| Calls: | 13,347 |
| Calls today: | 1 |
| Files: | 186,574 |
| D/L today: |
3,893 files (880M bytes) |
| Messages: | 3,358,100 |