Re: [DNG] startup scripts (was dng@lists.dyne.org)

[Didier Kryn]

Le 17/07/2015 21:38, ibid...@gmail.com a écrit :

KatolaZ:
>

> > > >You guys talk about supporting half a dozen init systems like it
> > > >was similar to providing half a dozen different editors, which
> > > >believe me is not quite the case.

This is true, because supporting an init system requires every package
that provides a daemon to work with that init system's boot scripts.
And you can't really define a single format for boot scripts, because
that's a fundamental part of how an init system works.


To be clear, let's concentrate on the part of init which is the 
concern: the daemon-launcher.


I don't think things are as complex as is suggested by the comments 
I have read up to now.


There are two categories of launchers: supervisors and 
non-supervisors. Similarly, I think two scripts only are needed for 
every daemon: one for launching without supervision, alla sysv-init and 
one for launching from a supervisor. Just two, not one per every 
launcher/supervisor.


 Further more, a method could be agreed on to tell the script if 
the daemon is going to be supervised or not, and we would then need only 
one script for all cases.


For example, providing "supervised-start" and "supervised-reload" 
in addition to the other cases could do the job. For safety, the scripts 
could check a file which tells them which supervisor is calling them.


What do you think?
Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] many packages VS. one package, was: Re: dng@lists.dyne.org

[Didier Kryn]

Le 18/07/2015 06:58, Peter Olson a écrit :

On July 17, 2015 at 11:38 PM Gregory Nowak  wrote:

On Fri, Jul 17, 2015 at 08:16:06PM -0700, James Powell wrote:

Some might ask, Why not just one simple package?

That's where Devuan can bring packaging sanity in as well.

megabyte for example. Granted, this may not be the best example, but
it does illustrate I think the reasons for smaller multiple packages
VS. one big package.

NOT DEVUAN 1.0 ...

I agree.  Debian accommodates the lean server install with just the binaries
and also allows selective documentation install and development and debugging
installs.

My principal complaint is with 'apt cache search' which is a low level tool that
doesn't expose any of the structure of the repository.

Many times I want to install a package I know the name of (approximately) and I
have to read or grep through hundreds of search results for related packages
that have nothing to do with installing (or even identifying by name) the
package I want, not to mention how complete the doc/devel/debug environment I
might like.



Peter Olson
___



Maybe I didn't understand what you mean, but did you try apt-file?

apt-get install apt-file
apt-file update
apt-file search /usr/bin/whatever

Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] startup scripts (was dng@lists.dyne.org)

[Laurent Bercot]

On 18/07/2015 09:52, Didier Kryn wrote:

There are two categories of launchers: supervisors and
non-supervisors. Similarly, I think two scripts only are needed for
every daemon: one for launching without supervision, alla sysv-init
and one for launching from a supervisor. Just two, not one per every
launcher/supervisor.

Further more, a method could be agreed on to tell the script if the
daemon is going to be supervised or not, and we would then need only
one script for all cases.

For example, providing "supervised-start" and "supervised-reload" in
addition to the other cases could do the job. For safety, the scripts
could check a file which tells them which supervisor is calling
them.

What do you think?


 It's a bit more complicated than that.

 Supervision suites don't only take a script, they take a whole
"service directory" where the configuration is stored. Which is a
good thing, because it involves not only the daemon-starting script,
but cleanup procedures, readiness notification procedures, and other
details on how to properly supervise the daemon.

 The daemon-starting script itself is launched by the supervisor
without arguments, so you cannot call it as "foo supervised-start".
You could provide one unique script for every daemon that does just
what you suggest, but you would still have to provide a complete
service directory in addition to it.

 And the service directory isn't exactly the same depending on the
chosen supervision suite. daemontools, runit, s6, perp and nosh all
have subtly different options, so even if you have a common basis
and simple daemons can use the same service directory with several
supervision suites, when you get into advanced stuff such as
readiness notification,configuration details must be handled
differently.

 Believe me, providing sysv-rc compatibility when you're working on
a supervision suite is no small feat: the paradigm is very different,
and when you've had a taste of supervision, you realize how poor the
sysv-rc model is and how hard it is to contort yourself to fit into
the box. If it was easy, we would have provided compatibility packages
long ago, and supervision would already rule the world (with a gentle,
good hand).

--
 Laurent
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] dng@lists.dyne.org

