Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/28/2014 01:10 AM, Tom H wrote:
>> Just to name a few:
>> - getting rid of the ugly LSB headers
> 
> Beauty is in the eye of the beholder. The "Short-Description" and
> "Description" LSB fields are useless, but I don't find Debian's LSB
> headers and Gentoo's squiggle-delimited stanzas any more beautiful or
> uglier than the other. What's important is that they do the job of
> allowing their respective rc routines order the startup - and they both
> do so.

IMO, it's better because less verbose. I just feel like the syntax is
better, also because it's integrated with the rest of the runscript
syntax, but that might be consider not so important, I can agree with
that to some degree.

>> - Dependency loop breaking system
> 
> What does this mean? That there are bugs in the dependency headers in
> the 1000-odd initscripts in Debian where openrc can work through the
> problem and insserv send you to the BTS?

This means that OpenRC goes through the "use" links (Should-Start, in
the LSB header format), and see if it needs to remove one of them in
order to break the dependency loop, and have a somehow satisfying boot
order. Note that this is only a feature available in a Debian specific
patch for the moment (not upstreamed yet). In Debian, that's located in
debian/patches/0020-dependency-loop-resolver.patch if you want to have a
look. I hope we can have this upstreamed soon before 0.13 is released.

> Is the mini-runscript style as experimental as Petter's 2-line sysv-rc
> script?

It's not. It's just that with OpenRC, you can decide to implement *or
not* the start() and stop() function. If you don't, then OpenRC will use
its internal function instead.

> Anyway, ifupdown and netifrc are pretty much equivalent.

And I don't see the point of having Debian switching to the Gentoo style
of things, so we agree! :)

> Finally, there's the issue of parallel boot. Debian has it in squeeze
> and wheezy with insserv. Has openrc fixed "rc_parallel"?

Yes. The dependency loop breaking system fixed it. What's remaining to
be fixed though, is the text output which is (very) ugly when the
parallel booting is activated.

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/531016d7.60...@debian.org

default init on non-Linux platforms

[Tom H]

On Thu, 20 Feb 2014 22:28:56 +0800, Thomas Goirand wrote:
> On 02/20/2014 09:02 PM, Tom H wrote:


Thanks for your answer and apologies for the delay in responding but my 
$dayjob's been keeping me very busy.




>> What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv
>> doesn't have?

You're being unfair to sysvinit+sysv-rc+insserv, although I have to 
admit that openrc is better and more cleanly designed from a user 
perspective because the combination of rc-update, rc-service, and 
rc-status is better than using service except to enable/disable a 
service where you have to use update-rc.d - and, if you want an output 
that's more human-friendly than "insserv -s", you have to install and 
use chkconfig.



> Just to name a few:
> - getting rid of the ugly LSB headers

Beauty is in the eye of the beholder. The "Short-Description" and 
"Description" LSB fields are useless, but I don't find Debian's LSB 
headers and Gentoo's squiggle-delimited stanzas any more beautiful or 
uglier than the other. What's important is that they do the job of 
allowing their respective rc routines order the startup - and they both 
do so.


As a sysadmin who works with different distributions, I find it 
quite frustrating that sysv-rc uses "Required-Start" and Should-Start", 
openrc "need" and "use", and systemd "Requires" and "Wants" to mean the 
same thing. Although it's not difficult to keep track of what's what, 
why should we have to?



> - cgroup supports to kill processes

IIRC, Patrick Lauer claimed to have written openrc's cgroup support in 
one afternoon.


And IIUC that support'll have to rewritten once the kernel's cgroup 
maintainer makes the changes that he's announced and non-systemd 
sysinits have to use Ubuntu's in-development cgroup manager (since 
systemd's cgroup manager's integrated into its pid 1).



> - rc_hotplug (a hotplugged service is one started by a dynamic dev
> manager when a matching hardware device is found).

AIUI openrc simply leverages udev to hotplug devices; but I'm only an 
occasional Gentoo user so I might have misundertood the process.



> - Checks if a daemon is really started by start-stop-daemon
> - Dependency loop breaking system

What does this mean? That there are bugs in the dependency headers in 
the 1000-odd initscripts in Debian where openrc can work through the 
problem and insserv send you to the BTS?



> - Named runlevels (I already talked about that)

I don't see this as a must-have feature. The default runlevels of 
sysinit, boot, default, single, reboot, shutdown where "sysinit" groups 
the services that are started in single-user mode and "boot" groups the 
services that are started by "default" and any user-defined runlevel but 
aren't started in single-user mode. However, the only one that you can 
switch to by name is "default" (with "rc default"). For the others, you 
have to use "init " just like sysv-rc.


In Gentoo, it makes sense to use named runlevels because if you install 
rsyslog, for example, you have to run "rc-update add rsyslog default" to 
ensure that rsyslog is started at boot. I guess that it makes more sense 
that running "rc-update add rsyslog 3" but in Debian, the maintainer 
scripts take care of this. If a Debian user wants to create a custom 
runlevel, calling it "4" or "thomasg" isn't that big a deal.


There's also a weird relationship between named levels, possibly because 
"default" is special-cased. I don't have a Gentoo box at hand to retest 
this but I did do this in the past.


When you boot to the "default" runlevel, "who -r" return "3". If you run 
"init 5", the runlevel switches to "5" instantaneously, and "rc-status 
--all" lists all the same services as "started".


If you boot to the "default" runlevel, rename "/etc/runlevels/default" 
to "/etc/runlevels/thomasg", and run "init 5", the runlevel switches to 
"5" by shutting down the daemons in "thomasg", and "rc-status --all" 
lists the sysinit and boot services as "started" and the thomasg 
services as "stopped".


Perhaps you'd have to run "rc thomasg" before "init 5" for the "thomasg" 
daemons not to be stopped but it's non-intuitive.


I know that it's a contrived, artificial (mis)manipulation that's 
unlikely in a real-world situation but there does seem to be a 
disconnect somewhere.



> - Stateful system (see rc-status)

see insserv


> - Dependency caching system (so you wont have to wait for its
> calculation at next boot)

see insserv


> And of course:
> - minimalistic declarative "runscripts", instead of huge init.d scripts.
> A quick example that I wrote myself is available here:
> http://thomas.goirand.fr/blog/?p=147

I've never seen a runscript formatted in this way in Gentoo.

For example, I downloaded the rsyslog initd script:

[~]# cat /root/portage/app-admin/rsyslog/files/7-stable/rsyslog.initd
#!/sbin/runscript
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: 
/var/cvsroot/

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/24/2014 04:29 AM, Marco d'Itri wrote:
> On Feb 23, Thomas Goirand  wrote:
> 
>> Marco and yourself are *a way* off topic. Please at least have the
>> decency to rename the subject of the tread to "systemd fanboys flamewar
>> yet-again bashing OpenRC just for fun" or something similar (but
>> preferably: don't just do that in this list, and avoid replying about
>> anything related to OpenRC, since we all know what type of
>> non-productive content it's going to be).
> This is not about systemd or any other init system.
> This is about how much additional work the five OpenRC users will cause 
> to other developers.

Probably you missed the point. Maybe because you don't really know what
OpenRC is about and what it does. Let's say we don't bring in new
packages, then it's 100% supported *right now* in Debian, using the
already existing LSB header init scripts. If there's new packages, then
it's probably more easy to use the simplified runscripts rather than the
traditional sysv-rc LSB header init.d scripts.

Also, it is my understanding that we wouldn't force anyone to add
support unless a patch is provided. I have no problem with that rule.

What additional work are you therefore talking about? It'd be actually
less work. The goal here is to *simplify* the maintenance of init
scripts (as well, for non-linux ports), by making it possible to use the
OpenRC syntax instead of the one of LSB header scripts which everyone
wants to get rid of.

OpenRC addresses the needs of about the 160k current users of sysv-rc.
This has nothing to do with the 800 systemd users (note: if you didn't
get it, I well know this is silly stats, I'm just using the same kind of
argumentation to show how pointless it is to use these stats in such a way).

Now that systemd is to become the default init system, at least let us
discuss peacefully about ways to address the problem of its
non-availability on some ports, and how to deal without systemd (also on
linux ports), for those who don't want to use it. If you aren't
interested in this topic, just don't read. Nobody forces you to do so.
The topic well identifies the content of the thread.

> Also, if I were bashing it just for fun then I would not forget 
> mentioning its Gentoo origin.

Very constructive. Thanks.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530af289.8090...@debian.org

Re: default init on non-Linux platforms

[heroxbd]

Dear Kevin,

Kevin Chadwick  writes:

> The benefit that Linux and even firefox etc. has gained from OpenBSD's
> practically paranoid bug fixing as well as finding the bugs for all the
> platforms it's userland still runs on especially in compiler tools
> should be realised and not underestimated. To some degree it will be
> true for debians HURD and is it kfreebsd too. So I don't get the
> holding Linux back rubbish especially when it is often based on
> superficial arguments that carry little weight, atleast in my eyes.
> Isolating Linux would hold it back and make it a flakier system in my
> eyes.

Thanks! That's exactly what I want to say.

I would like to have Debian GNU/kFreeBSD and GNU/Linux, butterflies and
human beings share this planet.

Benda


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/861tyts6di@moguhome00.in.awa.tohoku.ac.jp

Balance of portability and maintenance burden (Re: default init on non-Linux platforms)

[heroxbd]

Hey Adrian,

John Paul Adrian Glaubitz  writes:

> That's correct. However, the problem with kFreeBSD is that I - as a
> package maintainer - have to invest extra time to make sure my
> packages don't FTBFS on these architectures as otherwise my packages
> wouldn't be allowed to migrate to testing. Time which I rather invest
> into more important packaging work.

If you are that concerned about the maintenance burden, I am happy to
say OpenRC packagers are willing to help in this situation for any
OpenRC related issues. Just bug us.

On kFreeBSD, IMHO, diversity is quite a good thing, even from a packager
maintainer PoV. Making your package portable in the correct way (say,
not temperary conditional block hacks) is generally good for its
rubostness. Implicit assumptions to a single environment ease our tasks
in the short run, but accumulate and exploit the health of the package
in the long run.

Cheers,
Benda


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/86a9dhs71i.fsf...@moguhome00.in.awa.tohoku.ac.jp

Re: default init on non-Linux platforms

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/23/2014 03:29 PM, Marco d'Itri wrote:

> On Feb 23, Thomas Goirand  wrote:
> 
>> Marco and yourself are *a way* off topic. Please at least have the
>> decency to rename the subject of the tread to "systemd fanboys
>> flamewar yet-again bashing OpenRC just for fun" or something
>> similar (but preferably: don't just do that in this list, and avoid
>> replying about anything related to OpenRC, since we all know what
>> type of non-productive content it's going to be).
> 
> This is not about systemd or any other init system.
> 
> This is about how much additional work the five OpenRC users will
> cause to other developers.

To be fair, you would also have to add all the Hurd and kFreeBSD users -
and even if you assume that everyone who runs popcon on an amd64
kFreeBSD box also runs it on an i386 kFreeBSD box, and also runs it on a
Hurd box just for 100% overlap, according to the popcon front page
that's still 82 current users.

That's less than one in 2000 popcon submissions, which is not even a
drop in the total bucket - but it's much more than 5, and is still only
counting people who run popcon. (Which I often don't, because it breaks
my reflexive attempts to tab-complete 'popd' when I'm root.)

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTCl/4AAoJEASpNY00KDJry+EQAIKNnlm7r76b65+FI5gpWdwr
u5vnLlGWLx44K4PeIplZSmmEml0HXY41M2P7FL09bOtluXRJDv2xvJuogN8MXb6B
ff5i+kjbFbBT6SfYdIsCzS2bShP96UUG+bTALWuqwTOiUZp2w37GjiFBSzWcmcGl
j56imuiCMqIdoVrQFvYrB3gUKuDhsfbcvOU17suevdosu/fybzvjIvxQBSya+0iI
pTKWagygNyAEixpHnpGlaYyYTgHr4AIgGgjABULFsPzmVBFqomv8yr1VoHzf5hE4
3EbW5Bb/tzX2gjJraQkZXScsAfQ945T6baD6Ez5PN9RdLXwS4x5hfVN80JF0MlQq
IM/LxlXS8bjSyPWadVoK8ev+P8IJKoZwoew4QtGTwaK95/qd2jK0q/0jfA4tJcRQ
HECSCUpDyt28FiUF+BTfb+nsVsy0vGXDBghVIH6as23G2f75gONXlpLtbHv0kf9E
FEf++Pn1j8CBupehDlZnFTb4w9Fq1n6N8D0MBObyxDzVyA5ihPf/Mo0MKUDx0NDE
DqDmyxCM1cFsCO/Pq3KP9FLzfyv/bAR/H4T/rhMk1y1G9JxqTyhs3wVzzsBYSLKC
WxhNl+kICrp5qx+tk170fRIfXkFrxanuFk15h3nWSPZCv+0hsdwWGMk08RKTTPBr
X6nYHVaj6G2WKUeNmArW
=PHl0
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530a5ff8.8060...@fastmail.fm

Re: default init on non-Linux platforms

[Marco d'Itri]

On Feb 23, Thomas Goirand  wrote:

> Marco and yourself are *a way* off topic. Please at least have the
> decency to rename the subject of the tread to "systemd fanboys flamewar
> yet-again bashing OpenRC just for fun" or something similar (but
> preferably: don't just do that in this list, and avoid replying about
> anything related to OpenRC, since we all know what type of
> non-productive content it's going to be).
This is not about systemd or any other init system.
This is about how much additional work the five OpenRC users will cause 
to other developers.

Also, if I were bashing it just for fun then I would not forget 
mentioning its Gentoo origin.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

[Kevin Chadwick]

previously on this list Kevin Chadwick contributed:

> Perhaps before this thread spirals out of control I should

should also mention this has been discussed on this very list already,
though before I was enrolled and the following response went
unreplied to. 

On the other hand and I doubt of significance to me but it may well be
worth looking into how Google uses cgroups though apparently systemd
causes or would cause problems for them in potential kernel changes
being incompatible with their usage. May have been resolved and brought
up before though I forget if replied to, but might provide some
pro argument for the cgroups case for the few that it matters to
rather than the many that enforcing it's usage matters to.

https://lists.debian.org/debian-devel/2011/07/msg00423.html

___

>> It seems this problem (double fork) is the basement of using cgroup
>> under systemd ;)
>
> I think messing around with cgroups is a ridiculous way to solve this
> problem.

To be fair, systemd also uses cgroups to reliably kill rogue child
processes when stopping a service.  This is not unlike what BSD-derived
shells use pgroups for, I believe.

> The right answer is simply to change the daemons to give
> them an option which causes them not to fork.  Then you can just have
> a single supervision daemon which reaps (and restarts, if desired).

> I haven't done a survey of the available init replacements but this is
> not a new concept

Well, it's already present in SV init :

  1:2345:respawn:/sbin/getty 38400 tty1

> and I hope that most of them implement it as a possibility.

Daemontools, runit, minit, upstart, systemd all do.  I don't know about
initng.

-- Juliusz



-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/489578.4170...@smtp104.mail.ir2.yahoo.com

Re: default init on non-Linux platforms

[Kevin Chadwick]

previously on this list Matthias Urlichs contributed:

> One sample usecase where they dont't: "the system is wedged / overcommitted
> and I need to terminate some services; guess I'll start another ten processes
> to do that". Yeah, right.
> 
> I'll be nice to everybody else here and not enumerate any others.

Again that means your system is badly designed or administered without
proper restraints such as nice and limits which are important for
other reasons. Pkill root owned processes are hardly demanding but quite
the opposite.

not-well designed services should be fixed.

Why should I HAVE to have any evil when I don't have ANY need for it
and have much more important things depending on the kernel to be secure.

"unfortunately cgroups are a necessary evil" - Linus Torvalds

Should have added for a select few and others that don't know what
they are doing!

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/400062.71270...@smtp120.mail.ir2.yahoo.com

Re: default init on non-Linux platforms

[Matthias Urlichs]

Hi,

Kevin Chadwick:
> Regex works just fine for me.
> 
One sample usecase where they dont't: "the system is wedged / overcommitted
and I need to terminate some services; guess I'll start another ten processes
to do that". Yeah, right.

I'll be nice to everybody else here and not enumerate any others.

>> … not to mention any other processes which the daemon started, which
>> may or may not linger after its (grand)parent died, and which may or
>> may not cause problems when restarting.
>
> Never happened to me and shouldn't happen on a well designed service
> that should be controlling it's children. If it does happen you should
> be checking the system over anyway and possibly filing a bug.

*its children.

Besides, this is immaterial; a well-designed init should be able to cope
with not-well-designed services and furthermore should be able to help
me debug them if/when that happens. 


To summarize:

Please stop bashing features just because you happen to not
need ^w want them.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/21/2014 03:37 AM, Ondřej Surý wrote:
> mkdir -p /run/openrc
> touch /run/openrc/softlevel
> 
> and then it still doesn't work as expected:
> 
> root@howl:/etc/init.d# /etc/init.d/rsyslog start
>  * WARNING: rsyslog is already starting
> 
> root@howl:/etc/init.d# /etc/init.d/rsyslog stop
>  * ERROR: rsyslog stopped by something else
> 
> root@howl:/etc/init.d# /etc/init.d/rsyslog status
>  * status: stopped
> 
> root@howl:/etc/init.d# ps uax | grep rsyslo[g]
> root  6743  0.0  0.0  52592  1752 ?Ssl  20:28   0:00
> /usr/sbin/rsyslogd -n -c5
> root  6764  0.0  0.0   7768   856 pts/0S+   20:28   0:00 grep
> rsyslog
> 
> Thomas, would it be possible to make openrc-run work even when the
> openrc doesn't replace /etc/init.d/rc{,S}? Or does it need too much from
> openrc infrastructure, so my idea is just too crazy?

I'm not sure about how much work it would be, or how easy it would be to
implement, but the more I think about it, the more I think it'd be great
to do this.

The only problem I'd see, is that we'd have to keep the LSB headers,
since startpar / insserv would still only understand that. Though that's
probably the least annoying part. If at least we can rewrite the rest of
the scripts using the runscripts simplification, and have this available
by default in Jessie, then it'd be awesome. Switching between OpenRC and
sysv-rc can be dealt with later then (since what's important is to have
runscript support as early as possible).

I'll see with the rest of the contributors what they think about it, but
Benda seem to be positive about the fact it's doable. I'd also like to
patch sysv-rc so that it could write in /run/openrc/started, so that we
get a list of running daemon when switching to OpenRC (and avoid the
hack of parsing with "for file in /etc/rc0.d" to do a manual shutdown
after the switch).

Cheers,

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530a110c.8070...@debian.org

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/23/2014 08:57 PM, John Paul Adrian Glaubitz wrote:
> On Sun, Feb 23, 2014 at 08:50:13PM +0800, Thomas Goirand wrote:
>  > 
> http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysv-rc&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>>
>> sysv-rc wins...
>>
>> With useless stats, we can say useless things.
> 
> Two things:
> 
> - virtually everyone installs systemd in parallel, not by installing
>   systemd-sysv as this means you don't have an easy way of going
>   back to System V Init in case you shoot yourself into the foot;
>   you just install the package and point your init to the systemd
>   binary
> 
> - System V Init is the current default, of course it's installed
>   on virtually all systems
> 
>> http://qa.debian.org/popcon-graph.php?packages=systemd+upstart+openrc&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
> 
> Those are the proper stats to be used and you clearly see the trend.
> 
> And like your pet project - OpenRC - my pet project - the m68k port -
> isn't very popular either:
> 
>> http://popcon.debian.org/stat/submission.png
> 
> And I am not complaining that we're not making it a stable release,
> simply because it's pointless with a documented user base of 9.
> 
> Adrian

Marco and yourself are *a way* off topic. Please at least have the
decency to rename the subject of the tread to "systemd fanboys flamewar
yet-again bashing OpenRC just for fun" or something similar (but
preferably: don't just do that in this list, and avoid replying about
anything related to OpenRC, since we all know what type of
non-productive content it's going to be).

On 02/23/2014 09:04 PM, John Paul Adrian Glaubitz wrote:
> Well. OpenRC was up for discussion as the default init, wasn't it?

Yes, *was*. Now, move on, we're not discussing this anymore. If you
didn't notice the subject of this thread, it is:
"default init on non-Linux platforms"

On 02/23/2014 09:06 PM, John Paul Adrian Glaubitz wrote:
> I'm out, the weather is too nice :).

Exactly: you have better things to do. So please stay out (of this
thread and anything else related to OpenRC) and never come back.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530a0f23.3070...@debian.org

Re: default init on non-Linux platforms

[Kevin Chadwick]

Perhaps before this thread spirals out of control I should re-iterate
that what I said was cgroups doesn't pass the worth-it barrier for me
and not that they have NO value.

I also mentioned pgroups for those that do want this functionality but
also want portability and not bugs in daemons on one system but not
another increasing forking, reducing eyefall, collaboration etc. and
perhaps want a simpler solution.

The benefit that Linux and even firefox etc. has gained from OpenBSD's
practically paranoid bug fixing as well as finding the bugs for all the
platforms it's userland still runs on especially in compiler tools
should be realised and not underestimated. To some degree it will be
true for debians HURD and is it kfreebsd too. So I don't get the
holding Linux back rubbish especially when it is often based on
superficial arguments that carry little weight, atleast in my eyes.
Isolating Linux would hold it back and make it a flakier system in my
eyes.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/924308.73795...@smtp129.mail.ir2.yahoo.com

Re: default init on non-Linux platforms

[Kevin Chadwick]

previously on this list Marco d'Itri contributed:

> > But you aren't planning on running openrc at all, are you?  
> Who is? Seriously, would you mind stepping forward?

If it was available I would use it but wouldn't be switching cgroups
on or would be switching them off even if I hadn't bothered to
compile them out of the kernel out of principle and to catch any
nonsense that *required* them because some daemon writer has now decided
they don't need to bother with tracking their own children anymore.

When I used OpenRC on Alpine Linux I found it far nicer to work with
than any of systemd, upstart or syv-rc. The only one I find nicer to
work with is OpenBSD's.


-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/277875.64541...@smtp137.mail.ir2.yahoo.com

Re: default init on non-Linux platforms

[Kevin Chadwick]

previously on this list Matthias Urlichs contributed:

> > Kevin, I don't think you understand the reasoning behind this. Again,
> > the problem the init system has to solve here is being able to track a
> > process with a 100% accuracy, so whatever automated mechanisms you have
> > configured when certain situations occur, they have to find the correct
> > process to work on as to not kill the daemon instance you actually
> > still need.
> >   
> … not to mention any other processes which the daemon started, which
> may or may not linger after its (grand)parent died, and which may or
> may not cause problems when restarting.

Never happened to me and shouldn't happen on a well designed service
that should be controlling it's children. If it does happen you should
be checking the system over anyway and possibly filing a bug.

The only time I've had zombies is on a desktop.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/706169.64541...@smtp137.mail.ir2.yahoo.com

Re: default init on non-Linux platforms

[Kevin Chadwick]

On Fri, 21 Feb 2014 23:53:51 +0100
John Paul Adrian Glaubitz wrote:

> Kevin, I don't think you understand the reasoning behind this. Again,
> the problem the init system has to solve here is being able to track a
> process with a 100% accuracy, so whatever automated mechanisms you have
> configured when certain situations occur, they have to find the correct
> process to work on as to not kill the daemon instance you actually
> still need.
> 

ADRIAN, I hate it when people use your name thinking it makes any
difference to the content your about to spout.

> And, to my current knowledge, this is not possible without a mechanism
> like CGroups. Whether you rely on PID files or grep through the output
> of "ps" or use "pidof", either of them are fragile and prone to fail.
> 

Regex works just fine for me.

> I elaborated in my actual real-life case how PID files are prone to
> failure - I am aware that the situation with the full filesystem
> shouldn't occur in the first place,

Right including the rest of this email that's two counts of fantasy or
bad practice now justifying increased complexity in the kernel.

>  but, well administrators are just
> humans after all - and, using "ps" to track the process you are looking
> for to be able to restart, stop or kill it, can obviously be easily
> tricked into failure as well. 

> I was merely expressing that I think that CGroups are an indispensable
> if you're planning to use Debian to build modern productive systems with
> high availability in mind.

As I have already said in previous threads that you have obviously
forgotten from months ago. Something like CARP for complete server
redundancy or Ciscos redundancy protocol, I forget what it is called
is the way to go for many reasons.

> Just imagine some other (malicious)
> process using the same name as well or when you need to control
> different instances of the very same process.

So you keep machines that are running malicious processes online by
adding complexity to the kernel. It is people like you that meant that
kernel.org was offline for months after rediculously simple measures
weren't bothered with.

If you are lucky enough to have malicious processes that can be found
rather than a rootkit then you should be pulling the plug investigating
and hardening before all your machines take part in a DDOS.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/648730.64541...@smtp137.mail.ir2.yahoo.com

Re: default init on non-Linux platforms

[John Paul Adrian Glaubitz]

On Sun, Feb 23, 2014 at 08:45:10PM +0800, Thomas Goirand wrote:
> On 02/23/2014 07:32 PM, Jonathan Dowland wrote:
> > 
> > 
> >> On 21 Feb 2014, at 12:22, John Paul Adrian Glaubitz 
> >>  wrote:
> >>
> >> I agree and understand that this was the way to go back in the old
> >> days, but we shouldn't be using that on current setups.
> > 
> > But you aren't planning on running openrc at all, are you?
> 
> No, he's just planning on more pointless critics.

Hooray, another init system war on debian-devel on a sunny Sunday!

I know, reliable service starting and process tracking is completely
pointless and setting architectures with a neglectable userbase is
what we should all invest our efforts into.

I'm out, the weather is too nice :).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140223130643.ge6...@physik.fu-berlin.de

Re: default init on non-Linux platforms

[John Paul Adrian Glaubitz]

On Sun, Feb 23, 2014 at 08:50:13PM +0800, Thomas Goirand wrote:
 > http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysv-rc&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
> 
> sysv-rc wins...
> 
> With useless stats, we can say useless things.

Two things:

- virtually everyone installs systemd in parallel, not by installing
  systemd-sysv as this means you don't have an easy way of going
  back to System V Init in case you shoot yourself into the foot;
  you just install the package and point your init to the systemd
  binary

- System V Init is the current default, of course it's installed
  on virtually all systems

> http://qa.debian.org/popcon-graph.php?packages=systemd+upstart+openrc&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

Those are the proper stats to be used and you clearly see the trend.

And like your pet project - OpenRC - my pet project - the m68k port -
isn't very popular either:

> http://popcon.debian.org/stat/submission.png

And I am not complaining that we're not making it a stable release,
simply because it's pointless with a documented user base of 9.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140223125734.gc6...@physik.fu-berlin.de

Re: default init on non-Linux platforms

[John Paul Adrian Glaubitz]

On Sun, Feb 23, 2014 at 12:43:14PM +, Jonathan Dowland wrote:
> Since you aren't a user nor are going to be a user of openrc, I don't
> see why you feel the need to critique it, especially on debian-devel
> where the majority of subscribers are just not interested.

Well. OpenRC was up for discussion as the default init, wasn't it?

> You don't care about KFreeBSD, I don't care about KFreeBSD, but some do
> so why not leave them to it and focus your energy on something you do
> care about?

That's correct. However, the problem with kFreeBSD is that I - as a
package maintainer - have to invest extra time to make sure my
packages don't FTBFS on these architectures as otherwise my packages
wouldn't be allowed to migrate to testing. Time which I rather invest
into more important packaging work.

That would be the same as me forcing everyone else to make sure their
packages build fine on m68k even though it has zero relevance.

When Michael Stapelberg asked the audience eduring one of his talks
[1] whether any of them was using the kFreeBSD port, not a single
person was raising their hands, yet everyone else has to deal with it
and yet some people lose their minds when it doesn't get the same
attention as the Linux port.

Adrian

> [1] http://penta.debconf.org/dc13_schedule/speakers/2589.en.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140223130437.gd6...@physik.fu-berlin.de

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/23/2014 07:36 PM, Marco d'Itri wrote:
> On Feb 23, Jonathan Dowland  wrote:
> 
>> But you aren't planning on running openrc at all, are you?
> Who is? Seriously, would you mind stepping forward?
> 
> http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
> 
> What I see here is an handful of people wasting the time of a lot of 
> other people to further their own pet project.

http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysv-rc&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

sysv-rc wins...

With useless stats, we can say useless things.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5309ee85.4090...@debian.org

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/23/2014 07:32 PM, Jonathan Dowland wrote:
> 
> 
>> On 21 Feb 2014, at 12:22, John Paul Adrian Glaubitz 
>>  wrote:
>>
>> I agree and understand that this was the way to go back in the old
>> days, but we shouldn't be using that on current setups.
> 
> But you aren't planning on running openrc at all, are you?

No, he's just planning on more pointless critics.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5309ed56.1060...@debian.org

Re: default init on non-Linux platforms

[Jonathan Dowland]

Please do not CC me, I am subscribed to the list.

On Sun, Feb 23, 2014 at 12:47:44PM +0100, John Paul Adrian Glaubitz
wrote:
> On 02/23/2014 12:32 PM, Jonathan Dowland wrote:
> > But you aren't planning on running openrc at all, are you?
> 
> No, and I don't see any compelling reason why I should. With systemd
> there is one mature solution that does the job well and which is
> adopted by most other distributions now.

Since you aren't a user nor are going to be a user of openrc, I don't
see why you feel the need to critique it, especially on debian-devel
where the majority of subscribers are just not interested.

> I was merely expressing that I think that CGroups are an indispensable
> if you're planning to use Debian to build modern productive systems
> with high availability in mind.

Yup, but cgroups aren't available on KFreeBSD and one of the main
reasons for openrc in Debian is to provide some init system better than
sysvinit that works on the other kernel we are committed to supporting.
You don't care about KFreeBSD, I don't care about KFreeBSD, but some do
so why not leave them to it and focus your energy on something you do
care about?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140223124314.ga17...@bryant.redmars.org

Re: default init on non-Linux platforms

[John Paul Adrian Glaubitz]

On 02/23/2014 12:32 PM, Jonathan Dowland wrote:
>> I agree and understand that this was the way to go back in the old
>> days, but we shouldn't be using that on current setups.
> 
> But you aren't planning on running openrc at all, are you?

No, and I don't see any compelling reason why I should. With systemd
there is one mature solution that does the job well and which is adopted
by most other distributions now.

I was merely expressing that I think that CGroups are an indispensable
if you're planning to use Debian to build modern productive systems with
high availability in mind.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5309dfe0.9000...@physik.fu-berlin.de

Re: default init on non-Linux platforms

[Marco d'Itri]

On Feb 23, Jonathan Dowland  wrote:

> But you aren't planning on running openrc at all, are you?
Who is? Seriously, would you mind stepping forward?

http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

What I see here is an handful of people wasting the time of a lot of 
other people to further their own pet project.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

[Jonathan Dowland]

> On 21 Feb 2014, at 12:22, John Paul Adrian Glaubitz 
>  wrote:
> 
> I agree and understand that this was the way to go back in the old
> days, but we shouldn't be using that on current setups.

But you aren't planning on running openrc at all, are you?

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/595928c6-b3dd-4e34-9828-d72b62e3b...@debian.org

Re: default init on non-Linux platforms

[Matthias Urlichs]

Hi,

John Paul Adrian Glaubitz:
> Kevin, I don't think you understand the reasoning behind this. Again,
> the problem the init system has to solve here is being able to track a
> process with a 100% accuracy, so whatever automated mechanisms you have
> configured when certain situations occur, they have to find the correct
> process to work on as to not kill the daemon instance you actually
> still need.
> 
… not to mention any other processes which the daemon started, which
may or may not linger after its (grand)parent died, and which may or
may not cause problems when restarting.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

[John Paul Adrian Glaubitz]

On 02/21/2014 11:38 PM, Kevin Chadwick wrote:
> previously on this list hero...@gentoo.org contributed:
> 
>>> And grepping through the output of "ps" or similar is not what
>>> I would consider reliable and robust either.  
>>
>> Nod. grepping `ps` is what we should avoid at all cost.
> 
> All cost? While I like OpenRC and thanks to Gentoo for it and like
> your mention of each to there own (I am no old-nerd by the way). I have
> to disagree.

Kevin, I don't think you understand the reasoning behind this. Again,
the problem the init system has to solve here is being able to track a
process with a 100% accuracy, so whatever automated mechanisms you have
configured when certain situations occur, they have to find the correct
process to work on as to not kill the daemon instance you actually
still need.

And, to my current knowledge, this is not possible without a mechanism
like CGroups. Whether you rely on PID files or grep through the output
of "ps" or use "pidof", either of them are fragile and prone to fail.

I elaborated in my actual real-life case how PID files are prone to
failure - I am aware that the situation with the full filesystem
shouldn't occur in the first place, but, well administrators are just
humans after all - and, using "ps" to track the process you are looking
for to be able to restart, stop or kill it, can obviously be easily
tricked into failure as well. Just imagine some other (malicious)
process using the same name as well or when you need to control
different instances of the very same process. "pidof" might help
when you have the full path. But how does that keep you from working
on the wrong instance?

I have been looking for a solution of solving that problem without
CGroups, but I haven't really found one yet.

Do you know one?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5307d8ff.1000...@physik.fu-berlin.de

Re: default init on non-Linux platforms

[Kevin Chadwick]

previously on this list hero...@gentoo.org contributed:

> > And grepping through the output of "ps" or similar is not what
> > I would consider reliable and robust either.  
> 
> Nod. grepping `ps` is what we should avoid at all cost.

All cost? While I like OpenRC and thanks to Gentoo for it and like
your mention of each to there own (I am no old-nerd by the way). I have
to disagree.

If a service fails I am more interested in why and what will happen if
it restarts and not is it back-up already. For that, I would use
redundant servers which in any way you look at it and especially for
high availability situations must be more reliable than trying to
restart a failed service blindly that may not operate as it should when
it does.

Functional externally generated tests like https returned this file are
most valuable for monitoring services and I don't really see your point
or the major benefit at all, especially if it involves increased kernel
complexity.

cgroups doesn't break that, worth it, question for me personally.

However whilst I have found the reasoning by the CTTE to have been
rather disappointing and superficial and I am unlikely to ever use
systemd due to having fundamental issues with it. If a major concern was
portability and many of you have your heart set on systemd then
although it goes against my desires and technical concerns then perhaps
pgroups are worth a mention.




http://marc.info/?l=openbsd-misc&m=135313692911156&w=2


how can someone write this and not explain why a process managing
pgroups can't achieve the same results?

pgroups is going to be the first alternative for someone instinctively
looking for a portable alternative, so i'm genuinely interested in
knowing why they've discarded the idea

i am, however, aware of differences *unrelated* to writing a systemd
like appliance. pgroups do not provide per item hostname and other
virtualization facilities in freebsd jails/linux cgroups, but what
about *relevant* differences? something weak like "the index for for
cgroups is wide enough to fit an UUID"? in other words, something that
*doesn't* require a completely new api?




http://marc.info/?l=openbsd-misc&m=135314269712851&w=2

therefore the requirement for cgroups is completely arbitrary

also of interest:

* early versions of systemd documentation advised daemon authors not
to double fork. presumably cgroups wasn't in the radar at the time

* several (all?) openbsd daemons have options for not double-forking.
some of these daemons have the gall of preceding systemd




-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/163088.43505...@smtp102.mail.ir2.yahoo.com

Re: default init on non-Linux platforms

[heroxbd]

Dear Adrian,

John Paul Adrian Glaubitz  writes:

> On 02/21/2014 01:00 PM, hero...@gentoo.org wrote:
>>> So, OpenRC actually also relies on files - like System V Init - to
>>> track the state of a service? Isn't that approach somewhat unreliable
>>> and hacky?
>> 
>> I bet you are going to tell me the only reliable and non-hacky way to
>> track the state of a service is not forking/writing to files but
>> starting it foreground by a long-living daemon. I agree with you.
>
> Well, I was thinking about something like CGroups. I don't like the
> idea of having to rely on files for an init system to be able to
> track the processes it has started.
>
> I agree and understand that this was the way to go back in the old
> days, but we shouldn't be using that on current setups.
>
> At my department, we stumbled right over this design when the /var
> filesystem was full and System V Init could no longer create PID
> files to be able to track services, yet it started services without
> complaining.
>
> Since we had to restart our dhcpd several days on a particular day,
> System V Init was unable to track whether the daemon was already
> running and we ended up with several dozen instances.
>
> Sure, it's probably a bug in the init script used as it didn't
> check for enough disk space and wasn't failing when the disk is full.
> But again, this is a core component depending on external scripts
> being bug free which is not the correct approach when you are
> aiming for something robust.

Thank your for sharing with us your real life story. I can reasonate
with it: having a dhcpd malfunctioning and hundreds of people
complaining about the resulting unstable network is no fun at all.

How to cope with this will be a matter of personal taste. You might
think a robust framework will make it fool-proof. While I might think
running a central dhcp server along with something else which possibly
fill up the /var is questionable itself. I appreciate both.

>> OpenRC leverages cgroups when available. We are also working on a plugin
>> framework for external supervisors such as djbtools, runit and s6 (maybe
>> launchd, smf, systemd, ... as well if they're hackable) to do this
>> foreground status tracking while integrated with OpenRC: We are not
>> there yet though.
>
> Can external supervisors like djbtools or runit actually reliably track
> processes and if, yes, how? From my understanding, it's impossible
> to be able to really track a process once it has started when
> you don't have the possibility to use something like CGroups as
> services could always just double-fork. The tracking has to be
> done through a mechanism provided by the kernel, doesn't it?

I've meant "foreground", the opposite of double-fork, which has been
discussed in the list, like:

http://article.gmane.org/gmane.linux.debian.devel.general/152538

This does not require a special tracking mechanism in the kernel.

Double-fork is not a reliable way to track process. People invented it
as a hack back in history (from BSD community if I remember it right).

> And grepping through the output of "ps" or similar is not what
> I would consider reliable and robust either.

Nod. grepping `ps` is what we should avoid at all cost.

>> These advanced features are optional. We can still use the unreliable
>> and hacky way of trakcing files when the task is trivial, like a
>> personal VPS or laptop which do not care much about running sshd/httpd
>> for 3 years non-stop.
>
> Sure, I fully agree. But there are actually many enterprises who
> need something with 99% service availability. Our department
> runs a webserver, a login node for 1200 users and a large compute
> clusters with over 200 nodes and an SGI UV1000 (1024 CPUs, 2 TiB),
> so we need something which is able to control resources and track
> processes. Many enterprises and websites run Debian.

Yes, though I am a casual user, I actually had systemd and monit to
supervise httpd in one of our mirror servers. And I myself am even using
a computing cluter running RHEL5 (for stability and paid customer
service). So I am quite sharing the view with you. Different people in
different situations have different needs: Using a bad old pid-file
tracking, or no tracking at all is like wearing jeans at home, or even
naked. It happily coexists with the situation of wearing suites doing
public speech.

--- super light-hearded, just for fun, don't take it seriously ---
modern activists: com'on, just us, or you'll not be supported.
(com'on, wear suites, or you're out)
old nerds: fine, we will support ourselves.
(fine, we will find somewhere comfortable to be naked)
--- end ---

Hope this explains why I am devoting to something alternative and even
counter-advertised as suboptimal. Let's coexist and have fun. This
universe is ultimately a friendly place to live in after all.


Coming back to our starting point: service relying on file-tracking is
hackish and is recommended to be avoided in serious business in
preferre

Re: default init on non-Linux platforms

[John Paul Adrian Glaubitz]

On 02/21/2014 01:00 PM, hero...@gentoo.org wrote:
>> So, OpenRC actually also relies on files - like System V Init - to
>> track the state of a service? Isn't that approach somewhat unreliable
>> and hacky?
> 
> I bet you are going to tell me the only reliable and non-hacky way to
> track the state of a service is not forking/writing to files but
> starting it foreground by a long-living daemon. I agree with you.

Well, I was thinking about something like CGroups. I don't like the
idea of having to rely on files for an init system to be able to
track the processes it has started.

I agree and understand that this was the way to go back in the old
days, but we shouldn't be using that on current setups.

At my department, we stumbled right over this design when the /var
filesystem was full and System V Init could no longer create PID
files to be able to track services, yet it started services without
complaining.

Since we had to restart our dhcpd several days on a particular day,
System V Init was unable to track whether the daemon was already
running and we ended up with several dozen instances.

Sure, it's probably a bug in the init script used as it didn't
check for enough disk space and wasn't failing when the disk is full.
But again, this is a core component depending on external scripts
being bug free which is not the correct approach when you are
aiming for something robust.

> OpenRC leverages cgroups when available. We are also working on a plugin
> framework for external supervisors such as djbtools, runit and s6 (maybe
> launchd, smf, systemd, ... as well if they're hackable) to do this
> foreground status tracking while integrated with OpenRC: We are not
> there yet though.

Can external supervisors like djbtools or runit actually reliably track
processes and if, yes, how? From my understanding, it's impossible
to be able to really track a process once it has started when
you don't have the possibility to use something like CGroups as
services could always just double-fork. The tracking has to be
done through a mechanism provided by the kernel, doesn't it?

And grepping through the output of "ps" or similar is not what
I would consider reliable and robust either.

> These advanced features are optional. We can still use the unreliable
> and hacky way of trakcing files when the task is trivial, like a
> personal VPS or laptop which do not care much about running sshd/httpd
> for 3 years non-stop.

Sure, I fully agree. But there are actually many enterprises who
need something with 99% service availability. Our department
runs a webserver, a login node for 1200 users and a large compute
clusters with over 200 nodes and an SGI UV1000 (1024 CPUs, 2 TiB),
so we need something which is able to control resources and track
processes. Many enterprises and websites run Debian.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5307451b.1010...@physik.fu-berlin.de

Re: default init on non-Linux platforms

[heroxbd]

Dear Adrian,

John Paul Adrian Glaubitz  writes:

> So, OpenRC actually also relies on files - like System V Init - to
> track the state of a service? Isn't that approach somewhat unreliable
> and hacky?

I bet you are going to tell me the only reliable and non-hacky way to
track the state of a service is not forking/writing to files but
starting it foreground by a long-living daemon. I agree with you.

OpenRC leverages cgroups when available. We are also working on a plugin
framework for external supervisors such as djbtools, runit and s6 (maybe
launchd, smf, systemd, ... as well if they're hackable) to do this
foreground status tracking while integrated with OpenRC: We are not
there yet though.

These advanced features are optional. We can still use the unreliable
and hacky way of trakcing files when the task is trivial, like a
personal VPS or laptop which do not care much about running sshd/httpd
for 3 years non-stop.

Thanks for the insight.
Benda


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86eh2w8ylo@moguhome00.in.awa.tohoku.ac.jp

Re: default init on non-Linux platforms

[John Paul Adrian Glaubitz]

On 02/21/2014 04:20 AM, hero...@gentoo.org wrote:
> OpenRC needs a proper directory structure in /run/openrc to track the
> status of services. It is handled by init.sh and friends, you may need
> to hack that.

So, OpenRC actually also relies on files - like System V Init - to
track the state of a service? Isn't that approach somewhat unreliable
and hacky?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53072a4c.7090...@physik.fu-berlin.de

Re: default init on non-Linux platforms

[Simon McVittie]

On 20/02/14 19:37, Ondřej Surý wrote:
> I have split openrc into openrc and openrc-sysv moving the conflicting
> parts to openrc-sysv on my system, and it install just fine

If sysv-rc's invoke-rc.d and update-rc.d should be treated as generic
glue shared by multiple inits (which they probably should, since they
already support all of sysv-rc/insserv, Upstart, systemd) then it might
make more sense to move them to sysvinit-utils, and include openrc
support in them there.

According to `apt-file search invoke-rc.d`, the only implementations of
invoke-rc.d or update-rc.d in Debian are sysv-rc, file-rc and openrc
(plus an update-rc.d in multistrap which I assume is some sort of
wrapper); systemd and Upstart both rely on the one from sysvinit.

file-rc appears to be basically dead, and hasn't been updated for
dependency-based boot. Upstart already has a hard dependency on sysv-rc.
Perhaps systemd (or at least systemd-sysv) should have that as well, or
Breaks: file-rc, or something, since I doubt file-rc's update-rc.d deals
with systemd units; systemd currently depends on initscripts, which
depends on sysv-rc|file-rc. I'll open a bug.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530722b0.9000...@debian.org

Re: default init on non-Linux platforms

[heroxbd]

Hey Ondřej,

Ondřej Surý  writes:

> I have split openrc into openrc and openrc-sysv moving the conflicting
> parts to openrc-sysv on my system, and it install just fine, but running
> script with /sbin/openrc-run needs:
>
> mkdir -p /run/openrc
> touch /run/openrc/softlevel
>
> and then it still doesn't work as expected:
>
> root@howl:/etc/init.d# /etc/init.d/rsyslog start
>  * WARNING: rsyslog is already starting
>
> root@howl:/etc/init.d# /etc/init.d/rsyslog stop
>  * ERROR: rsyslog stopped by something else
>
> root@howl:/etc/init.d# /etc/init.d/rsyslog status
>  * status: stopped

OpenRC needs a proper directory structure in /run/openrc to track the
status of services. It is handled by init.sh and friends, you may need
to hack that.

> root@howl:/etc/init.d# ps uax | grep rsyslo[g]
> root  6743  0.0  0.0  52592  1752 ?Ssl  20:28   0:00
> /usr/sbin/rsyslogd -n -c5
> root  6764  0.0  0.0   7768   856 pts/0S+   20:28   0:00 grep
> rsyslog
>
> Thomas, would it be possible to make openrc-run work even when the
> openrc doesn't replace /etc/init.d/rc{,S}? 

sure.

> Or does it need too much from openrc infrastructure, so my idea is
> just too crazy?

No, it not crazy. I am running OpenRC to manage services on the clusters
where I have only normal user privilege, it's in parallel to sysv-rc
like system of RHEL5. You might look into the MKPREFIX build option.

And out of curiosity, what are you trying to achieve here?

Cheers,
Benda

Re: default init on non-Linux platforms

[Ondřej Surý]

On Thu, Feb 20, 2014, at 17:39, Thomas Goirand wrote:
> There's of course dependencies in OpenRC. You have the choice: either
> you keep the LSB headers, either you write it the OpenRC way (IMO,
> prefered...). In OpenRC, you just use functions of the openrc-run
> "interpreter". For example:

Well, this is something I have been looking for...

If this can be made to work without the needed mumbo jumbo (see
below)... then it would solve the problem with migrating sysv-rc
scripts.

I have split openrc into openrc and openrc-sysv moving the conflicting
parts to openrc-sysv on my system, and it install just fine, but running
script with /sbin/openrc-run needs:

mkdir -p /run/openrc
touch /run/openrc/softlevel

and then it still doesn't work as expected:

root@howl:/etc/init.d# /etc/init.d/rsyslog start
 * WARNING: rsyslog is already starting

root@howl:/etc/init.d# /etc/init.d/rsyslog stop
 * ERROR: rsyslog stopped by something else

root@howl:/etc/init.d# /etc/init.d/rsyslog status
 * status: stopped

root@howl:/etc/init.d# ps uax | grep rsyslo[g]
root  6743  0.0  0.0  52592  1752 ?Ssl  20:28   0:00
/usr/sbin/rsyslogd -n -c5
root  6764  0.0  0.0   7768   856 pts/0S+   20:28   0:00 grep
rsyslog

Thomas, would it be possible to make openrc-run work even when the
openrc doesn't replace /etc/init.d/rc{,S}? Or does it need too much from
openrc infrastructure, so my idea is just too crazy?

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1392925038.31139.85827933.1da8f...@webmail.messagingengine.com

Re: default init on non-Linux platforms

[Russ Allbery]

Ansgar Burchardt  writes:
> On 02/20/2014 15:28, Thomas Goirand wrote:

>> Also, we have an ALIVE UPSTREAM TEAM, and an evolving project, which is
>> IMO important (is there anyone still working on sysv-rc apart from a
>> few Debian maintainers? my understanding is: we're alone now...).

> Doesn't it still use the (unmaintained?) sysvinit? But then, that's only
> a part that probably doesn't need much maintainance anyway.

I believe that sysvinit and sysv-rc are both actively maintained by at
least Petter Reinholdsten and possibly also Roger Leigh and Werner Fink (I
haven't checked recent commit activity, but Petter has definitely been
doing new development on those packages), and that they consider
themselves to be upstream, not just Debian package maintainers.  I
wouldn't classify either as unmaintained upstream, although the level of
resources available is currently low compared to the other init systems
we've been discussing.

http://savannah.nongnu.org/projects/sysvinit is the upstream home page.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ob21n2aa@windlord.stanford.edu

Re: default init on non-Linux platforms

[Russ Allbery]

Ansgar Burchardt  writes:
> On 02/20/2014 09:57, gregor herrmann wrote:
>> On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:

>>> That package does currently depend on
>>> perl, though, which isn't appropriate for an essential package.
>>> ...  The dependency is because
>>> deb-systemd-helper uses a bunch of modules that are not currently in
>>> perl-core (File::Path, File::Basename, File::Find, File::Temp,
>>> Text::ParseWords, and Data::Dumper,

>> I might be missing something but they all seem to be in perl core:

> I think Russ means they are not part of perl-base package, but provided
> by perl/perl-modules in Debian. So packages using them have to depend on
> the full perl package instead of the minimal perl-base package.

Yes, sorry, wrong package name.  I keep making that mistake.

> However this could be fixed by moving the additional modules to
> perl-base (increasing its size slightly) or changing the implementation
> to not use them.

Yes.  I'm not sure if we want to do that rather than just keeping that
program in a separate package from the stuff that has to be essential.
I'm not familiar with how high of a bar we set for including modules in
perl-base.

Some of those modules (File::Find, File::Temp, Text::ParseWords) are ones
where I'd be a little uncomfortable with open-coding the desired
functionality.  Getting those operations correct is tricky and requires
care, and it's best to use standard implementations that have been heavily
tested.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sirdn2i1@windlord.stanford.edu

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/20/2014 10:45 PM, Didier 'OdyX' Raboud wrote:
> Le jeudi, 20 février 2014, 22.28:56 Thomas Goirand a écrit :
>> On 02/20/2014 09:02 PM, Tom H wrote:
>>> What features does sysvinit+openrc have that
>>> sysvinit+sysv-rc+insserv doesn't have?
>>
>> Just to name a few:
>> - getting rid of the ugly LSB headers
> 
> They might be ugly, but they encode the dependency tree; by what are 
> they replaced in OpenRC?

There's of course dependencies in OpenRC. You have the choice: either
you keep the LSB headers, either you write it the OpenRC way (IMO,
prefered...). In OpenRC, you just use functions of the openrc-run
"interpreter". For exaample:

depend()
{
use dns
need localmount
after bootmisc ntp-client
}

The "need" expresses a Required-Start:, and "use", a Should-Start:.

>> - cgroup supports to kill processes
> 
> On non-Linux ports ?

cgroup are optional, and obvious, not in use in kFreeBSD (see
/etc/rc.conf for its activation).

On 02/20/2014 10:52 PM, Ansgar Burchardt wrote:
> I'm curious: does OpenRC allow processes to leave the cgroup? For
> example, when killing the ssh service, I do not want to kill active
> connections. With systemd, pam_systemd takes care of this. How does it
> work on OpenRC?

Sorry, I don't know. You can try if you're curious! :)

On 02/20/2014 10:52 PM, Ansgar Burchardt wrote:
> Doesn't it still use the (unmaintained?) sysvinit? But then, that's
> only a part that probably doesn't need much maintainance anyway.

Correct, and I agree. The /sbin/init binary is anyway very small. As
much as I can tell, it is built only out of src/init.c and src/utmp.c,
which together represent 3162 lines of C code currently. That's antic
code from 1991! :)

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53062fb1.3000...@debian.org

Re: default init on non-Linux platforms

[Ansgar Burchardt]

On 02/20/2014 15:28, Thomas Goirand wrote:
> On 02/20/2014 09:02 PM, Tom H wrote:
>> What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv
>> doesn't have?
> 
> Just to name a few:
> - getting rid of the ugly LSB headers
> - cgroup supports to kill processes

I'm curious: does OpenRC allow processes to leave the cgroup? For
example, when killing the ssh service, I do not want to kill active
connections. With systemd, pam_systemd takes care of this. How does it
work on OpenRC?

> - Dependency caching system (so you wont have to wait for its
> calculation at next boot)

I thought the current sysvinit implementation with insserv in Debian
already does this. But I might be wrong.

> Also, we have an ALIVE UPSTREAM TEAM, and an evolving project, which is
> IMO important (is there anyone still working on sysv-rc apart from a few
> Debian maintainers? my understanding is: we're alone now...).

Doesn't it still use the (unmaintained?) sysvinit? But then, that's only
a part that probably doesn't need much maintainance anyway.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530616c8.2090...@debian.org

Re: default init on non-Linux platforms

[Didier 'OdyX' Raboud]

Le jeudi, 20 février 2014, 22.28:56 Thomas Goirand a écrit :
> On 02/20/2014 09:02 PM, Tom H wrote:
> > What features does sysvinit+openrc have that
> > sysvinit+sysv-rc+insserv doesn't have?
> 
> Just to name a few:
> - getting rid of the ugly LSB headers

They might be ugly, but they encode the dependency tree; by what are 
they replaced in OpenRC?

> - cgroup supports to kill processes

On non-Linux ports ?

--
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/20/2014 09:02 PM, Tom H wrote:
> What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv
> doesn't have?

Just to name a few:
- getting rid of the ugly LSB headers
- cgroup supports to kill processes
- rc_hotplug (a hotplugged service is one started by a dynamic dev
manager when a matching hardware device is found).
- Checks if a daemon is really started by start-stop-daemon
- Dependency loop breaking system
- Named runlevels (I already talked about that)
- Stateful system (see rc-status)
- Dependency caching system (so you wont have to wait for its
calculation at next boot)
- ... (that's from top of my head, I may have forget some...)

And of course:
- minimalistic declarative "runscripts", instead of huge init.d scripts.
A quick example that I wrote myself is available here:
http://thomas.goirand.fr/blog/?p=147

You may find more examples inside the source code of openrc (in the
Debian source package for example), under init.d.misc. Interestingly, in
it you may see that simple things are very simple, but it's also
possible to make complex runscripts when needed (yes, the hard reality,
sometimes means that complex things are needed at boot time).

What's coming:
- monit integration in runscripts (so you can have monit to restart
crashed services, and send emails when they do). We already have patches
available for it, so it's taking a good shape.
- s6 (or equivalent) process monitoring. This is still under discussion
upstream.

There's some goodies which are more Gentoo oriented, like their network
integration, but I don't think it's worth mentioning as I don't think
these features would be useful for Debian, unless someone works on
adapting them (for example, to read /etc/network/interfaces instead of
whatever Gentoo uses).

Also, we have an ALIVE UPSTREAM TEAM, and an evolving project, which is
IMO important (is there anyone still working on sysv-rc apart from a few
Debian maintainers? my understanding is: we're alone now...).

Cheers,

Thomas Goirand (zigo)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53061128.1080...@debian.org

default init on non-Linux platforms

[Tom H]

On Thu, 20 Feb 2014 14:19:30 +0900, hero...@gentoo.org wrote:
> Tollef Fog Heen  writes:
>>
>> It's probably better to just contribute your changes to the sysv-rc
>> version and so make that one able to manage openrc in addition to the
>> others it already knows how to. No point in forking it.
>
> Forking was a decision made by me in the early phase of packaging
> OpenRC. At that time I referred to the way file-rc handled update-rc.d
> as in
>
> sysvinit: /usr/share/sysvinit/update-rc.d
>
> A central package providing update-rc.d and invoke-rc.d is nice.
> Though it should not be sysv-rc, which OpenRC is intending to replace.

What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv 
doesn't have?


https://wiki.debian.org/Debate/initsystem/openrc doesn't make that case 
and none of the members of the CTTE explained their "openrc > sysvinit" 
votes (unless I missed that point in the 100s/1000s of #727708 posts).



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5305fcf8.90...@gmail.com

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/20/2014 02:10 AM, Kevin Chadwick wrote:
> Do people use all those runlevels?

As much as I know, there's only 4 in use (using names of OpenRC here,
since OpenRC has named runlevels):
- shutdown (runlevel 0)
- recovery (runlevel 1)
- reboot (runlevel 6)
- default (often, everything else, but most of the time, it's runlevel 2
or 4)

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5305efed.4020...@debian.org

Re: default init on non-Linux platforms

[gregor herrmann]

On Thu, 20 Feb 2014 10:52:12 +0100, Ansgar Burchardt wrote:

> On 02/20/2014 09:57, gregor herrmann wrote:
> > On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:
> >> ...  The dependency is because
> >> deb-systemd-helper uses a bunch of modules that are not currently in
> >> perl-core (File::Path, File::Basename, File::Find, File::Temp,
> >> Text::ParseWords, and Data::Dumper,
> > I might be missing something but they all seem to be in perl core:
> I think Russ means they are not part of perl-base package, but provided
> by perl/perl-modules in Debian. So packages using them have to depend on
> the full perl package instead of the minimal perl-base package.

Ehm, yeah, right.

I already had the feeling that it was too early when I started to
write this mail. - Sorry.
 
Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   BOFH excuse #9:  doppler effect 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140220102948.gk5...@colleen.colgarra.priv.at

Re: default init on non-Linux platforms

[Ansgar Burchardt]

Hi,

On 02/20/2014 09:57, gregor herrmann wrote:
> On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:
>> That package does currently depend on
>> perl, though, which isn't appropriate for an essential package.
>> ...  The dependency is because
>> deb-systemd-helper uses a bunch of modules that are not currently in
>> perl-core (File::Path, File::Basename, File::Find, File::Temp,
>> Text::ParseWords, and Data::Dumper,
> 
> I might be missing something but they all seem to be in perl core:

I think Russ means they are not part of perl-base package, but provided
by perl/perl-modules in Debian. So packages using them have to depend on
the full perl package instead of the minimal perl-base package.

However this could be fixed by moving the additional modules to
perl-base (increasing its size slightly) or changing the implementation
to not use them.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5305d04c.4080...@debian.org

Re: default init on non-Linux platforms

[gregor herrmann]

On Wed, 19 Feb 2014 21:30:44 -0800, Russ Allbery wrote:

> That package does currently depend on
> perl, though, which isn't appropriate for an essential package.
> ...  The dependency is because
> deb-systemd-helper uses a bunch of modules that are not currently in
> perl-core (File::Path, File::Basename, File::Find, File::Temp,
> Text::ParseWords, and Data::Dumper,

I might be missing something but they all seem to be in perl core:

% for m in File::Path File::Basename File::Find File::Temp Text::ParseWords 
Data::Dumper ; do corelist $m ; done

Data for 2014-01-09
File::Path was first released with perl 5.001

Data for 2014-01-09
File::Basename was first released with perl 5

Data for 2014-01-09
File::Find was first released with perl 5

Data for 2014-01-09
File::Temp was first released with perl v5.6.1

Data for 2014-01-09
Text::ParseWords was first released with perl 5

Data for 2014-01-09
Data::Dumper was first released with perl 5.005


Cheers,
gregor


-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   BOFH excuse #59:  failed trials, system needs redesigned 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140220085738.gj5...@colleen.colgarra.priv.at

Re: default init on non-Linux platforms

[Russ Allbery]

hero...@gentoo.org writes:

> Forking was a decision made by me in the early phase of packaging
> OpenRC. At that time I referred to the way file-rc handled update-rc.d
> as in

>  sysvinit: /usr/share/sysvinit/update-rc.d

> A central package providing update-rc.d and invoke-rc.d is nice. Though
> it should not be sysv-rc, which OpenRC is intending to replace.

One possibility would be to move those programs to init-system-helpers,
since that is, after all, the point of that package (even if right now
it's only used for systemd glue).  That package does currently depend on
perl, though, which isn't appropriate for an essential package.  I'm not
sure the best way to approach that.  The dependency is because
deb-systemd-helper uses a bunch of modules that are not currently in
perl-core (File::Path, File::Basename, File::Find, File::Temp,
Text::ParseWords, and Data::Dumper, although the last is only used for
debugging and could be loaded on demand if available and skipped
otherwise).

File::Path and File::Basename can be easily replaced with some short
functions and simple regexes, but the rest are a bit harder to replace.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r46y8i63@windlord.stanford.edu

Re: default init on non-Linux platforms

[heroxbd]

Hi Tollef,

Tollef Fog Heen  writes:

> It's probably better to just contribute your changes to the sysv-rc
> version and so make that one able to manage openrc in addition to the
> others it already knows how to.  No point in forking it.

Forking was a decision made by me in the early phase of packaging
OpenRC. At that time I referred to the way file-rc handled update-rc.d
as in

 sysvinit: /usr/share/sysvinit/update-rc.d

A central package providing update-rc.d and invoke-rc.d is nice. Though
it should not be sysv-rc, which OpenRC is intending to replace.

Cheers,
Benda


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86a9dmbbtp@moguhome00.in.awa.tohoku.ac.jp

Re: default init on non-Linux platforms

[Tollef Fog Heen]

]] Thomas Goirand 

> How come? I just took what was in the sysinit package! Or probably, what
> you are talking about is new features, which I should merge it back into
> the OpenRC version?

It's probably better to just contribute your changes to the sysv-rc
version and so make that one able to manage openrc in addition to the
others it already knows how to.  No point in forking it.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m2ppmi4cvu@rahvafeir.err.no

Re: default init on non-Linux platforms

[Kevin Chadwick]

previously on this list Thomas Goirand contributed:

> So, systemd is still using /etc/rc?.d. Could you tell exactly what it
> uses out of /etc/rc?.d, and what for? Does it only needs to see them as
> S??script-name in runlevel 2 or 4 (or whatever it uses...)?
> 
> If systemd needs links in /etc/rcX.d, then I think it should be possible
> to hack something.

One of the main things I like about OpenRC and especially OpenBSDs rc
system is that you can modify the files directly intuitively.

The main thing I hate about the current system is those links and them
requiring a tool to edit them in any timely fashion. Almost as much as
the huge commandlines needed to do so for systemd without it's tools
or for things it's tools can't or couldn't do at the time I tested it
out, if I remember rightly to do with
org.??? lines.

Do people use all those runlevels?

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/494637.19636...@smtp114.mail.ir2.yahoo.com

Press updates [Was: Re: default init on non-Linux platforms]

[Neil McGovern]

On Wed, Feb 19, 2014 at 03:45:12PM +, Dimitri John Ledkov wrote:
> On 19 February 2014 15:28, Ondřej Surý  wrote:
> > are you aware that media are already quoting your blogpost as official
> > announcement of next Debian codename?
> >
> 
> Nah, wasn't aware =) I blame Neil, I thought he still was a release manager 
> ;-)
> Any reason, not to make it official? =)
> 

You should read your lovely bits mails more carefully then :) I also
wouldn't call phoronix "the media". And on a slight tangent, I'd always
welcome more people who are interested in the press and publicity team
:)

Neil
-- 


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

[Matthias Urlichs]

Hi,

The Wanderer:
> > Nah, wasn't aware =) I blame Neil, I thought he still was a release
> > manager ;-) Any reason, not to make it official? =)
> 
> Well, back in 2002 there was a probably-joking sort-of decision that
> "zurg" should be the codename of the release where the Hurd and *BSD
> ports were fully ready [1].

Only 14 years late, then. (Assuming it'll be ready sometime in 2016.)

Let's put it this way: we're unlikely to exceed that delay any time soon.

> I like the idea (and the method of choosing, and of announcing, it)
> otherwise, though.

+1

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/19/2014 11:53 PM, Simon McVittie wrote:
> I suspect the right thing would be to share one implementation of
> update-rc.d(8), invoke-rc.d(8) and possibly service(8) between all
> supported init implementations, provided by either src:sysvinit or
> src:init-system-helpers.

Surprisingly, "service" is shared among all init systems (it's in
sysvinit-utils), while the other 2 are not.

I agree we should have a common interface and make sure one daemon
remains enabled / disabled in all init systems.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5304e53b.9050...@debian.org

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/19/2014 10:47 PM, Michael Biebl wrote:
> Am 19.02.2014 00:52, schrieb Russ Allbery:
>> Henrique de Moraes Holschuh  writes:
>>
>>> They *HAVE* to be provided by the active init system.  They are an
>>> impedance matching layer (aka stable API) used by maintainer scripts to
>>> interface with the active init system.
>>
>> If you look at the existing implementation, you'll find that the version
>> provided by sysv-rc already supports systemd, upstart, and sysv-rc itself.
>> So this isn't precisely true.  If we stick with the current model, then
>> some (probably essential) package just needs to provide those
>> implementations and accept patches to work with new init systems, but each
>> init system doesn't need to provide its own version.
>>
>> There are some advantages to providing only one version with knowledge of
>> all of the init systems given that we're supporting init system switching,
>> and therefore may need to set up state for init systems that aren't
>> currently running so that switching can work properly.  A good example is
>> registering an init script with insserv so that the correct S and K links
>> are created even if the system is currently booted with a different init
>> system.
> 
> If you look at e.g. update-rc.d enable|disable, it currently has support
> for systemd, upstart and sysv-rc. So whenever you enable a service, this
> state is kept in sync across the different init systems (assuming the
> service in question ships native support for other init systems).
> 
> I don't find equivalent functionality in openrc's implementation of
> update-rc.d

How come? I just took what was in the sysinit package! Or probably, what
you are talking about is new features, which I should merge it back into
the OpenRC version?

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5304e46b.8050...@debian.org

Re: New debian "codename" (Was: default init on non-Linux platforms)

[Ondřej Surý]

On Wed, Feb 19, 2014, at 17:09, Dimitri John Ledkov wrote:
> On 19 February 2014 16:05, Ondřej Surý  wrote:
> > On Wed, Feb 19, 2014, at 16:57, The Wanderer wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA512
> >>
> >> On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:
> >>
> >> > On 19 February 2014 15:28, Ondřej Surý  wrote:
> >> >
> >> >> Dimitri,
> >>
> >> >> are you aware that media are already quoting your blogpost as
> >> >> official announcement of next Debian codename?
> >> >
> >> > Nah, wasn't aware =) I blame Neil, I thought he still was a release
> >> > manager ;-) Any reason, not to make it official? =)
> >
> > And obviously the phoronix and others thought you are on the release
> > team and you have a say about next codename (since you have blogged
> > about it, it must be true). *palmface* (not targeted at Neil nor
> > Dimitri...)
> >
> >> Well, back in 2002 there was a probably-joking sort-of decision that
> >> "zurg" should be the codename of the release where the Hurd and *BSD
> >> ports were fully ready [1]. Given that we seem to be moving more towards
> >> dropping ports than finalizing them at the moment, using the name zurg
> >> would not seem to be in keeping with that idea.
> >>
> >> [1] https://lists.debian.org/debian-devel/2002/07/msg01139.html
> >>
> >> I like the idea (and the method of choosing, and of announcing, it)
> >> otherwise, though.
> >
> > Well, it makes me really sad how little effort the current journalists
> > make to verify the claims. Dimitry blogs some insider joke and it's
> > already on phoronix. And since it's written on the internet it must be
> > true. *double palmface*
> >
> 
> Wait, wait, somebody needs to edit Debian's wikipedia article with
> citations, for it to be _triple_ official and verified =)))

That should have been your first step: https://xkcd.com/978/

:-P

Ondrej
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1392826366.9816.85310137.7f3d3...@webmail.messagingengine.com

Re: New debian "codename" (Was: default init on non-Linux platforms)

[Dimitri John Ledkov]

On 19 February 2014 16:05, Ondřej Surý  wrote:
> On Wed, Feb 19, 2014, at 16:57, The Wanderer wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:
>>
>> > On 19 February 2014 15:28, Ondřej Surý  wrote:
>> >
>> >> Dimitri,
>>
>> >> are you aware that media are already quoting your blogpost as
>> >> official announcement of next Debian codename?
>> >
>> > Nah, wasn't aware =) I blame Neil, I thought he still was a release
>> > manager ;-) Any reason, not to make it official? =)
>
> And obviously the phoronix and others thought you are on the release
> team and you have a say about next codename (since you have blogged
> about it, it must be true). *palmface* (not targeted at Neil nor
> Dimitri...)
>
>> Well, back in 2002 there was a probably-joking sort-of decision that
>> "zurg" should be the codename of the release where the Hurd and *BSD
>> ports were fully ready [1]. Given that we seem to be moving more towards
>> dropping ports than finalizing them at the moment, using the name zurg
>> would not seem to be in keeping with that idea.
>>
>> [1] https://lists.debian.org/debian-devel/2002/07/msg01139.html
>>
>> I like the idea (and the method of choosing, and of announcing, it)
>> otherwise, though.
>
> Well, it makes me really sad how little effort the current journalists
> make to verify the claims. Dimitry blogs some insider joke and it's
> already on phoronix. And since it's written on the internet it must be
> true. *double palmface*
>

