I would suggest we step away from including "services" in "boot".
To "boot" a system into a functional one is one thing.
To start "services" at (or after that) is another.
Modularity is good.
I prefer "boot" to be scripted since it then can be adjusted more
easily if needed for any actual system and situation. Though boot
scripting should only deal with system startup and system shutdown.
Service start/stop/... rather belongs to "services management".
hmm not sure that this thought brings things forward though :)
Ralph.
On Sat, Dec 30, 2023 at 11:12:24PM +0100, tito via Dng wrote:
> On Sat, 30 Dec 2023 22:33:38 +0100
> tito via Dng <dng@???> wrote:
>
> > On Sat, 30 Dec 2023 07:25:08 -0300
> > altoid via Dng <dng@???> wrote:
> >
> > > Hello:
> > >
> > > On 30 Dec 2023 at 5:01, Lars Noodén via Dng wrote:
> > >
> > > > ... IBM picking up (or being tricked into sponsoring) the
> > > > decommoditization attack ...
> > >
> > > IBM?
> > > Tricked?
> > > Right ...
> > >
> > > Just like Mike Lynch tricked HP into dropping an absurd 8.0 billion
> > > for Autonomy to then write off a huge chunk of it?
> > >
> > > 8^D !!!!!!!!!!
> > >
> > > > ... this new scale at least some minor coordination ...
> > > I beg to differ.
> > >
> > > Not at all 'minor'.
> > >
> > > In my opinion, what is needed is Devuan ie: whoever runs the show, to
> > > clearly define and set a course of action.
> > >
> > > And then see that it is followed, to the letter.
> > >
> > > To get the idea across in a more graphic manner:
> > >
> > > ----------------------------------------------------------------------
> > > Devuan is *not* a ship safely moored at harbour.
> > >
> > > It is a ship with a skeleton crew, barely any fuel in its tanks,
> > > sailing too close to a reef infested coast with a pack of enemy
> > > submarines paitiently waiting for it to move into open sea.
> > >
> > > It is in dire need of accurate charts and officers (captain/1st
> > > mate/navigator/engineer) to whom the crew and passengers can look up
> > > and follow.
> > > ----------------------------------------------------------------------
> > >
> > > > ... many who can contribute with sysvinit scripts ...
> > > Linux has tens of thousands of very capable users, the great majority
> > > highly qualified.
> > >
> > > There was a post here recently about a script or set of scripts that
> > > would translate/interpret (?) systemd 'whatevers' to sysvinit scripts
> > > in a straightforward manner.
> > >
> > > If so, that would be *the*' solution.
> > > If not, I'd say that is exactly what Devuan needs.
> > >
> > > ie:
> > > systemd 'whatever' in ----> sysvinit scripts out.
> > >
> > > It must be an *integral and systematic* solution.
> >
> > Hi,
> > I fully agree with you and from day one of using Devuan
> > I'm thinking about what this integral and systematic solution could be.
> > One proposal was common service description files
> > for all alternative init systems to share the burden
> > of maintaining them, there was some interest but
> > this proposal didn't gain the needed traction.
> > So thinking about what that solution could be
> > I have many questions in my head but few answers.
> >
> > If I understand It correctly one part of init scripts
> > are included in the initscripts package:
> >
> > /etc/init.d/bootlogs
> > /etc/init.d/bootmisc.sh
> > /etc/init.d/brightness
> > /etc/init.d/checkfs.sh
> > /etc/init.d/checkroot-bootclean.sh
> > /etc/init.d/checkroot.sh
> > /etc/init.d/halt
> > /etc/init.d/hostname.sh
> > /etc/init.d/killprocs
> > /etc/init.d/mount-configfs
> > /etc/init.d/mountall-bootclean.sh
> > /etc/init.d/mountall.sh
> > /etc/init.d/mountdevsubfs.sh
> > /etc/init.d/mountkernfs.sh
> > /etc/init.d/mountnfs-bootclean.sh
> > /etc/init.d/mountnfs.sh
> > /etc/init.d/rc.local
> > /etc/init.d/reboot
> > /etc/init.d/rmnologin
> > /etc/init.d/sendsigs
> > /etc/init.d/single
> > /etc/init.d/umountfs
> > /etc/init.d/umountnfs.sh
> > /etc/init.d/umountroot
> > /etc/init.d/urandom
> >
> > and some (let's call it infrastructural) part in sysv-rc
> >
> > /.
> > /etc
> > /etc/init.d
> > /etc/rc0.d
> > /etc/rc1.d
> > /etc/rc2.d
> > /etc/rc3.d
> > /etc/rc4.d
> > /etc/rc5.d
> > /etc/rc6.d
> > /etc/rcS.d
> > /lib
> > /lib/init
> > /lib/init/rc
> > /lib/init/rcS
> > /etc/init.d/rc
> > /etc/init.d/rcS
> >
> > So a first question is: are they enough to boot a system?
> > At a first glance I don't think so (maybe a very simple system)
> > and looking at their dependencies just a few other packages
> > are sucked in.
> > This minimal sysvinit infrastructure is the one we have
> > direct control over, with the addition of orphan-sysvinit-scripts
> > which is a great temporary solution to keep our systems
> > running but if it is true that there were some 1000+
> > packages shipping an init script it will not scale up easily.
> > So the only viable solution to me seems to be to use
> > systemd's own force, in other words we need to find
> > a way to leverage their .service files as a base of our init system.
> > I think that translation like the one proposed
> > by some scripts to convert .service files to initscripts
> > (on the fly (dangerous!) or before (needs forking of packages?))
> > is not a future proof solution as we will always lag behind
> > to fix breakages created by new features added by the systemd
> > developers, so in the end only using the service files
> > shipped directly seems the way to me.
> > What looks as a great idea at first shows lots of problems
> > when I start to think how this could be implemented
> > ( maybe just due to my ignorance or partial knowledge):
> >
> > 1) the .service files are mixed with other
> > systemd files (.target.wants etc.) and in several directories
> > how to the detect the ones we need?
> > blacklist, whitelist? not a KISS solution.....
> > maybe by name (skip same name as initscripts?)
> > Are there other criteria that could be used?
> >
> > 1a) do .wants.target easily align with initscript's headers?
> >
> > 2) cron.d files are transformed in .timer files so they also need
> > to be fixed
> >
> > 3) /etc/default files are still used but I recall that they will vanish
> > in the future
> >
> > 4) systemd runs all services in foreground so the Exec lines
> > in service files miss the needed command line options to
> > daemonize a service so all services need to be forked (?)
> > in the background by our solution
> >
> > 5) we need to take care of pid files (am I right?)
> >
> > 6) we need to take care of log files (am I right?)
> >
> > Sometimes I think we are just resisting progress....
> >
> > Just my 2 cents.
> >
> > Ciao,
> > Tito
> >
> > > > ... getting onboard with that aspect of the development process
> > > ...
> > > Needs what I mention above:
> > >
> > > "... accurate charts and officers (captain/1st mate/navigator) to
> > > whom the crew can look up an follow."
> > >
> > > Thanks for your input.
> > >
> > > Have a Happy New Year.
> > >
> > > Best,
> > >
> > > A.
>
> One rather weird and still untested idea I was thinking about to boot
> a system with mixed initscripts and service files was:
>
> 1) answer most of the previous questions
>
> 2) use the logic in service files to initscritp translator
> a) detect the service files we need to translate at boot
> b) mount an overlay fs on /etc/init.d/ (as it could be on a read only fs
> at boot time or always ro)
> c) convert the previously enumerated service files
> d) copy them to the /etc/init.d/ overlay fs
> e) run insserv to create a boot order
> f) boot the system
>
> Could this work? I doubt it.....
>
> Unresolved problems:
> 1) how to keep track of services enabled disabled by the user
> 2) what to do when new packages are installed:
> a) hook the converter to dpkg
> b) I really don't know....
>
> The later in the night the "weirder" the ideas...
>
> Ciao,
> Tito
>
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
::
Re: [DNG] There seems to be some st…