[KatolaZ]

On Fri, Jul 17, 2015 at 08:16:06PM -0700, James Powell wrote:
> I never said it was set in stone.
> 
> All I suggested was if you install a package like SDL, then you install all 
> of SDL, not just part of it. This reduces overhead of making multiple 
> packages, simplifies the distribution, and makes the work of the package 
> maintainer easier.
> 

Again, I don't see why I should have ALL the stuff that comes with
sdl, including tons of header files, bindings for python, perl, ocaml,
libs with debugging symbols and so forth if my application just needs
libsdl1.2

HND

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] startup scripts (was dng@lists.dyne.org)

[Fred DC]

On 18/07/2015 10:49, Laurent Bercot wrote:
> 
>  Believe me, providing sysv-rc compatibility when you're working on
> a supervision suite is no small feat: the paradigm is very different,
> 
> . If it was easy, we would have provided compatibility packages
> long ago, and supervision would already rule the world (with a gentle,
> good hand).
> 

I am not saying that runit is better as s6 - all I want to point out is
that debian runit, until recently, intergrates fairly well with sysv-rc.

Yes, the supervised services do need their own service-framework with
their own scripts. For me (as a simple user) the hard nut to crack was
to write stubs and a script which during a debian-update translate the
inet-calls to sv-calls without insserv telling me to take a hike.

I succeded because I accepted the fact that I have the standard
lsb-sysv-scripts in /etc/init.d/ and that the underlying dpkg-system
does use these scripts.

I fully agree with Laurent's sentiments that it is not as simple...
IMHO, it is doeable to make it compatible against an init-system
wich is the required default by the package-manager - but without
an aggreed standard it will get out of hand.

my 2cents

Fred

BTW, and what about rcS, rc0 and rc6a complete re-write?
Naah... KISS... use what we got! Strictly my opinion.



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] startup scripts (was dng@lists.dyne.org)

[KatolaZ]

On Sat, Jul 18, 2015 at 09:52:18AM +0200, Didier Kryn wrote:

[cut]

> 
>  Further more, a method could be agreed on to tell the script if
> the daemon is going to be supervised or not, and we would then need
> only one script for all cases.
> 
> For example, providing "supervised-start" and
> "supervised-reload" in addition to the other cases could do the job.
> For safety, the scripts could check a file which tells them which
> supervisor is calling them.
> 
> What do you think?
> Didier


How do you support init scripts for several init systems for all the
daemons that could be installed in a distro like Devuan? Who should do
this work? Who should keep things updated and synchronised to allow
the whole process to be neat and clean? Guys, if one apt-get installs
--force-yes the default editor, and things go wrong, it's not a big
issue. If we do the same on init, it's back to dice
rolling... (cit. moria).

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] startup scripts (was dng@lists.dyne.org)

[Laurent Bercot]

On 18/07/2015 12:42, Fred DC wrote:

I am not saying that runit is better as s6 - all I want to point out is
that debian runit, until recently, intergrates fairly well with sysv-rc.


 The reason why it does is that it compromises on supervision. I don't
know how debian runit is packaged, but I'm willing to bet that in this
model, for instance, udevd is not supervised by runsv. See the first FAQ
entry at http://skarnet.org/software/s6-linux-init/quickstart.html for
details.



Yes, the supervised services do need their own service-framework with
their own scripts. For me (as a simple user) the hard nut to crack was
to write stubs and a script which during a debian-update translate the
inet-calls to sv-calls without insserv telling me to take a hike.

I succeded because I accepted the fact that I have the standard
lsb-sysv-scripts in /etc/init.d/ and that the underlying dpkg-system
does use these scripts.


 I'm currently working on a service manager for s6 that can ease the
transition between a sysv-rc style and a supervision style, i.e. it can
use the sysv-rc scripts at first, and switch to a supervision style
service by service when package maintainers start supporting it. It
still doesn't make things easy, but I believe it makes the support
envisionable for a distribution, because the workload does not have
to be done all at once - it can be spread over time.



BTW, and what about rcS, rc0 and rc6a complete re-write?


 That's my ultimate goal, but it's obviously not feasible without a
gradual and smooth transition plan, which I'm elaborating now.



Naah... KISS... use what we got! Strictly my opinion.


 KISS all right, but sysv-rc is not SS, and most importantly, it's