Wait, wait, somebody needs to edit Debian's wikipedia article with
citations, for it to be _triple_ official and verified =)))

-- 
Regards,

Dimitri.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANBHLUgNmZbhrW1_RY=f+6nabx-vcpj+-qf5kid2rtqisvi...@mail.gmail.com

Re: default init on non-Linux platforms

[Dimitri John Ledkov]

On 19 February 2014 15:57, The Wanderer  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:
>
>> On 19 February 2014 15:28, Ondřej Surý  wrote:
>>
>>> Dimitri,
>
>>> are you aware that media are already quoting your blogpost as
>>> official announcement of next Debian codename?
>>
>> Nah, wasn't aware =) I blame Neil, I thought he still was a release
>> manager ;-) Any reason, not to make it official? =)
>
> Well, back in 2002 there was a probably-joking sort-of decision that
> "zurg" should be the codename of the release where the Hurd and *BSD
> ports were fully ready [1]. Given that we seem to be moving more towards
> dropping ports than finalizing them at the moment, using the name zurg
> would not seem to be in keeping with that idea.
>
> I like the idea (and the method of choosing, and of announcing, it)
> otherwise, though.
>

To be honest Zurg is living up to it's expectations. kFreeBSD is
looking very solid on jessie already, and it can only get better by
Zurg time. Initial porting work is done, and now work is mostly put
into polishing and providing new features. It really is something i'm
comfortable running as my main server. And given Zurg's ambitious
plans drafted today the name is both suitable and telling as predicted
back then.

And if scope is limitted to virtual machines / cloud instances - Hurd
also looks very good.

-- 
Regards,

Dimitri.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANBHLUiB==jdfc1sjchgnitacorzraa966cwfu6vuagaekq...@mail.gmail.com

New debian "codename" (Was: default init on non-Linux platforms)

[Ondřej Surý]

On Wed, Feb 19, 2014, at 16:57, The Wanderer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:
> 
> > On 19 February 2014 15:28, Ondřej Surý  wrote:
> > 
> >> Dimitri,
> 
> >> are you aware that media are already quoting your blogpost as
> >> official announcement of next Debian codename?
> > 
> > Nah, wasn't aware =) I blame Neil, I thought he still was a release
> > manager ;-) Any reason, not to make it official? =)

And obviously the phoronix and others thought you are on the release
team and you have a say about next codename (since you have blogged
about it, it must be true). *palmface* (not targeted at Neil nor
Dimitri...)

> Well, back in 2002 there was a probably-joking sort-of decision that
> "zurg" should be the codename of the release where the Hurd and *BSD
> ports were fully ready [1]. Given that we seem to be moving more towards
> dropping ports than finalizing them at the moment, using the name zurg
> would not seem to be in keeping with that idea.
> 
> [1] https://lists.debian.org/debian-devel/2002/07/msg01139.html
> 
> I like the idea (and the method of choosing, and of announcing, it)
> otherwise, though.

Well, it makes me really sad how little effort the current journalists
make to verify the claims. Dimitry blogs some insider joke and it's
already on phoronix. And since it's written on the internet it must be
true. *double palmface*

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1392825915.7856.85305641.6b618...@webmail.messagingengine.com

Re: default init on non-Linux platforms

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:

> On 19 February 2014 15:28, Ondřej Surý  wrote:
> 
>> Dimitri,

>> are you aware that media are already quoting your blogpost as
>> official announcement of next Debian codename?
> 
> Nah, wasn't aware =) I blame Neil, I thought he still was a release
> manager ;-) Any reason, not to make it official? =)

Well, back in 2002 there was a probably-joking sort-of decision that
"zurg" should be the codename of the release where the Hurd and *BSD
ports were fully ready [1]. Given that we seem to be moving more towards
dropping ports than finalizing them at the moment, using the name zurg
would not seem to be in keeping with that idea.

I like the idea (and the method of choosing, and of announcing, it)
otherwise, though.


[1] https://lists.debian.org/debian-devel/2002/07/msg01139.html

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTBNSBAAoJEASpNY00KDJrxTkP/2JtWJDGwrw+EXNaUBE5fFv+
zjWMPUqmCZgvaS/LUe8aiwbPUGXXy18pyIQwsHH30XPcouCQTbX7K1I8PuUekMc1
E4axQ6F5/aFZHki1n1VxWqW3VUxPU+hDP4CpPr+OymSQDkXduMir2WXYx1JMyYKR
405zV2NjirFuwS9ldD/EaEA5zCXAK2KSw1KG3KVRJN3N/r2/y1nxomJ9B6lMuUJT
RrjlCg3DYuwWQGMDHuA3OAnIxRP/qI2EkNp5qPCY6zAsZf4co8PDrjsC/4cx4AVo
Zqu6FDkR+vROzhF7+016s2buVUsGmExDysY1dNaflXGB3A0jpIBcEQ0qxXuYbR1a
Eo0CSn34+7DuMCeIYslW7vtEviAH4K5gxt4kAQTqU65OVGGEUDCaj3T8VwQ0bb5l
BD5YryZA/bXdBXVZm3geGa9Ft41Bg2WGqd5G1/muvmc+yP0oocWmTnDJaEqBSDaH
sp5YvVVXgK7G7azMvCjpL0M2gXAoaDcPjsoG/9D8jEThnVshk3fmu1EgsCxnecR+
qY1fBhCP88GpSXSc2jb0cPvGFIZJSH6V7q2r9ZUniT9wsL53rq5mGnM6soM+Gn/c
uz+5IK2gc5yO1o/besgkGGFd3RbIrYEvFOqjfdJIqexV4Lrw2r8LH1rOX66gaSB1
4Ephwd895xZzC/5wP4Tj
=wIwk
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5304d481.9000...@fastmail.fm

Re: default init on non-Linux platforms

[Simon McVittie]

On 19/02/14 15:09, Thomas Goirand wrote:
> First, yes, OpenRC uses /etc/runlevel, with the folders below that being
> the *names* of the runlevel (which IMO is a way more user friendly than
> just numbers). FYI, we have: shutdown=0, recovery=1, reboot=6, and
> everything-else=default. So we do have these 4 directory names, and
> OpenRC doesn't care about /etc/rc?.d.

Similar to systemd's multi-user.target etc. (which are made to depend on
native systemd units), then. However, systemd still needs to know
whether an LSB init script with no corresponding systemd unit should be
started or not, which it does by looking in /etc/rcX.d (I think it
assuems that anything started in any of rc[2345].d should be included in
multi-user.target).

> If systemd needs links in /etc/rcX.d, then I think it should be possible
> to hack something.

I suspect the right thing would be to share one implementation of
update-rc.d(8), invoke-rc.d(8) and possibly service(8) between all
supported init implementations, provided by either src:sysvinit or
src:init-system-helpers. The implementations in sysv-rc and
sysvinit-utils already seem to support sysv-rc[1], systemd and Upstart;
teaching them about OpenRC shouldn't be rocket science.

This has the advantage that if you install a daemon while your init is
sysvinit/sysv-rc, enable and/or disable it, then switch to systemd or
OpenRC and reboot, that daemon remains enabled or disabled (as appropriate).

S

[1] and probably file-rc for that matter


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5304d35e.20...@debian.org

Re: default init on non-Linux platforms

[Dimitri John Ledkov]

On 19 February 2014 15:28, Ondřej Surý  wrote:
> Dimitri,
>
> On Wed, Feb 19, 2014, at 12:57, Dimitri John Ledkov wrote:
>> On 19 February 2014 11:22, Neil McGovern  wrote:
>> > On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
>> >> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
>> >> > On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
>> >> > > [0] Can we haz a release name?
>> >> > >
>> >> >
>> >> > Sure. It's Debian 8.0, "zurg". [0]
>> >> >
>> >> > Neil
>> >> > [0] Note: may be a lie.
>> >>
>> >> Umm, Debian 9.0?
>> >>
>> >
>> > For those who may not be following along at home, I'm no longer a
>> > release manager. I don't get to pick release names. The use of 8.0 was
>> > deliberate to try and make it clearer that I have no say in the matter.
>> >
>>
>> But it's such a good name!
>
> are you aware that media are already quoting your blogpost as official
> announcement of next Debian codename?
>

Nah, wasn't aware =) I blame Neil, I thought he still was a release manager ;-)
Any reason, not to make it official? =)

-- 
Regards,

Dimitri.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANBHLUjk=szx4ztfxwzhjnyxptgeovtqtbesa_cf_dnuqyj...@mail.gmail.com

Re: default init on non-Linux platforms

[Ondřej Surý]

Dimitri,

On Wed, Feb 19, 2014, at 12:57, Dimitri John Ledkov wrote:
> On 19 February 2014 11:22, Neil McGovern  wrote:
> > On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
> >> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
> >> > On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
> >> > > [0] Can we haz a release name?
> >> > >
> >> >
> >> > Sure. It's Debian 8.0, "zurg". [0]
> >> >
> >> > Neil
> >> > [0] Note: may be a lie.
> >>
> >> Umm, Debian 9.0?
> >>
> >
> > For those who may not be following along at home, I'm no longer a
> > release manager. I don't get to pick release names. The use of 8.0 was
> > deliberate to try and make it clearer that I have no say in the matter.
> >
> 
> But it's such a good name!

