Spam detection software, running on the system "lists",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview: On 13-10-2023 15:09, Steve Litt wrote: > (needs, provides,
> Those are kind of meaningless in runit although I'm pretty sure they're
> vital in systemd, sysvinit, and I think s6 if you do s6 the new w [...]


Content analysis details: (7.1 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.7 CK_HELO_DYNAMIC_SPLIT_IP Relay HELO'd using suspicious hostname
                            (Split IP)
 0.0 TVD_RCVD_IP            Message was received from an IP address
 0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                            blocked.  See
                            http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                             for more information.
                            [URIs: troubleshooters.com]
 0.0 RCVD_IN_SORBS_DUL      RBL: SORBS: sent directly from dynamic IP
                            address
                            [82.168.208.164 listed in dnsbl.sorbs.net]
 0.0 HTML_MESSAGE           BODY: HTML included in message
 3.9 HELO_DYNAMIC_IPADDR2   Relay HELO'd using suspicious hostname (IP
                            addr 2)
 2.5 NO_FM_NAME_IP_HOSTN    No From name + hostname using IP address

The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam. If you wish to view
it, it may be safer to save it to a file and open it with an editor.

On 13-10-2023 15:09, Steve Litt wrote:
> (needs, provides,
> Those are kind of meaningless in runit although I'm pretty sure they're
> vital in systemd, sysvinit, and I think s6 if you do s6 the new way. So
> for runit and old-school s6, "needs" and that systemd "startafter" and
> "startbefore" stuff boil down to "what needs to be running before this
> daemon starts?" And unlike systemd and the new s6, the already started
> dependency daemon hasn't set a flag saying it's running, nor has it
> (for sysvinit) backgrounded itself to say it's running. Instead, in
> runit you test for the dependency being running. For instance, if the
> dependency is the network, you can ping 8.8.8.8 and if it fails, exit 1
> and let runit try again in a second or five or whatever.
>
> This "test" method sounds like a kludge, but it's actually better
> because it tests what you need, not what the daemon said when it
> supposedly became effective. If you need MariaDB running, you can test
> with a read for a table you know is in a known database, instead of
> hoping systemd's right about saying that it's running. So in the tito
> file you need test scripts for each dependency, and each test script is
> probably about 1 to 3 lines, but they are code, not key value pairs.
>
> Another situation is where you must shut down one daemon before
> shutting down another. I think the usual example of this is you must
> shut down your database before shutting down nfs. Any such relationship
> must be in the tito file.
>
>> daemon, options to run in foreground, options to run
>> in background, options to log, options for pidfile, run as user, run
>> as group,
> I think you've pretty much covered it, unless you want it to enable one
> to create a unit file from the tito file, but that decision would be
> political and strategic, seeing as the unit files will always be
> available until systemd goes away.
>
> By the way, I'm pretty sure that if each "must start A before starting
> B" and each "must kill C before killing D" is listed in the tito file,
> sysvinit S and K numbers can be calculated. I think the make program
> might be helpful in doing this.
>
> SteveT
>
> Steve Litt
>
> Autumn 2023 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21

Why would you change the behavior of a existing init system? One piece
of software to interpret a service file and create the correct init
script or whatever that init system needs and covers 80% of the work for
a packager would already be a game changer.

Besides S6 is implementing dependencies if I understand the
documentation correctly.

Grtz

Nick