not correct. "Use what we got" is a good strategy to organize work
and focus on the urgent things first, but at some point, when
"what we got" is insufficient, it needs to be addressed. Take your
time, and I'll be there when distributions are ready to tackle the
issue. :)

--
 Laurent

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] startup scripts (was dng@lists.dyne.org)

[Didier Kryn]

Le 18/07/2015 12:43, KatolaZ a écrit :

On Sat, Jul 18, 2015 at 09:52:18AM +0200, Didier Kryn wrote:

[cut]


  Further more, a method could be agreed on to tell the script if
the daemon is going to be supervised or not, and we would then need
only one script for all cases.

 For example, providing "supervised-start" and
"supervised-reload" in addition to the other cases could do the job.
For safety, the scripts could check a file which tells them which
supervisor is calling them.

 What do you think?
 Didier


How do you support init scripts for several init systems for all the
daemons that could be installed in a distro like Devuan? Who should do
this work? Who should keep things updated and synchronised to allow
the whole process to be neat and clean? Guys, if one apt-get installs
--force-yes the default editor, and things go wrong, it's not a big
issue. If we do the same on init, it's back to dice
rolling... (cit. moria).

My2Cents

KatolaZ



Dear KatolaZ,

I probably didn't express things properly. My idea was precisely a 
way to workaround the issue you say. The idea was to modify the existing 
sysv-init scripts so that, while remaining 100% compatible with 
sysv-init, they become also usable by supervisors. If it proved possible 
and a standard method was agreed on, then I am convinced the authors of 
these daemons would do it upstream.


Alas, supervision experts don't think it is possible :-(

Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] dng@lists.dyne.org

[Hendrik Boom]

On Sat, Jul 18, 2015 at 11:37:26AM +0100, KatolaZ wrote:
> On Fri, Jul 17, 2015 at 08:16:06PM -0700, James Powell wrote:
> > I never said it was set in stone.
> > 
> > All I suggested was if you install a package like SDL, then you install all 
> > of SDL, not just part of it. This reduces overhead of making multiple 
> > packages, simplifies the distribution, and makes the work of the package 
> > maintainer easier.
> > 
> 
> Again, I don't see why I should have ALL the stuff that comes with
> sdl, including tons of header files, bindings for python, perl, ocaml,
> libs with debugging symbols and so forth if my application just needs
> libsdl1.2

Agree.

Should there be an easy way to find all those other things if one only knows 
one is using libsdl1.2? 

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] startup scripts (was dng@lists.dyne.org)

[James Powell]

The boot scripts can be somewhat universal, but not always. Runit and s6 
require some very special and specific service and boot scripts for init, plus 
a lot of custom service scripts. These are what need the most attention. The 
init stage scripts are going to be unique to each init system as well.

Stage 1 in Runit is the one shot primary system startup sequences, while in s6, 
stage 1 is the init system script itself.

These can be translated between each as needed, but each init should be made to 
have it's own stuff. In the long term, the scripts will not need much 
maintenance if they are done correctly.

Sent from my Windows Phone

From: Didier Kryn
Sent: ‎7/‎18/‎2015 6:44 AM
To: dng@lists.dyne.org
Subject: Re: [DNG] startup scripts (was dng@lists.dyne.org)

Le 18/07/2015 12:43, KatolaZ a écrit :
> On Sat, Jul 18, 2015 at 09:52:18AM +0200, Didier Kryn wrote:
>
> [cut]
>
>>   Further more, a method could be agreed on to tell the script if
>> the daemon is going to be supervised or not, and we would then need
>> only one script for all cases.
>>
>>  For example, providing "supervised-start" and
>> "supervised-reload" in addition to the other cases could do the job.
>> For safety, the scripts could check a file which tells them which
>> supervisor is calling them.
>>
>>  What do you think?
>>  Didier
>
> How do you support init scripts for several init systems for all the
> daemons that could be installed in a distro like Devuan? Who should do
> this work? Who should keep things updated and synchronised to allow
> the whole process to be neat and clean? Guys, if one apt-get installs
> --force-yes the default editor, and things go wrong, it's not a big
> issue. If we do the same on init, it's back to dice
> rolling... (cit. moria).
>
> My2Cents
>
> KatolaZ
>

 Dear KatolaZ,

 I probably didn't express things properly. My idea was precisely a