are you aware that media are already quoting your blogpost as official
announcement of next Debian codename?

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1392823700.31129.85290293.71ac1...@webmail.messagingengine.com

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/19/2014 10:44 PM, Michael Biebl wrote:
> I'd like to add that switching to openrc breaks the SysV/LSB support in
> systemd. Openrc doesn't use the /etc/rc?.d/ directories to create the
> symlinks which signal if a service is active for a given runlevel.
> (those symlinks are created in /etc/runlevel/* afaics)
> 
> This means systemd doesn't consider the SysV/LSB init script as enabled
> and won't start it on boot.

Oh, that's interesting!

First, yes, OpenRC uses /etc/runlevel, with the folders below that being
the *names* of the runlevel (which IMO is a way more user friendly than
just numbers). FYI, we have: shutdown=0, recovery=1, reboot=6, and
everything-else=default. So we do have these 4 directory names, and
OpenRC doesn't care about /etc/rc?.d.

Could you expand the above text and give a bit more explanations /
details? :)

So, systemd is still using /etc/rc?.d. Could you tell exactly what it
uses out of /etc/rc?.d, and what for? Does it only needs to see them as
S??script-name in runlevel 2 or 4 (or whatever it uses...)?

If systemd needs links in /etc/rcX.d, then I think it should be possible
to hack something.

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5304c91a.1090...@debian.org

Re: default init on non-Linux platforms

[Michael Biebl]

Am 19.02.2014 00:52, schrieb Russ Allbery:
> Henrique de Moraes Holschuh  writes:
> 
>> They *HAVE* to be provided by the active init system.  They are an
>> impedance matching layer (aka stable API) used by maintainer scripts to
>> interface with the active init system.
> 
> If you look at the existing implementation, you'll find that the version
> provided by sysv-rc already supports systemd, upstart, and sysv-rc itself.
> So this isn't precisely true.  If we stick with the current model, then
> some (probably essential) package just needs to provide those
> implementations and accept patches to work with new init systems, but each
> init system doesn't need to provide its own version.
> 
> There are some advantages to providing only one version with knowledge of
> all of the init systems given that we're supporting init system switching,
> and therefore may need to set up state for init systems that aren't
> currently running so that switching can work properly.  A good example is
> registering an init script with insserv so that the correct S and K links
> are created even if the system is currently booted with a different init
> system.

If you look at e.g. update-rc.d enable|disable, it currently has support
for systemd, upstart and sysv-rc. So whenever you enable a service, this
state is kept in sync across the different init systems (assuming the
service in question ships native support for other init systems).

I don't find equivalent functionality in openrc's implementation of
update-rc.d



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: default init on non-Linux platforms

[Michael Biebl]

Am 18.02.2014 19:18, schrieb Didier 'OdyX' Raboud:
> Le mercredi, 19 février 2014, 00.56:07 Thomas Goirand a écrit :
>> On 02/18/2014 11:10 PM, Jonathan Dowland wrote:
>>> On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
 Once I consider OpenRC ready for it, would it be ok to just replace
 sysv-rc by OpenRC, and transform sysv-rc into a transitional
 package?
 What is the opinion of other DDs? Is there anyone which would like
 to
 keep the old featureless sysv-rc?
>>>
>>> What problem does that solve?
>>
>> In this way, we'd have only 2 init systems to take care of, and we
>> could start replacing init.d scripts by OpenRC runscripts *IF*
>> there's a systemd service file.
> 
> Yes. And three different daemon-starting syntaxes to manage the Wheezy-
> to-Jessie upgrades.
> 
> Again, for Jessie, I don't think it's reasonable to change the default 
> init _and_ replace the common baseline. I, for one, am not going to 
> replace my awkward-but-working sysvinit scripts by anything but 
> systemd/upstart unit files and that is doomed to happen in jessie+1 [0].

I'd like to add that switching to openrc breaks the SysV/LSB support in
systemd. Openrc doesn't use the /etc/rc?.d/ directories to create the
symlinks which signal if a service is active for a given runlevel.
(those symlinks are created in /etc/runlevel/* afaics)

This means systemd doesn't consider the SysV/LSB init script as enabled
and won't start it on boot.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: default init on non-Linux platforms

[Dimitri John Ledkov]

On 19 February 2014 11:22, Neil McGovern  wrote:
> On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
>> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
>> > On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
>> > > [0] Can we haz a release name?
>> > >
>> >
>> > Sure. It's Debian 8.0, "zurg". [0]
>> >
>> > Neil
>> > [0] Note: may be a lie.
>>
>> Umm, Debian 9.0?
>>
>
> For those who may not be following along at home, I'm no longer a
> release manager. I don't get to pick release names. The use of 8.0 was
> deliberate to try and make it clearer that I have no say in the matter.
>

But it's such a good name!

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/canbhluhsjcqzxh3l1yrzduzl6ahxwsurgjzyfgxzvkwmodm...@mail.gmail.com

Re: default init on non-Linux platforms

[Neil McGovern]

On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
> > On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
> > > [0] Can we haz a release name?
> > > 
> > 
> > Sure. It's Debian 8.0, "zurg". [0]
> > 
> > Neil
> > [0] Note: may be a lie.
> 
> Umm, Debian 9.0?
> 

For those who may not be following along at home, I'm no longer a
release manager. I don't get to pick release names. The use of 8.0 was
deliberate to try and make it clearer that I have no say in the matter.

Neil
-- 


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

[Chris Bannister]

On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
> On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
> > [0] Can we haz a release name?
> > 
> 
> Sure. It's Debian 8.0, "zurg". [0]
> 
> Neil
> [0] Note: may be a lie.

Umm, Debian 9.0?

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140219103708.GE28892@tal

Re: default init on non-Linux platforms

[Matthias Urlichs]

Hi,

Thomas Goirand:
> > [0] Can we haz a release name?
> 
> It's been years that I've been asking that we have the release name a
> way sooner. Ideally, one release earlier, so that we can prepare for the
> new name soon enough (and not fix things during the freeze). But the
> release team doesn't seem to agree with this! :)
> 
I'm all for going with "zurg" here.

This transition mentions jessie+1 so often that naming it now make sense.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

[Russ Allbery]

Thomas Goirand  writes:
> On 02/19/2014 08:05 AM, Henrique de Moraes Holschuh wrote:
>> On Tue, 18 Feb 2014, Russ Allbery wrote:

>>> There are some advantages to providing only one version with knowledge
>>> of all of the init systems given that we're supporting init system
>>> switching, and therefore may need to set up state for init systems
>>> that aren't currently running so that switching can work properly.  A
>>> good example is registering an init script with insserv so that the
>>> correct S and K links are created even if the system is currently
>>> booted with a different init system.

>> I agree.

> I agree as well, but it's simply not what is currently being done.
> Currently, sysv-rc & OpenRC both provide update-rc.d and invoke-rc.d. If
> we could move them to sysvinit-utils, why not. It'd be also nice to have
> invoke-rc.d write the symlinks in /run/openrc/started no mater what, so
> that OpenRC could know how to shutdown quickly after switching init
> system. Note that I already patched the "service" tool for this, but it
> will only do something if /run/openrc/started exists as a folder.
> Suggestions welcome.

If it improves integration with OpenRC, I'm in favor of modifying the
current invoke-rc.d to support this.  I think moving update-rc.d and
invoke-rc.d to a generic package and using them across all of our
supported init systems makes the most sense.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bny38sw1@windlord.stanford.edu

Re: default init on non-Linux platforms

[Thomas Goirand]

Hi,

I'm replying to everyone in a single mail, I hope that's fine. I'm
therefore a bit repeating myself, sorry for that.

On 02/19/2014 02:18 AM, Didier 'OdyX' Raboud wrote:
> Le mercredi, 19 février 2014, 00.56:07 Thomas Goirand a écrit :
>> On 02/18/2014 11:10 PM, Jonathan Dowland wrote:
>>> On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
 Once I consider OpenRC ready for it, would it be ok to just replace
 sysv-rc by OpenRC, and transform sysv-rc into a transitional
 package?
 What is the opinion of other DDs? Is there anyone which would like
 to
 keep the old featureless sysv-rc?
>>>
>>> What problem does that solve?
>>
>> In this way, we'd have only 2 init systems to take care of, and we
>> could start replacing init.d scripts by OpenRC runscripts *IF*
>> there's a systemd service file.
> 
> Yes. And three different daemon-starting syntaxes to manage the Wheezy-
> to-Jessie upgrades.
> 
> Again, for Jessie, I don't think it's reasonable to change the default 
> init _and_ replace the common baseline. I, for one, am not going to 
> replace my awkward-but-working sysvinit scripts by anything but 
> systemd/upstart unit files and that is doomed to happen in jessie+1 [0].

I agree. My idea is that we shouldn't change any init.d script in the
favor of OpenRC before sysv-rc is deprecated by one of the new stable
release.

> [0] Can we haz a release name?

It's been years that I've been asking that we have the release name a
way sooner. Ideally, one release earlier, so that we can prepare for the
new name soon enough (and not fix things during the freeze). But the
release team doesn't seem to agree with this! :)

On 02/19/2014 01:33 AM, Gergely Nagy wrote:
> From a maintainer PoV, I already maintain sysvinit scripts for wheezy,
> and upstream, they will have to be maintained for the forseeable
> future anyway, so maintaining it for Jessie is exactly zero work on
> my part.
>
> Adding OpenRC to the mix (something I'm not familiar with, and I'm not
> really interested in getting to know better, either) is an extra
> burden I wouldn't want to do myself.

Then great, because I am not proposing to change any init.d script right
now, at least not before OpenRC officially replaces sysv-rc. And OpenRC
is fully compatible with init.d scripts, transforming them into
runscript is optional, and IMO, not something we should do before
sysv-rc is gone.

> I wouldn't say no to a patch
> adding an OpenRC runscript, of course, but I'd rather not do it
> myself.

Thanks!

On 02/19/2014 02:12 AM, Didier 'OdyX' Raboud wrote:
> Le mercredi, 19 février 2014, 01.11:21 Thomas Goirand a écrit :
>> Actually, thinking about it a 2nd time, I think there would be a major
>> drawback in delaying to Jessie +1. If we decide that sysv-rc goes
>> away, then starting at the Jessie release, we don't have to care
>> anymore about LSB header scripts. Meaning that we could write systemd
>> service files, plus OpenRC runscripts (for those who cares about
>> OpenRC, or our non-linux ports).
>>
>> If we delay it, this means that we'd have to keep maintaining LSB
>> header scripts in Sid for all the life of Jessie (for those who cares
>> about non-linux ports or having OpenRC / sysv-rc support).
>
> I don't think that's true. If we decide that sysvinit scripts (hence
> LSB  headers) have to be supported in jessie but are deprecated, then
> jessie+1 can start to drop them completely (given reasonable
> replacement  for non-init defaults of course). Dropping them in the
> jessie suite would complicate the upgrade path from Wheezy for no
> reason that I would  value high enough.

One of us is not understanding the other here. I believe this should be
because I don't express myself well enough (this wouldn't be the first
time...). So I'll try once more:

I thing we should *not* replace any LSB header init.d scripts before
Jessie, and make them mandatory for the release. At the same time, I
think we should replace sysv-rc by OpenRC for Jessie [1]. This way,
after the release, we'd be sure there wouldn't be any sysv-rc setup out
there, and replacing LSB headers would be possible (and recommended).

On 02/19/2014 06:07 AM, Adam Borowski wrote:
> Idea: someone is working on a service->runscript interpreter, for a
> subset of common functionality.  If that tool could have a validator
> that returns ok if there's no unsupported stanza, what about running
> that validator in lintian and screaming if validation fails but there
> is no runscript?
>
> This way, there'd be three kinds of packages:
> * LSB only
> * service that's palatable for OpenRC
> * service + runscript
>
> This would greatly simplify preparing for deprecation of sysv-rc.
> Hopefully somewhere to the tune of 90-95% packages having just one
> daemon definition. Such a reduction of work could make dropping
> sysv-rc in jessie viable.

I think this could be a good idea to have such a tool. I see 3 ways to
implement it.
1/ A userland tool to generate stuff onc

Re: default init on non-Linux platforms

[Steven Chamberlain]

Apparently sysvinit scripts must be retained anyway for a smooth
migration to jessie;  also for easy backporting of jessie packages to
wheezy, and maybe other reasons.  Non-Linux ports are likely to use
those SysV init scripts, though we might invoke them from something
other than sysvinit.

I know some maintainers would like SysV init scripts to disappear, but
the earliest I think that can happen for existing packages would be
jessie+1.  In that case, we should try to plan for a similar migration
from jessie to jessie+1.

It's difficult to predict so far ahead, but if it will be a migration to
OpenRC, maybe jessie should try to have OpenRC already in place, so that
it will be able to use jessie+1's runscripts when they appear and be
able to shut down cleanly when SysV init scripts are gone.

(I think Thomas was describing the same situation in the context of sid)

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5303f898.7070...@pyro.eu.org

Re: default init on non-Linux platforms

[Henrique de Moraes Holschuh]

On Tue, 18 Feb 2014, Russ Allbery wrote:
> Henrique de Moraes Holschuh  writes:
> > They *HAVE* to be provided by the active init system.  They are an
> > impedance matching layer (aka stable API) used by maintainer scripts to
> > interface with the active init system.
> 
> If you look at the existing implementation, you'll find that the version
> provided by sysv-rc already supports systemd, upstart, and sysv-rc itself.
> So this isn't precisely true.  If we stick with the current model, then
> some (probably essential) package just needs to provide those

Hmm, we can provide one, yes.  Probably in sysvinit-utils, which already has
some important tools that are not strictly related to sysvinit itself.

> There are some advantages to providing only one version with knowledge of
> all of the init systems given that we're supporting init system switching,
> and therefore may need to set up state for init systems that aren't
> currently running so that switching can work properly.  A good example is
> registering an init script with insserv so that the correct S and K links
> are created even if the system is currently booted with a different init
> system.

I agree.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140219000552.ga17...@khazad-dum.debian.net

Re: default init on non-Linux platforms

[Russ Allbery]

Henrique de Moraes Holschuh  writes:

> They *HAVE* to be provided by the active init system.  They are an
> impedance matching layer (aka stable API) used by maintainer scripts to
> interface with the active init system.

If you look at the existing implementation, you'll find that the version
provided by sysv-rc already supports systemd, upstart, and sysv-rc itself.
So this isn't precisely true.  If we stick with the current model, then
some (probably essential) package just needs to provide those
implementations and accept patches to work with new init systems, but each
init system doesn't need to provide its own version.

There are some advantages to providing only one version with knowledge of
all of the init systems given that we're supporting init system switching,
and therefore may need to set up state for init systems that aren't
currently running so that switching can work properly.  A good example is
registering an init script with insserv so that the correct S and K links
are created even if the system is currently booted with a different init
system.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bny4ou68@windlord.stanford.edu

Re: default init on non-Linux platforms

[Henrique de Moraes Holschuh]

On Tue, 18 Feb 2014, Tollef Fog Heen wrote:
> > Once I consider OpenRC ready for it, would it be ok to just replace
> > sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
> 
> No, update-rc.d and invoke-rc.d still need to be provided by something.

They *HAVE* to be provided by the active init system.  They are an impedance
matching layer (aka stable API) used by maintainer scripts to interface with
the active init system.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140218234420.ga17...@khazad-dum.debian.net

[OT]: zurg (was Re: default init on non-Linux platforms)

[gustavo panizzo]

On 02/18/2014 03:31 PM, Neil McGovern wrote:
> On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
>> [0] Can we haz a release name?
>>
> Sure. It's Debian 8.0, "zurg". [0]
finally one of the 'bad' guys!

[*]  as a release, sid don't apply
>
> Neil
> [0] Note: may be a lie.


-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5303dbe1.1050...@zumbi.com.ar

Re: default init on non-Linux platforms

[Adam Borowski]

On Wed, Feb 19, 2014 at 01:11:21AM +0800, Thomas Goirand wrote:
> Actually, thinking about it a 2nd time, I think there would be a major
> drawback in delaying to Jessie +1. If we decide that sysv-rc goes away,
> then starting at the Jessie release, we don't have to care anymore about
> LSB header scripts. Meaning that we could write systemd service files,
> plus OpenRC runscripts (for those who cares about OpenRC, or our
> non-linux ports).

Idea: someone is working on a service->runscript interpreter, for a subset
of common functionality.  If that tool could have a validator that returns
ok if there's no unsupported stanza, what about running that validator in
lintian and screaming if validation fails but there is no runscript?

This way, there'd be three kinds of packages:
* LSB only
* service that's palatable for OpenRC
* service + runscript

This would greatly simplify preparing for deprecation of sysv-rc.  Hopefully
somewhere to the tune of 90-95% packages having just one daemon definition.
Such a reduction of work could make dropping sysv-rc in jessie viable.

> If we delay it, this means that we'd have to keep maintaining LSB header
> scripts in Sid for all the life of Jessie (for those who cares about
> non-linux ports or having OpenRC / sysv-rc support).

If we need to suffer systemd but can't use the main benefit of new-style
init systems, what the whole brouchacha was for?  As OpenRC is supposed to
be a drop-in replacement, and upstart has dropped the towel, migrating by
Jessie would allow supporting only two init systems by Zurg¹ with nothing
but 1.05 declarative definition per daemon package.


[¹]. What do you mean, neilm doesn't get to name jessie+1?
-- 
A tit a day keeps the vet away.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140218220732.gb31...@angband.pl

Re: default init on non-Linux platforms

[Andrew Shadura]

Hello,

On Tue, 18 Feb 2014 19:59:13 +0100
Tollef Fog Heen  wrote:

> > Once I consider OpenRC ready for it, would it be ok to just replace
> > sysv-rc by OpenRC, and transform sysv-rc into a transitional
> > package?
 
> No, update-rc.d and invoke-rc.d still need to be provided by
> something.
 
OpenRC provides them.


-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140218200708.6965c22a@ileemo

Re: default init on non-Linux platforms

[Tollef Fog Heen]

]] Thomas Goirand 


> Once I consider OpenRC ready for it, would it be ok to just replace
> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?

No, update-rc.d and invoke-rc.d still need to be provided by something.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m2r4706yda@rahvafeir.err.no

Re: default init on non-Linux platforms

[Neil McGovern]

On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
> [0] Can we haz a release name?
> 

Sure. It's Debian 8.0, "zurg". [0]

Neil
[0] Note: may be a lie.


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

[Didier 'OdyX' Raboud]

Le mercredi, 19 février 2014, 00.56:07 Thomas Goirand a écrit :
> On 02/18/2014 11:10 PM, Jonathan Dowland wrote:
> > On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
> >> Once I consider OpenRC ready for it, would it be ok to just replace
> >> sysv-rc by OpenRC, and transform sysv-rc into a transitional
> >> package?
> >> What is the opinion of other DDs? Is there anyone which would like
> >> to
> >> keep the old featureless sysv-rc?
> > 
> > What problem does that solve?
> 
> In this way, we'd have only 2 init systems to take care of, and we
> could start replacing init.d scripts by OpenRC runscripts *IF*
> there's a systemd service file.

Yes. And three different daemon-starting syntaxes to manage the Wheezy-
to-Jessie upgrades.

Again, for Jessie, I don't think it's reasonable to change the default 
init _and_ replace the common baseline. I, for one, am not going to 
replace my awkward-but-working sysvinit scripts by anything but 
systemd/upstart unit files and that is doomed to happen in jessie+1 [0].

Cheers,
OdyX

[0] Can we haz a release name?


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2536787.IXIK3uYTH8@gyllingar

Re: default init on non-Linux platforms

[Didier 'OdyX' Raboud]

Le mercredi, 19 février 2014, 01.11:21 Thomas Goirand a écrit :
> Actually, thinking about it a 2nd time, I think there would be a major
> drawback in delaying to Jessie +1. If we decide that sysv-rc goes
> away, then starting at the Jessie release, we don't have to care
> anymore about LSB header scripts. Meaning that we could write systemd
> service files, plus OpenRC runscripts (for those who cares about
> OpenRC, or our non-linux ports).
> 
> If we delay it, this means that we'd have to keep maintaining LSB
> header scripts in Sid for all the life of Jessie (for those who cares
> about non-linux ports or having OpenRC / sysv-rc support).

I don't think that's true. If we decide that sysvinit scripts (hence LSB 
headers) have to be supported in jessie but are deprecated, then 
jessie+1 can start to drop them completely (given reasonable replacement 
for non-init defaults of course). Dropping them in the jessie suite 
would complicate the upgrade path from Wheezy for no reason that I would 
value high enough.

OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4440019.su1Rqjt91a@gyllingar

Re: default init on non-Linux platforms

[Gergely Nagy]

Thomas Goirand  writes:

> Actually, thinking about it a 2nd time, I think there would be a major
> drawback in delaying to Jessie +1. If we decide that sysv-rc goes away,
> then starting at the Jessie release, we don't have to care anymore about
> LSB header scripts. Meaning that we could write systemd service files,
> plus OpenRC runscripts (for those who cares about OpenRC, or our
> non-linux ports).
>
> If we delay it, this means that we'd have to keep maintaining LSB header
> scripts in Sid for all the life of Jessie (for those who cares about
> non-linux ports or having OpenRC / sysv-rc support).
>
> Thoughts anyone?

>From a maintainer PoV, I already maintain sysvinit scripts for wheezy,
and upstream, they will have to be maintained for the forseeable future
anyway, so maintaining it for Jessie is exactly zero work on my part.

Adding OpenRC to the mix (something I'm not familiar with, and I'm not
really interested in getting to know better, either) is an extra burden
I wouldn't want to do myself. I wouldn't say no to a patch adding an
OpenRC runscript, of course, but I'd rather not do it myself.

-- 
|8]

P.S.: If you're curious, and would like to send OpenRC runscript
patches, syslog-ng-core is the single package in the archive where I
maintain a sysvinit script. ;)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877g8stjem.fsf@algernon.balabit

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/18/2014 11:38 PM, Didier 'OdyX' Raboud wrote:
> Le mardi, 18 février 2014, 22.55:32 Thomas Goirand a écrit :
>> Once I consider OpenRC ready for it, would it be ok to just replace
>> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
>> What is the opinion of other DDs? Is there anyone which would like to
>> keep the old featureless sysv-rc?
> 
> I think we should focus on one init system change at a time.
> 
> Having the good-old sysvinit setup still working in a satisfactory 
> manner is nice while preparing Jessie: that's what Wheezy has and 
> therefore has to be supported to upgrade to Jessie (think partial 
> upgrades, full-upgrade-not-rebooted-yet, etc etc). When testing crazy 
> stuff with systemd, I know I can always fallback to sysvinit if I broke 
> any .socket or .service unit I'm working on. It will be slower and feel 
> old, but would most certainly boot and provide me with comfortable ways 
> to debug. If that was changed to OpenRC, we'd exchange the sysvinit 
> safety net that all got to know in exchange for a brand new safety net 
> that we don't really know yet.
> 
> Moving to OpenRC as the secondary init for Jessie looks like changing 
> the two wheels of a bike at the same time. I'd widely prefer to keep 
> sysvinit (as old it might feel) for Jessie, especially as transition 
> point from Wheezy and have these discussions again after Jessie is 
> released.
> 
> That shouldn't stop you from providing the best OpenRC integration in 
> Debian, be it for the ports or in preparation for jessie+1.
> 
> Cheers,
> OdyX

Actually, thinking about it a 2nd time, I think there would be a major
drawback in delaying to Jessie +1. If we decide that sysv-rc goes away,
then starting at the Jessie release, we don't have to care anymore about
LSB header scripts. Meaning that we could write systemd service files,
plus OpenRC runscripts (for those who cares about OpenRC, or our
non-linux ports).

If we delay it, this means that we'd have to keep maintaining LSB header
scripts in Sid for all the life of Jessie (for those who cares about
non-linux ports or having OpenRC / sysv-rc support).

Thoughts anyone?

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53039439.4060...@debian.org

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/18/2014 11:10 PM, Jonathan Dowland wrote:
> On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
>> Once I consider OpenRC ready for it, would it be ok to just replace
>> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
>> What is the opinion of other DDs? Is there anyone which would like to
>> keep the old featureless sysv-rc?
> 
> What problem does that solve?

In this way, we'd have only 2 init systems to take care of, and we could
start replacing init.d scripts by OpenRC runscripts *IF* there's a
systemd service file. Otherwise, we have to keep init.d scripts just in
case someone is running sysv-rc. So keeping sysv-rc would block progress
and force anyone to keep writing/maintaining init.d LSB header scripts.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530390a7.1050...@debian.org

Re: default init on non-Linux platforms

[Jonathan Dowland]

On Tue, Feb 18, 2014 at 05:26:05PM +0100, Christoph Egger wrote:
>   Hm so why was none of the ports list Cc-ed on this mail? There is
> active discussion [0] between hurd and bsd people were we want to go
> now.

Likewise perhaps pkg-sysvinit-devel should be copied into all such
discussions (copied here)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140218165441.gc2...@bryant.redmars.org

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/18/2014 11:38 PM, Didier 'OdyX' Raboud wrote:
> Le mardi, 18 février 2014, 22.55:32 Thomas Goirand a écrit :
>> Once I consider OpenRC ready for it, would it be ok to just replace
>> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
>> What is the opinion of other DDs? Is there anyone which would like to
>> keep the old featureless sysv-rc?
> 
> I think we should focus on one init system change at a time.
> 
> Having the good-old sysvinit setup still working in a satisfactory 
> manner is nice while preparing Jessie: that's what Wheezy has and 
> therefore has to be supported to upgrade to Jessie (think partial 
> upgrades, full-upgrade-not-rebooted-yet, etc etc). When testing crazy 
> stuff with systemd, I know I can always fallback to sysvinit if I broke 
> any .socket or .service unit I'm working on. It will be slower and feel 
> old, but would most certainly boot and provide me with comfortable ways 
> to debug. If that was changed to OpenRC, we'd exchange the sysvinit 
> safety net that all got to know in exchange for a brand new safety net 
> that we don't really know yet.
> 
> Moving to OpenRC as the secondary init for Jessie looks like changing 
> the two wheels of a bike at the same time. I'd widely prefer to keep 
> sysvinit (as old it might feel) for Jessie, especially as transition 
> point from Wheezy and have these discussions again after Jessie is 
> released.
> 
> That shouldn't stop you from providing the best OpenRC integration in 
> Debian, be it for the ports or in preparation for jessie+1.
> 
> Cheers,
> OdyX

Didier, what you are saying above make sense, I haven't really thought
about a timeline though.

If everyone agrees to have Jessie+1 as a target for sysv-rc deprecation,
that's fine to me.

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53038a6e.3010...@debian.org

Re: default init on non-Linux platforms

[Christoph Egger]

Hi!

Ondřej Surý  writes:
> I don't really want to open another can of worms, but what's the opinion
> of non-Linux ports maintainers on default init?

  Hm so why was none of the ports list Cc-ed on this mail? There is
active discussion [0] between hurd and bsd people were we want to go
now.

> Or maybe I should turn it another way:
>
> If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:
>
> Depends: systemd | openrc
>
> if I want to get rid of non-declarative init scripts in my daemon
> packages?

  As others have said already, sysv init is hardly going away *for*
*jessie* (if for upgrades alone). This positions seems to clearly be
supported by systemd maintainers as well (I remember particularly
discussing things along these lines with e.g. Michael Stapelberg at
Debconf).

  Christoph

[0] 52e82fac.2070...@pyro.eu.org and followups
-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bny4ie02@anonymous.siccegge.de

Re: default init on non-Linux platforms

[Jonathan Dowland]

On Tue, Feb 18, 2014 at 11:58:20PM +0800, Thomas Goirand wrote:
> You are IMO missing the point. I'm not proposing to drop support for
> init scripts, but remove sysv-rc. That's very different! We could
> continue to have init scripts but have OpenRC to use them.

Although I'm still not sure what problem you are trying to solve, I
would suggest explicitly CCing pkg-sysvinit-devel (the sysvinit
maintainers).

-- 
Jonathan Dowland


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140218161838.gb2...@bryant.redmars.org

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/18/2014 11:08 PM, Guus Sliepen wrote:
> On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
> 
>> On 02/18/2014 10:15 PM, Ondřej Surý wrote:
> [...]
>>> If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:
>>>
>>> Depends: systemd | openrc
>>>
>>> if I want to get rid of non-declarative init scripts in my daemon
>>> packages?
> [...]
>> Once I consider OpenRC ready for it, would it be ok to just replace
>> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
>> What is the opinion of other DDs? Is there anyone which would like to
>> keep the old featureless sysv-rc?
> 
> My opinion is that maintainers should still provide sysv init scripts until it
> is decided that Debian does not support sysvinit any more. The TC decided that
> systemd will be the default init system on Linux, not that it would be the 
> only
> init system.
> 
> Dropping support for sysv init scripts now means that you are burning the
> bridge before you finished crossing it.

You are IMO missing the point. I'm not proposing to drop support for
init scripts, but remove sysv-rc. That's very different! We could
continue to have init scripts but have OpenRC to use them.

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5303831c.4020...@debian.org

Re: default init on non-Linux platforms

[Simon McVittie]

On 18/02/14 14:15, Ondřej Surý wrote:
> If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:
> 
> Depends: systemd | openrc
> 
> if I want to get rid of non-declarative init scripts in my daemon
> packages?

I don't think that's going to be a good migration path from wheezy to
jessie. For instance, suppose your daemon is ondrejd. After upgrading
ondrejd/wheezy to ondrejd/jessie, but before rebooting into jessie, it's
still necessary for sysvinit and sysv-rc to be able to stop ondrejd; and
the postinst must succeed, which with debhelper's current dh_installinit
snippets means it's still necessary for sysvinit and sysv-rc to be able
to *start* ondrejd, too (although degraded operation would be OK).

(Depends: systemd doesn't give you systemd-as-pid-1 as a replacement for
sysvinit, anyway; that's systemd-sysv.)

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5303815d.4010...@debian.org

Re: default init on non-Linux platforms

[Didier 'OdyX' Raboud]

Le mardi, 18 février 2014, 22.55:32 Thomas Goirand a écrit :
> Once I consider OpenRC ready for it, would it be ok to just replace
> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
> What is the opinion of other DDs? Is there anyone which would like to
> keep the old featureless sysv-rc?

I think we should focus on one init system change at a time.

Having the good-old sysvinit setup still working in a satisfactory 
manner is nice while preparing Jessie: that's what Wheezy has and 
therefore has to be supported to upgrade to Jessie (think partial 
upgrades, full-upgrade-not-rebooted-yet, etc etc). When testing crazy 
stuff with systemd, I know I can always fallback to sysvinit if I broke 
any .socket or .service unit I'm working on. It will be slower and feel 
old, but would most certainly boot and provide me with comfortable ways 
to debug. If that was changed to OpenRC, we'd exchange the sysvinit 
safety net that all got to know in exchange for a brand new safety net 
that we don't really know yet.

Moving to OpenRC as the secondary init for Jessie looks like changing 
the two wheels of a bike at the same time. I'd widely prefer to keep 
sysvinit (as old it might feel) for Jessie, especially as transition 
point from Wheezy and have these discussions again after Jessie is 
released.

That shouldn't stop you from providing the best OpenRC integration in 
Debian, be it for the ports or in preparation for jessie+1.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: default init on non-Linux platforms

[Andrew Shadura]

Hello,

On 18 February 2014 16:08, Guus Sliepen  wrote:
>> Once I consider OpenRC ready for it, would it be ok to just replace
>> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
>> What is the opinion of other DDs? Is there anyone which would like to
>> keep the old featureless sysv-rc?

> My opinion is that maintainers should still provide sysv init scripts until it
> is decided that Debian does not support sysvinit any more. The TC decided that
> systemd will be the default init system on Linux, not that it would be the
> only init system.

> Dropping support for sysv init scripts now means that you are burning the
> bridge before you finished crossing it.

OpenRC, if properly baked, fully supports traditional initscripts, so
nothing burns. I guess Thomas is working on baking OpenRC the right
way :)

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cacujmdp+pckq-lvvkgdfnbfegmf+rhwdwgxgbmp3830k4mt...@mail.gmail.com

Re: default init on non-Linux platforms

[Kurt Roeckx]

On Tue, Feb 18, 2014 at 03:15:24PM +0100, Ondrej Surý wrote:
> Hi,
> 
> I don't really want to open another can of worms, but what's the opinion
> of non-Linux ports maintainers on default init?
> 
> Or maybe I should turn it another way:
> 
> If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:
> 
> Depends: systemd | openrc
> 
> if I want to get rid of non-declarative init scripts in my daemon
> packages?

I think that's going to fail on upgrade when sysvinit it still
running as init.


Kurt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140218151855.ga12...@roeckx.be

Re: default init on non-Linux platforms

[Guus Sliepen]

On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:

> On 02/18/2014 10:15 PM, Ondřej Surý wrote:
[...]
> > If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:
> > 
> > Depends: systemd | openrc
> > 
> > if I want to get rid of non-declarative init scripts in my daemon
> > packages?
[...]
> Once I consider OpenRC ready for it, would it be ok to just replace
> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
> What is the opinion of other DDs? Is there anyone which would like to
> keep the old featureless sysv-rc?

My opinion is that maintainers should still provide sysv init scripts until it
is decided that Debian does not support sysvinit any more. The TC decided that
systemd will be the default init system on Linux, not that it would be the only
init system.

Dropping support for sysv init scripts now means that you are burning the
bridge before you finished crossing it.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

[Jonathan Dowland]

On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
> Once I consider OpenRC ready for it, would it be ok to just replace
> sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
> What is the opinion of other DDs? Is there anyone which would like to
> keep the old featureless sysv-rc?

What problem does that solve?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140218151029.ga2...@bryant.redmars.org

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/18/2014 10:15 PM, Ondřej Surý wrote:
> Hi,
> 
> I don't really want to open another can of worms, but what's the opinion
> of non-Linux ports maintainers on default init?
> 
> Or maybe I should turn it another way:
> 
> If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:
> 
> Depends: systemd | openrc
> 
> if I want to get rid of non-declarative init scripts in my daemon
> packages?
> 
> O.

I'd like to widen this topic.

We're not there yet (I still need to do some more tests with Hurd, and
fix a few problems), but I will soon upload OpenRC to Sid.

Once I consider OpenRC ready for it, would it be ok to just replace
sysv-rc by OpenRC, and transform sysv-rc into a transitional package?
What is the opinion of other DDs? Is there anyone which would like to
keep the old featureless sysv-rc?

Cheers,

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53037464.4030...@debian.org

default init on non-Linux platforms

[Ondřej Surý]

Hi,

I don't really want to open another can of worms, but what's the opinion
of non-Linux ports maintainers on default init?

Or maybe I should turn it another way:

If we have working OpenRC on kFreeBSD and GNU Hurd, can I do:

Depends: systemd | openrc

if I want to get rid of non-declarative init scripts in my daemon
packages?

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1392732924.27488.84805349.0558e...@webmail.messagingengine.com