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 14-10-2023 07:17, Steve Litt wrote: > dng@??? said
on Fri, 13 Oct 2023 16:49:38 +0200 > >>>> daemon, options to run in foreground,
options to run >>>> in background, options to log, options for [...]

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: d404.nl]
 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 14-10-2023 07:17, Steve Litt wrote:
> dng@??? said on Fri, 13 Oct 2023 16:49:38 +0200
>
>>>> 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.
>> Why would you change the behavior of a existing init system?
> I don't understand the question, or perhaps I don't understand the
> context of the question.
>
>> 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.
> I'm not sure what the preceding paragraph means.
>
>> Besides S6 is implementing dependencies if I understand the
>> documentation correctly.
> True, but the discussion was about having a titofile that can be
> translated into several different init system init/run scripts.
>
> Thanks,
>
> SteveT
>
> Steve Litt
>
> Autumn 2023 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21

Sorry English is not my primary language, I will try to be more
specific. I was referring to the part /"So in the titofile 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."/. In my opinion this
would be the job of the init system and not part of a descriptive file.

One program which read a service file and generates a init script (and a
test script if you like) for most used init systems and ignores systemd
specific parts would cover 80% of the needs of a packager. Can be
written in something like python or any other interpreted language
because it will not be part of the init system self and speed is not
much of a concern.

I hope this is more understandable.

Grtz

Nick