way to workaround the issue you say. The idea was to modify the existing
sysv-init scripts so that, while remaining 100% compatible with
sysv-init, they become also usable by supervisors. If it proved possible
and a standard method was agreed on, then I am convinced the authors of
these daemons would do it upstream.

 Alas, supervision experts don't think it is possible :-(

 Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] sysvinit vs sysvinit-core

[Anto]

Hello everybody,

When I tried to upgrade the packages on my PC to the ones from Devuan 
jessie repository just now, the following ones got held back due to my 
pinning preference.


root@hp8530w:~# dpkg --list accountsservice acpi-fakekey initscripts 
libaccountsservice0 sysvinit sysvinit-utils util-linux

Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version   Architecture  Description
+++-=-=-=-
ii  accountsservice 0.6.21-8  amd64 
query and manipulate user account information
ii  acpi-fakekey 0.140-5+deb7u3amd64 
tool to generate fake key events
ii  initscripts 2.88dsf-41+deb7u1 amd64 
scripts for initializing and shutting down the system
ii  libaccountsservice0 0.6.21-8  
amd64 query and manipulate user account information 
- shared libraries
ii  sysvinit 2.88dsf-41+deb7u1 amd64 
System-V-like init utilities
ii  sysvinit-utils 2.88dsf-41+deb7u1 amd64 
System-V-like utilities
ii  util-linux 2.25.2-4.1+devuan1amd64 
Miscellaneous system utilities

root@hp8530w:~#

As above, I am still using sysvinit from Debian wheezy. And I held 
util-linux to the above version. As far as I remember, I got problems 
using util-linux higher than that version. I forgot the exact the problems.


What I am wondering is that, why Devuan is using sysvinit-core instead 
of sysvinit? Could we not just bring forward sysvinit from Debian wheezy 
for Devuan jessie? As far as I understood, sysvinit-core was introduced 
as the workaround to use SysV init in Debian jessie instead of the 
default init (which name should not be mentioned). If my understanding 
is wrong, is that because of the changes on util-linux? If not, what are 
technical reasons behind that, a part from staying very close to Debian 
jessie?


Cheers,

Anto

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] sysvinit vs sysvinit-core

[Adam Borowski]

On Sat, Jul 18, 2015 at 11:35:20PM +0200, Anto wrote:
> As above, I am still using sysvinit from Debian wheezy. And I held
> util-linux to the above version. As far as I remember, I got problems using
> util-linux higher than that version. I forgot the exact the problems.
> 
> What I am wondering is that, why Devuan is using sysvinit-core instead of
> sysvinit? Could we not just bring forward sysvinit from Debian wheezy for
> Devuan jessie? As far as I understood, sysvinit-core was introduced as the
> workaround to use SysV init in Debian jessie instead of the default init
> (which name should not be mentioned). If my understanding is wrong, is that
> because of the changes on util-linux? If not, what are technical reasons
> behind that, a part from staying very close to Debian jessie?

The reason for the rename is that, with sysvinit/wheezy being essential,
there was no way to install an alternate init system as default.  In jessie,
the essential package is "init" instead, which lists supported init systems,
them being systemd-sysv, sysvinit-core and upstart (openrc replaces sysv-rc
but not sysvinit).

-- 
⢎⣉⠂⠠⠤⡀⣄⠤⡀⠠⡅⠀⠤⡧⠄⡄⠀⡄⠀⠀⠀⠠⡅⠀⡠⠤⠄⠀⠀⠀⢴⠍⠀⡠⠤⡀⣄⠤⡀⠀⠀⠀⠤⡧⠄⣇⠤⡀⡠⠤⡀⠀⠀⠀⡄⠀⡄⡠⠤⡀⠠⠤⡀⡇⡠⠄⠀⠀⠀
⠢⠤⠃⠪⠭⠇⠇⠀⠇⠀⠣⠀⠀⠣⠄⠨⠭⠃⠣⠀⠬⠭⠂⠀⠀⠀⠸⠀⠀⠣⠤⠃⠇⠀⠀⠣⠄⠇⠀⠇⠫⠭⠁⠀⠀⠀⠣⠣⠃⠫⠭⠁⠪⠭⠇⠏⠢⠄⠀⠄⠀
(https://github.com/kilobyte/braillefont for this hack)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng