From Newsgroup: comp.lang.ada

On Wed, 13 Mar 2024 16:34:14 +0200, magardner2010 wrote:

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

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.

Not relevant to the whole overarching discussion, but to my
understanding, that might be better managed by distribution / OS
maintainers, rather than developers. When thinking about programs like daemons, or other similar pieces on a bigger system, with all the
variety of systems, init systems, and programs around, who best to do it
than the people that are ultimately orchestrating the whole ecosystem.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Mon, 18 Mar 2024 18:05:20 +0100, streaksu wrote:

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 3/18/24 20:56, Lawrence D'Oliveiro wrote:

I was thinking more about code being written for in-house use by
particular customers--I should have made that clear.

That is fair enough.

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.

I agree that it could be useful for a project to provide some barebones
units for that. 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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Tue, 19 Mar 2024 01:36:20 +0100, streaksu wrote:

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.

;)
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On 3/19/24 03:36, Lawrence D'Oliveiro wrote:

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.

Hahaha, that's fair enough.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

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.
--
Regards, Kc
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Tue, 19 Mar 2024 10:16:50 -0000 (UTC), Kevin Chadwick wrote:

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.

The unit files are in the classic .INI file format, which has been around
for decades. Code for parsing it should be readily available for every language in common use.

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”.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

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.

https://cvsweb.openbsd.org/src/etc/rc?rev=1.572&content-type=text/x-cvsweb-markup
--
Regards, Kc
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Wed, 20 Mar 2024 00:58:30 -0000 (UTC), Kevin Chadwick wrote:

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.

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

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.

I'm skeptical of the flexibility being lost. Perhaps it is possible but Ada
was specified competitively. Had Linux init been handled competitively then
I doubt they would have attempted and failed to move away from scripts
entirely. Likely openrc, runit or a new init system would have succeeded.

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.

SysV init scripts are quite horrid but OpenBSDs rc system is far more
transparent, flexible and nicer to work with than systemd.
--
Regards, Kc
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Wed, 20 Mar 2024 09:56:18 -0000 (UTC), Kevin Chadwick wrote:

I'm skeptical of the flexibility being lost.

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.

SysV init scripts are quite horrid but OpenBSDs rc system is far more
transparent, flexible and nicer to work with than systemd.

Does it have the equivalent of cgroups? These are a Linux feature (also
used by OpenRC) to ensure that, no matter how service processes may fork/ exec/terminate, the service manager can always track them down.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

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.

s6 supports both dependency management and readiness notification:

https://skarnet.org/software/s6/overview.html

s6 is the basis for 66, used for service management by Obarun, an
Arch-based distro:

https://wiki.obarun.org/doku.php?id=66intro

When i was running Void as my daily driver, i was using 66 for service management. (And not runit, which doesn't have true support for
dependencies; kludges are required.)

The s6 site has a page discussing "socket activation":

https://skarnet.org/software/s6/socket-activation.html

OpenRC supports integration with s6, and OpenRC itself provides
dependency management; cf. this excerpt from the openrc-run(8) man
page:

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.

There's also dinit, which i don't have any direct experience of; here's
a page by the author, comparing it to other systems:

https://github.com/davmac314/dinit/blob/master/doc/COMPARISON

(And of course, since cgroups is distinct from systemd, it can be
utilised by any init / supervision / service management system.)


Alexis.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

The declarative systemd unit-file syntax should be easier to translate
to other forms than perhaps going the other way.

s6 author Laurent Bercot has written a detailed document discussing
converting systemd unit files to an s6 context:

https://skarnet.org/software/s6/unit-conversion.html


Alexis.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

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...

It can also be accomplished very clearly and easily from a script.
--
Regards, Kc
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.ada

On Thu, 21 Mar 2024 01:50:05 -0000 (UTC), Kevin Chadwick wrote:

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...

Which I never mentioned.
--- Synchronet 3.20a-Linux NewsLink 1.114