Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 11/06/2013 07:00 AM, Paul Tagliamonte wrote: If you want to hold your own system back, there's nothing stoping you (and your rights granted by f/oss software allow you to do so). And there's nothing stopping you from contributing to OpenRC either, if you feel, like me, that it's free of big-corp interest, that supporting non-linux ports is the ethical thing to do, and that OpenRC deserves attention despite some of its problems, and lack of some important features. I don't remember seeing any commits or patch from you ... 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/52e41a61.7040...@debian.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 11/06/2013 09:33 PM, Gergely Nagy wrote: Switching to systemd/upstart/OpenRC will not mean the rest will be dropped. Whatever the decision we take, I really wish we deprecate sysv-rc in the favor of OpenRC. It would really make sense, even if systemd or Upstart becomes the default. Also, I would really love to get help on actually making it *easy to switch* from one init system to another, though we aren't there at all. Shutting down daemons cleanly on the first shutdown on all calses, after switching, isn't easy. Contributions welcome! 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/52e41efe.6070...@debian.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 11/06/2013 10:14 PM, Thorsten Glaser wrote: but the propo- nents of systemd, upstart *and* openrc (to a lesser amount) alike *all* want to *not* keep supporting init scripts). Just FYI, here's my view... I'd love to have a patch in OpenRC so that we'd have something like /etc/init.d.openrc that would contains overrides runscripts for sysv-rc scripts in /etc/init.d, so that they would both co-exist (like, if OpenRC sees they have the same name, use the one in /etc/init.d.openrc). However, we don't have such a feature yet. If we never have such a patch available, then yes, I'd be for sysv-rc scripts to die, which can only happen if we impose the support of either Upstart or systemd: in which case init.d scripts could be converted to OpenRC runscripts, because OpenRC would be the only left consumer of them if we decide sysv-rc is deprecated. The later is a likely scenario, but I'd prefer the former. Feel free to contribute! :) 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/52e42110.7090...@debian.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 12/25/2013 08:46 AM, Thomas Goirand wrote: And overriding the *entire* service file seems excessive if you wish to override just one line of the package's service file. And also, systemd would be the only package behaving this way, which is counter-intuitive for our users. I'd even go up to say this isn't policy compliant (as configuration files must be in /etc). Thomas, we have agreed to no longer discuss this topic anymore until the technical committee has made a decision, haven't we? And, as for your statement, it's incorrect. systemd (and udevd) have always shipped their factory unit files in /usr or /lib and everything that you customize is read from /etc/systemd and /etc/udevd, respectively and has precedence over the shipped unit or rules files. This is a common practice used by many packages, So there is nothing violating the policy and the information you had was simply incorrect. In any case, please let's stop here and let the committee do their work. We've had enough discussion already. Cheers and Happy Holidays! 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/52baaa79.20...@physik.fu-berlin.de
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 12/25/2013 05:50 PM, John Paul Adrian Glaubitz wrote: On 12/25/2013 08:46 AM, Thomas Goirand wrote: And overriding the *entire* service file seems excessive if you wish to override just one line of the package's service file. And also, systemd would be the only package behaving this way, which is counter-intuitive for our users. I'd even go up to say this isn't policy compliant (as configuration files must be in /etc). Thomas, we have agreed to no longer discuss this topic anymore until the technical committee has made a decision, haven't we? Ok. Cheers and Happy Holidays! To you as well! 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/52bac69f.7020...@debian.org
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Tue, Dec 24, 2013 at 02:19:36AM +0100, Philipp Kern wrote: On 2013-12-23 13:15, Sergey B Kirpichev wrote: [a potentially badly-phrased question] ...I don't think many continue to read your rant and take your feedback seriously. Apart from those who already resonate with your opinion. And hence it's not really a useful contribution to the discussion. I'll ask, then. Does systemd support an error handler script? There is ExecStopPost, but I don't see that it gets the return value of the main process or anything similar. So is there anything better than a home-grown wrapper script with an error handler? FWIW, when I asked the question above regarding core files on #systemd a while ago (probably half a year ago or so) folks referred me to core pipe handler, which I don't consider useful for me, as it is a global setup. -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend -- 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/20131224164705.gx23...@lemon.cohens.org.il
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Tue, Dec 24, 2013 at 05:47:05PM +0100, Tzafrir Cohen wrote: On Tue, Dec 24, 2013 at 02:19:36AM +0100, Philipp Kern wrote: On 2013-12-23 13:15, Sergey B Kirpichev wrote: [a potentially badly-phrased question] ...I don't think many continue to read your rant and take your feedback seriously. Apart from those who already resonate with your opinion. And hence it's not really a useful contribution to the discussion. I'll ask, then. Does systemd support an error handler script? No. But of course you can wrap the program in whatever script you want, and start that script instead of the program itself in the unit. Zbyszek -- 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/20131224223449.gl13...@in.waw.pl
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 10/31/2013 09:47 PM, Steven Chamberlain wrote: On Thu, 31 Oct 2013 06:33:44 +0100 John Paul Adrian Glaubitz wrote: two places where to place systemd service files. One is located below /usr/lib/systemd which is the directory where service files provided by the package are placed, and one is /etc/systemd where your own, custom service files are located. If you created a custom local script, just to append something to the daemon's command line, is that going to clobber the package's service file indefinitely? So if a new version or security update adds a -s flag telling the daemon to 'run in secure mode' your local definition might never pick that up? In this situation, I think I'd prefer to see a conffile prompt. And overriding the *entire* service file seems excessive if you wish to override just one line of the package's service file. And also, systemd would be the only package behaving this way, which is counter-intuitive for our users. I'd even go up to say this isn't policy compliant (as configuration files must be in /etc). On 10/31/2013 09:57 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Oct You add a file /etc/systemd/system/xxx.service.d/yyy.conf with the following contents: [Service] SettingToOverride=whatever Which doesn't fix the problem if SettingToOverride silently gets a new -s option in /usr, to launch the daemon in its security mode, as Steven described. Users would get no prompt at all, and will never know. While I perfectly understand why things are this way in RedHat (eg: by policy, all rpm stuff are non-interactive), I think this should be fixed in Debian. We must have the systemd files stored somewhere in /etc. I don't really understand why the systemd maintainers in Debian don't fix that. Would such patch be too hard to maintain? Is there some resistance upstream for having the path of systemd files fixed, to be Debian policy compliant (this would be very surprising considering they seem to care)? Or is this the view of the systemd maintainers that it's perfectly fine to violate the policy in this case? 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/52ba8d6f.6020...@debian.org
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
You don’t want anything like these in your local init service. For such tests you have Nagios, Icinga or similiar daemons. And they can do much deeper checks, e.g. can you login into your webservice because your database backend on a different server is available. Once your monitoring system – your costly monitoring system with someone behind it just to check whether your buggy scripts have failed to start your service — has detected the service is not running, what will you do to understand what has gone wrong? Obviously, if you ask such a question - you never had any good expirience with mentioned above costly monitoring solution. Then why you claim that other people are incompetent? You are. FYI. The monitoring system will restart your service on failure, just like systemd. Or it will run gdb on core and send you a message, or do whatever you configure it to do. And the point is what tests (and actions) could be much more configurable than systemd's. The best you can do with systemd's monitoring functional is to switch it off. I don’t mind if you want systemd, but don’t force it on others. There are no features in systemd that I would dump the well known sysvinit. I don’t mind if you don’t want these features, but don’t force others to run their Debian systems with software from the previous century that lacks them. If they want systemd - fine. I'll happy to support this as a variant for init system. It's already in the Debian, please use this. But why you force others to this overbloated system? Nobody is forcing you to use these features. How I can be sure? There is the Restart configuration directive. Yet another competent (yes, just like you) Debian maintainer could add a default service file with Restart=on-failure, for example. Why not? It's cool and from this century, right? -- 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/20131223121509.ga30...@darkstar.order.hcn-strela.ru
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 2013-12-23 13:15, Sergey B Kirpichev wrote: You don’t want anything like these in your local init service. For such tests you have Nagios, Icinga or similiar daemons. And they can do much deeper checks, e.g. can you login into your webservice because your database backend on a different server is available. Once your monitoring system – your costly monitoring system with someone behind it just to check whether your buggy scripts have failed to start your service — has detected the service is not running, what will you do to understand what has gone wrong? Obviously, if you ask such a question - you never had any good expirience with mentioned above costly monitoring solution. Then why you claim that other people are incompetent? You are. [...] And with that aggressiveness and... But why you force others to this overbloated system? ...I don't think many continue to read your rant and take your feedback seriously. Apart from those who already resonate with your opinion. And hence it's not really a useful contribution to the discussion. Kind regards Philipp Kern -- 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/988832368fdcd82614334771d06e8...@hub.kern.lc
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Matthias Urlichs dixit: A systemd service file is five lines. Someone has shown that this works with sysvinit as well, if you use #!/path/to/some-helper as shebang. Want more features in your init script? Like, say, a reliable way to figure out if any parts of your server are still running after it crashed? Ugh, bad server design. Or a way to determine that it has started up correctly? An initscript is supposed to not return before it did that. determined environment without stupid surprises like a LOCALE That’d be the domain of the aforementioned helper. Or a private tmp? I shudder at the mere thought of allowing a dæmon to unshare its /tmp from the rest of the system, because of the maintenance nightmare this creates, from a Unix PoV (maybe it’s “cool” to you and “usual” to Plan 9 guys, but things like this, or POSIX ACLs, or SELinux, massively make the system opaque to Unix admins). Or any other of the cool features systemd offers? Newsflash: “cool” isn’t always “better”. SysV init scripts do not even *have* a reliable dependency system. Sequential booting worked fine for ages, and mostly still does (with file-rc, although insserv certainly introduced trouble). The SysV manager can tell that the thing started and didn't exit nonzero, but that's not always the same thing as running. The initscript is supposed to exit nonzero if the dæmon does not run. Sure, not too many initscripts do that, but still. (If you want a good example, look at postgresql’s, except it doesn’t wait long enough on some slow systems.) This is about features. Many of the features systemd provides (and which I refuse to live without, having become accustomed to them over the last year or so) are, by basic Unix design, not available to something that is not PID 1. But not everyone needs or wants those features. And, as pointed out on the unshared /tmp example above, some of them may be positively harmful to maintenance of the system in question. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”) -- 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/pine.bsm.4.64l.132015440.23...@herc.mirbsd.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Mon, Nov 11, 2013 at 08:20:58PM +, Thorsten Glaser wrote: Matthias Urlichs dixit: A systemd service file is five lines. Someone has shown that this works with sysvinit as well, if you use #!/path/to/some-helper as shebang. Nice theory, but in practice it is a mess. That people could clean stuff up has been raised and dismissed various times because nobody cleans it up. Want more features in your init script? Like, say, a reliable way to figure out if any parts of your server are still running after it crashed? Ugh, bad server design. Why? Or a way to determine that it has started up correctly? An initscript is supposed to not return before it did that. Why? Also, loads of scripts have sleeps in them. determined environment without stupid surprises like a LOCALE That’d be the domain of the aforementioned helper. Theory vs practice again. Or a private tmp? I shudder at the mere thought of allowing a dæmon to unshare its /tmp from the rest of the system, because of the maintenance nightmare this creates, from a Unix PoV (maybe it’s “cool” to you and “usual” to Plan 9 guys, but things like this, or POSIX ACLs, or SELinux, massively make the system opaque to Unix admins). Or any other of the cool features systemd offers? Newsflash: “cool” isn’t always “better”. Instead of such easy replies, try with: s/cool/nice/ Every reply from you reads as - I don't see the need - I don't like it - Could theoretically be done in another way while systemd provides an easy consistent way for *every* service. No rewriting needed. You can easily change some options. SysV init scripts do not even *have* a reliable dependency system. Sequential booting worked fine for ages, and mostly still does (with file-rc, although insserv certainly introduced trouble). It may have worked fine, but doesn't dismiss the argument that the other design is better / improved vs the old one. The SysV manager can tell that the thing started and didn't exit nonzero, but that's not always the same thing as running. The initscript is supposed to exit nonzero if the dæmon does not run. Sure, not too many initscripts do that, but still. (If you want a good example, look at postgresql’s, except it doesn’t wait long enough on some slow systems.) doesn't wait long enough is enough IMO You also raise the supposed to, which is again theory vs practice. With systemd you have various things which you can rely on. No need to hope that the init script was properly written. If you want to change an option you can. This without totally changing the init script to change it in the way it was supposed to be written. This is about features. Many of the features systemd provides (and which I refuse to live without, having become accustomed to them over the last year or so) are, by basic Unix design, not available to something that is not PID 1. But not everyone needs or wants those features. And, as pointed out on the unshared /tmp example above, some of them may be positively harmful to maintenance of the system in question. You didn't point it out, you said it makes it complicated without stating why. -- Regards, Olav -- 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/2013212436.ga17...@bkor.dhs.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Mon, Nov 11, 2013 at 10:24:36PM +0100, Olav Vitters wrote: On Mon, Nov 11, 2013 at 08:20:58PM +, Thorsten Glaser wrote: Or a private tmp? I shudder at the mere thought of allowing a dæmon to unshare its /tmp from the rest of the system, because of the maintenance nightmare this creates, from a Unix PoV (maybe it’s “cool” to you and “usual” to Plan 9 guys, but things like this, or POSIX ACLs, or SELinux, massively make the system opaque to Unix admins). Olav answered other points, I'll just answer this one. PrivateTmp directiories are accessible from the outside, given suitable priviledges. If you look into /tmp/systemd-service.service-XXX/tmp and /var/tmp/systemd-service.service-XXX/tmp, you'll find the contents of the /tmp and /var/tmp directories of service.service. In fact, we make use of this functionality: the systemd-tmpfiles cleaner also removes old stuff from PrivateTmp directories, just like from normal /tmp and /var/tmp. (Until relatively recently, the service name wasn't used in the directory name, so all dirs were called /tmp/systemd-private-XXX, where XX is some random string, but now the service is included, so finding the right dir is rather simple.) Zbyszek -- 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/2013224230.gu28...@in.waw.pl
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Marko Randjelovic markoran at eunet.rs writes: That's exactly how I feel when I want to create a small daemon using a SystemV init script. I feel like building an airplane from scratch while I would just use a bike. Sure, systemd is bloated. Just like the kernel is bloated, I presume. A kernel which runs on anything from bikes to space planes. (Literally.) A systemd service file is five lines. Want more features? Add more lines. Use /etc/init.d/skeleton and you'll see it's very simple. Want more features in your init script? Like, say, a reliable way to figure out if any parts of your server are still running after it crashed? Or a way to determine that it has started up correctly? Or a reliable log of all of its output in one location? (With a filter that dumps the last 100 lines of debug log to disk _only_ if there's an error right behind them!) Or a way to figure out which dependency prevented your daemon from running (and which seamlessly resumes bootup when you fix the problem)? Or a pre- determined environment without stupid surprises like a LOCALE set to Chinese (or something more insiduous like, say, an ignored signal) when you start something by hand? Or a private /tmp? Or any other of the cool features systemd offers? systemd: For each of these, add a line to your service script. If it's not the default anyway. SysV: Sorry, you're screwed. (Mostly.) SysV init scripts do not even *have* a reliable dependency system. The SysV manager can tell that the thing started and didn't exit nonzero, but that's not always the same thing as running. Shell is a programming language. It cannot be less flexible then config files. *than. Besides, this is not about flexibility. You're free to run a small and simple shell script to start your service if you need to, just like today you're free to hide your not-so-small and no-longer-simple script (see above about reliably detecting whether a service is in fact up) inside a bloated SysV init script. This is about features. Many of the features systemd provides (and which I refuse to live without, having become accustomed to them over the last year or so) are, by basic Unix design, not available to something that is not PID 1. -- -- Matthias Urlichs -- 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/loom.20131108t130649-...@post.gmane.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 11/01/2013 02:00 AM, Kevin Chadwick wrote: previously on this list Wouter Verhelst contributed: By absense of documentation, are you referring to the almost 10% of the source base that are comments or the 15% that is DocBook XML based documentation? (Almost 14kLOC and almost 36kLOX, respectively.) That particular comment was not referring to systemd specificaly. I haven't looked at the systemd code in much detail myself. What I wrote in the above-quoted post was based on the comment of this OpenRC developer. Perhaps I should have checked some more before repeating that comment, though. Well he actually said that seperating/finding the logind code and any relevent documentation was difficult. So an accurate rebuttal would be ?kLOC and ?kLOX concerning logind This kinds of statistics show nothing. Statistics about the number of lines of comments will never tell what kinds of comments there is, and/or if they are relevant. Have a look in the code, it gives a much better idea (yes, this requires not just reading this list and make your own opinion!). 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/527fcef9.6000...@debian.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Sun, Nov 10, 2013 at 11:25:32AM +, Matthias Urlichs wrote: Want more features in your init script? Like, say, a reliable way to figure out if any parts of your server are still running after it crashed? Or a way to determine that it has started up correctly? You don’t want anything like these in your local init service. For such tests you have Nagios, Icinga or similiar daemons. And they can do much deeper checks, e.g. can you login into your webservice because your database backend on a different server is available. I don’t mind if you want systemd, but don’t force it on others. There are no features in systemd that I would dump the well known sysvinit. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Le dimanche 10 novembre 2013 à 20:23 +0100, Stephan Seitz a écrit : You don’t want anything like these in your local init service. For such tests you have Nagios, Icinga or similiar daemons. And they can do much deeper checks, e.g. can you login into your webservice because your database backend on a different server is available. Once your monitoring system – your costly monitoring system with someone behind it just to check whether your buggy scripts have failed to start your service — has detected the service is not running, what will you do to understand what has gone wrong? Please read other people’s arguments before you reply with something completely unrelated. I don’t mind if you want systemd, but don’t force it on others. There are no features in systemd that I would dump the well known sysvinit. I don’t mind if you don’t want these features, but don’t force others to run their Debian systems with software from the previous century that lacks them. Nobody is forcing you to use these features. Systemd will keep your precious SysV scripts working just as well as they do right now. The ones who wants to force others to live without the software they need in Debian are the incompetent sysvinit fanboys who lurk around here. kthxbye, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1384113818.1803.9.camel@tomoe
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Tue, 5 Nov 2013 18:00:09 -0500 Paul Tagliamonte paul...@debian.org wrote: What? Sorry, what? Are you disagreeing with yourself? If it's so important to a UNIX system, why do you say it's not technical ... I said it's not *only* technical. Big companies all over and over again show they care much more about their economic interests than about interests of free software community. As of my understanding, Debian should be an independent project, devoted to interest of its community (users), and not the interests of any companies. However, it is obvious companies push their software because they control their development, but then if such software becomes essential for Debian, they control Debian. If you read free software principles elaborated by Richard M. Stallman and FSF, it is clear that the point is exactly in having control over your life, i.e. being independent (or in other words not under control) of any companies. No, that's not what RMS and the FSF means. They claim, by ensuring software you use is free, you can ensure that you retain your rights when using your computer by granting you basic freedoms (the four freedoms). One of those freedoms is to use the software commercially, just FYI. I didn't say I am against commercial usage of software. RMS did say something like I said: That’s the fundamental issue: while non-free software and SaaSS are controlled by some other entity (typically a corporation or a state), free software is controlled by its users. Why does this control matter? Because freedom means having control over your own life. http://www.wired.com/opinion/2013/09/why-free-software-is-more-important-now-than-ever-before/ We shall not stand in the way of progress. logind, systemd (such as socket based activation, dependency booting) in particular, and friends are technical wins. We'd be silly to not take them. We are not standing in the way, if Red Hat wants to test systemd it can do it in Fedora. systemd is obviously more powerful than sysvinit, but I am afraid of implications. UNIX philosophy is to do only one thing right. They replace login system and it can obviously have even security implications. And SysVInit just works well and it is simply enough. It has much less dependencies than systemd. Do not make unneeded weight on people to learn systemd in addition to shell scripts, if systemd is powerful that also means there is a lot to learn. I really doubt non-standards task can be solved with systemd without shell scripts (or similar), and every serious UNIX admin must know shell programming anyway. This is like saying A horse drawn carrage works well enough, why do you need an airplane. You need an airplane because Earth is 40,000 km in round and because you have a reason to travel to a distant location. Or just you want to do some sport? But I know my possibilities and I wouldn't spend my money on an airplane just for sport, to produce an airplane you have to take raw materials out of this planet, you have to spend power, human time, make pollution, etc. -- http://mr.flossdaily.org signature.asc Description: PGP signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Tue, 5 Nov 2013, Paul Tagliamonte wrote: First of all, I do not agree Debian community is hurt because of split about init system, I disagree strongly. Please read through every flame thread over the last 4 years and try to say this with a straight face. That’s why I say let’s just support them all. such software becomes essential for Debian, they control Debian. If you read free software principles elaborated by Richard M. Stallman and FSF, it is clear that the point is exactly in having control over your life, i.e. being independent (or in other words not under control) of any companies. No, that's not what RMS and the FSF means. They claim, by ensuring software you use is free, you can ensure that you retain your rights when using your computer by granting you basic freedoms (the four freedoms). That’s the general idea, yes. But there are, of course, new developments that make the “ensuring X” no longer be enough. Do remember that this is not about the (freeness of the) software but of the users. http://mako.cc/copyrighteous/freedom-for-users-not-for-software Hence why I insist on freedom of choice, even though I’d never choose systemd for myself, since I see that others would want it. One of those freedoms is to use the software commercially, just FYI. I think that’s not his point. I read Marko’s mail as an argument against vendor lock-in, and, let’s face it, systemd is company-backed (RedHat, mostly), as is Upstart (Canonical, mostly). But, IMHO now, even if this were not so, there’s already way too much vendor lock-in in the (GNU) world, for example autoconf 2.62 depending on GNU m4, whereas older versions worked perfectly fine with BSD m4, and so on. Let’s not add to it. it's urgent, and it *is* causing social problems in Debian. ACK. We don't want free software becomes just a marionette of big business. The fun thing about F/OSS is free software *can* become a marionette and we're still much more free than before (and can still express the same rights as if it wasn't a mega-corp). Yes, but by becoming a marionette of either systemd or upstart (and, funnily – as my stances towards Canonical/*buntu/Shuttleworth are known – currently I perceive systemd as a much larger threat) we lose wrt. the current state of having sysvinit usable. We shall not stand in the way of progress. logind, systemd (such as socket based activation, dependency booting) in particular, and friends are technical wins. We'd be silly to not take them. NO! We’d be silly to take them, because they lead to vendor lock-in, and *especially* the systemd side has shown, time and time again, that they won’t stop there. They intend to wholly change the ecosystem, to get away from Unix and GNU and towards this thing some people now call “FLOS” (one ‘s’). And Debian is, fundamentally, still a Unix of sorts. I believe they should do their FLOS experiments in a downstream. If you want to hold your own system back, there's nothing stoping you Bad suggestion. I don’t even want to follow this thought. This is like saying A horse drawn carrage works well enough, why do you need an airplane. In some cases, the airplane is too much. Think, to transport one person a dozen kilometres. Think about costs. Sometimes, the benefits do *not* outweigh the costs. But sometimes, they do – an æroplane is the perfect tool to transport several dozen people from Europe to the Americas, for example (other than a ship). Which is another reason for us to actively support both sysvinit and one of the newcomers (such as upstart, since it’s much less hostile). This way, people (actual users!) can choose. It’s not necessary to install the whole systemd stack on a small one-purpose VM, for example. Or on a tightly secured, small VM _host_ (when the guests have all the power). without deviation from the norm progress is not possible -- Frank Zappa Without competition, progress is not possible either. A systemd monoculture – which clearly is what “the systemd/GNOME crowd” (they really mesh together) want – will not help anyone. I believe this is a purely technical issue I’m with you on this, but… , and one that is near 100% invisible to the user. … most definitely not on this. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- 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/alpine.deb.2.10.1311061350390.14...@tglase.lan.tarent.de
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
And SysVInit just works well and it is simply enough. It has much less dependencies than systemd. Do not make unneeded weight on people to learn systemd in addition to shell scripts, if systemd is powerful that also means there is a lot to learn. I really doubt non-standards task can be solved with systemd without shell scripts (or similar), and every serious UNIX admin must know shell programming anyway. This is like saying A horse drawn carrage works well enough, why do you need an airplane. You need an airplane because Earth is 40,000 km in round and because you have a reason to travel to a distant location. Or just you want to do some sport? But I know my possibilities and I wouldn't spend my money on an airplane just for sport, to produce an airplane you have to take raw materials out of this planet, you have to spend power, human time, make pollution, etc. That's exactly how I feel when I want to create a small daemon using a SystemV init script. I feel like building an airplane from scratch while I would just use a bike. Introducing the concept of possibilities is interesting: sometimes, you need some choices in your available tools to perform the same task, depending on your current need… Adrien -- 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/527a3e75.5050...@antipoul.fr
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Thorsten Glaser t.gla...@tarent.de writes: On Tue, 5 Nov 2013, Paul Tagliamonte wrote: First of all, I do not agree Debian community is hurt because of split about init system, I disagree strongly. Please read through every flame thread over the last 4 years and try to say this with a straight face. That’s why I say let’s just support them all. Please no. That's a maintenance nightmare. I'm fine with one on GNU/Linux, another everywhere else (but I'll treat everything else as secondary), but supporting all of them, everywhere they're available, is madness. Do remember that this is not about the (freeness of the) software but of the users. http://mako.cc/copyrighteous/freedom-for-users-not-for-software Hence why I insist on freedom of choice, even though I’d never choose systemd for myself, since I see that others would want it. Freedom of choice remains even when there's a default. We have a default desktop, default syslogd, default MTA, default-this, default-that, yet, we have alternatives for all of those. We have a default init now, and alternatives to that too. If we choose a different default, the alternatives can still co-exist, like they do now. Freedom is not lost. One of those freedoms is to use the software commercially, just FYI. I think that’s not his point. I read Marko’s mail as an argument against vendor lock-in, and, let’s face it, systemd is company-backed (RedHat, mostly), systemd is company-backed only as much as glibc or GNOME is. We shall not stand in the way of progress. logind, systemd (such as socket based activation, dependency booting) in particular, and friends are technical wins. We'd be silly to not take them. NO! We’d be silly to take them, because they lead to vendor lock-in, and *especially* the systemd side has shown, time and time again, that they won’t stop there. They intend to wholly change the ecosystem, to get away from Unix and GNU and towards this thing some people now call “FLOS” (one ‘s’). And change is bad, because...? I'm not sure about you, but I prefer to improve my systems instead of holding them hostage to ancient technologies, just because there's only one implementation of a particular solution. But sometimes, they do – an æroplane is the perfect tool to transport several dozen people from Europe to the Americas, for example (other than a ship). Which is another reason for us to actively support both sysvinit and one of the newcomers (such as upstart, since it’s much less hostile). This way, people (actual users!) can choose. It’s not necessary to install the whole systemd stack on a small one-purpose VM, for example. Or on a tightly secured, small VM _host_ (when the guests have all the power). This is a misguided reasoning. Just because we select *one* default, does not mean that all alternatives will be dropped. We have systemd and upstart in Debian, they're usable, yet, sysvinit is the default. Switching to systemd/upstart/OpenRC will not mean the rest will be dropped. The choice will remain. without deviation from the norm progress is not possible -- Frank Zappa Without competition, progress is not possible either. A systemd monoculture – which clearly is what “the systemd/GNOME crowd” (they really mesh together) want – will not help anyone. See above. -- |8] -- 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/87k3glvemn.fsf@algernon.balabit
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Nov 06, 2013 at 02:33:36PM +0100, Gergely Nagy wrote: Please no. That's a maintenance nightmare. I'm fine with one on GNU/Linux, another everywhere else (but I'll treat everything else as secondary), but supporting all of them, everywhere they're available, is madness. This is now in the hands of the tech-ctte, discussing it here further serves no useful purpose at the moment. -- 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/20131106140012.ga24...@bryant.redmars.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, 6 Nov 2013, Gergely Nagy wrote: Please no. That's a maintenance nightmare. I'm fine with one on GNU/Linux, another everywhere else (but I'll treat everything else as secondary), but supporting all of them, everywhere they're available, is madness. And: Freedom of choice remains even when there's a default. We have a default desktop, default syslogd, default MTA, default-this, default-that, yet, we have alternatives for all of those. We have a default init now, and alternatives to that too. If we choose a different default, the alternatives can still co-exist, like they do now. Freedom is not lost. Do you read what you write? These two blocks are the inverse of each other. Either you support them all or they cannot coëxist. [ vendor lock-in ] And change is bad, because...? I'm not sure about you, but I prefer to Experience shows that vendor lock-in is always bad, because it prevents you from exchanging one bad component with another. The fact that things are OSS doesn’t change this, either, especially as it still leads to massive effort. improve my systems instead of holding them hostage to ancient technologies, just because there's only one implementation of a particular solution. This is contrary too… you want to switch to one “more modern” init system, just because it’s the only one that offers you the features you now think you want, holding you hostage to whatever technology Poettering thinks nice right now (consider his track report of abandoning things, too) and preventing you from using something else instead. (Or something more suited to a particular job.) Switching to systemd/upstart/OpenRC will not mean the rest will be dropped. But that’s just the thing: you said above: one on GNU/Linux, one on the others, period. This in effect means that all other systems will be dropped because you don’t want to support them (unless we keep sysvinit as lowest common denominator, require maintainers to write init scripts (which can be very short with a helper, as recent Planet Debian posts showed), and use the other init systems in compat mode; but the propo- nents of systemd, upstart *and* openrc (to a lesser amount) alike *all* want to *not* keep supporting init scripts). bye, //mirabilos -- 15:41⎜Lo-lan-do:#fusionforge Somebody write a testsuite for helloworld :-) -- 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/alpine.deb.2.10.1311061508230.14...@tglase.lan.tarent.de
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Nov 06, 2013 at 03:14:14PM +0100, Thorsten Glaser wrote: [snip] Some good points made all around, more for the ctte to consider. As Jonathan says, it's in ctte's hands now, let's agree to disagree and let the poor souls on the commitee do their job Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, 06 Nov 2013 14:04:53 +0100 Adrien CLERC adr...@antipoul.fr wrote: And SysVInit just works well and it is simply enough. It has much less dependencies than systemd. Do not make unneeded weight on people to learn systemd in addition to shell scripts, if systemd is powerful that also means there is a lot to learn. I really doubt non-standards task can be solved with systemd without shell scripts (or similar), and every serious UNIX admin must know shell programming anyway. This is like saying A horse drawn carrage works well enough, why do you need an airplane. You need an airplane because Earth is 40,000 km in round and because you have a reason to travel to a distant location. Or just you want to do some sport? But I know my possibilities and I wouldn't spend my money on an airplane just for sport, to produce an airplane you have to take raw materials out of this planet, you have to spend power, human time, make pollution, etc. That's exactly how I feel when I want to create a small daemon using a SystemV init script. I feel like building an airplane from scratch while I would just use a bike. Use /etc/init.d/skeleton and you'll see it's very simple. Introducing the concept of possibilities is interesting: sometimes, you need some choices in your available tools to perform the same task, depending on your current need… Adrien Shell is a programming language. It cannot be less flexible then config files. But there is also an interesting point. We are currently not using BASH features for init scripts. As I remember, BASH was bloated or smt, but certainly less than systemd is. -- 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/20131106174319.0535e...@eunet.rs
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
This discussion isn't really furthering the development of Debian and the init system question is already with the technical committee so can we please take such discussions off-list, if one is determined to continue them. -- 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/20131106171114.ga27...@bryant.redmars.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
* Thorsten Glaser: On Thu, 31 Oct 2013, Florian Weimer wrote: Curiously, a lot of system administrators do not do this correctly using sysvinit, causing system daemons to start unexpectedly after installing package updates. What *is* the correct way, anyway? Renaming the S symlinks to K symlinks. update-rc.d is intended for packaging scripts only. So I ended up writing 'exit 0' as the first line into the respective /etc/default/ file to disable them… or changing the initscript directly (also 'exit 0' as first line after the shebang), leading to conffile prompts. Yes, that's what I usually do as well because it's more reliable. As far as I'm concerned, this is the number one reason why the Debian init system needs an overhaul. -- 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/87d2mdifh7@mid.deneb.enyo.de
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Nov 06, 2013 at 06:53:40PM +0100, Florian Weimer wrote: [...] Again, good points, but ones we've discussed. Perhaps we should end this thread? Fondly, Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
❦ 6 novembre 2013 18:53 CET, Florian Weimer f...@deneb.enyo.de : Curiously, a lot of system administrators do not do this correctly using sysvinit, causing system daemons to start unexpectedly after installing package updates. What *is* the correct way, anyway? Renaming the S symlinks to K symlinks. update-rc.d is intended for packaging scripts only. update-rc.d has now a disable command. I think this is intended for administrators. It is compatible with SysV and systemd. Dunno about upstart. -- die_if_kernel(Penguin instruction from Penguin mode??!?!, regs); 2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c signature.asc Description: PGP signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
❦ 6 novembre 2013 17:43 CET, Marko Randjelovic marko...@eunet.rs : That's exactly how I feel when I want to create a small daemon using a SystemV init script. I feel like building an airplane from scratch while I would just use a bike. Use /etc/init.d/skeleton and you'll see it's very simple. The restart part of this script is buggy and documented as this: # Wait for children to finish too if this is a daemon that forks # and if the daemon is only ever run from this initscript. # If the above conditions are not satisfied then add some other code # that waits for the process to drop all resources that could be # needed by services started subsequently. A last resort is to # sleep for some time. This is why we have so many scripts with sleep. On 138 init.d script I have on my system, 52 are using sleep. This is full of race conditions. If your system is slow, a restart will likely fail because sleep will not wait enough time. -- panic (Splunge!); 2.2.16 /usr/src/linux/drivers/scsi/psi240i.c signature.asc Description: PGP signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Sat, 26 Oct 2013 11:07:36 +0200 Lucas Nussbaum lea...@debian.org wrote: I think that it would be a failure of the Debian project if we had to have a GR about such a technical decision. I think that we need to trust that the Technical Committee will make the right decision. A GR about this will likely result in splitting and hurting the project even more. This is not at all merely a technical decision. First of all, I do not agree Debian community is hurt because of split about init system, nor that some problems would be solved by Tech Committee rules about default init system. Init system is an essential part of any UNIX-like system. If anything can undermine an OS, it is init system. Big companies all over and over again show they care much more about their economic interests than about interests of free software community. As of my understanding, Debian should be an independent project, devoted to interest of its community (users), and not the interests of any companies. However, it is obvious companies push their software because they control their development, but then if such software becomes essential for Debian, they control Debian. If you read free software principles elaborated by Richard M. Stallman and FSF, it is clear that the point is exactly in having control over your life, i.e. being independent (or in other words not under control) of any companies. Even if such projects are forked, it is not a good outcome, since they are to (and unnecessarily) complex and community will have much problems in adding any additional features or other modifications, while companies can do it because they pay full time developers and they have both psychological interest to impress their users and to control direction of free software development. If anything looks like a Trojan horse, it's an init system controlled by a big company. If someone is rushing this decision, it may be only in interest of companies that want by the (false) argument of urgency use Tech Committee to make such decision without taking into consideration neither interests nor attitude of whole Debian community. We don't want free software becomes just a marionette of big business. If a software insists on depending on any particular init system for some only to them knows reason, then it cannot be default or we are becoming hostages of such software. Users who want to use it should take care on their own about installing needed dependencies. Gnome all the time keeps making us unpleasant surprises. Gnome is bloated, depend on to many software, and now even on specific init system. Its configuration system is surely not to much like Windows registry as it looks based on gconftool, but it is obviously to complex and far away from UNIX philosophy. When GDM3 appeared, I couldn't change theme, most options were missing. The picture was hardcoded in exe. Since then I don't use GDM anymore. And now Gnome depend on systemd. If systemd one day puts us in similar situation, will it be possible to remove it? What will systemd depend on a few years later? And SysVInit just works well and it is simply enough. It has much less dependencies than systemd. Do not make unneeded weight on people to learn systemd in addition to shell scripts, if systemd is powerful that also means there is a lot to learn. I really doubt non-standards task can be solved with systemd without shell scripts (or similar), and every serious UNIX admin must know shell programming anyway. signature.asc Description: PGP signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Tue, Nov 05, 2013 at 11:43:16PM +0100, Marko Randjelovic wrote: On Sat, 26 Oct 2013 11:07:36 +0200 Lucas Nussbaum lea...@debian.org wrote: I think that it would be a failure of the Debian project if we had to have a GR about such a technical decision. I think that we need to trust that the Technical Committee will make the right decision. A GR about this will likely result in splitting and hurting the project even more. This is not at all merely a technical decision. I disagree strongly. First of all, I do not agree Debian community is hurt because of split about init system, I disagree strongly. Please read through every flame thread over the last 4 years and try to say this with a straight face. nor that some problems would be solved by Tech Committee rules about default init system. Init system is an essential part of any UNIX-like system. If anything can undermine an OS, it is init system. What? Sorry, what? Are you disagreeing with yourself? If it's so important to a UNIX system, why do you say it's not technical ... Big companies all over and over again show they care much more about their economic interests than about interests of free software community. As of my understanding, Debian should be an independent project, devoted to interest of its community (users), and not the interests of any companies. However, it is obvious companies push their software because they control their development, but then if such software becomes essential for Debian, they control Debian. If you read free software principles elaborated by Richard M. Stallman and FSF, it is clear that the point is exactly in having control over your life, i.e. being independent (or in other words not under control) of any companies. No, that's not what RMS and the FSF means. They claim, by ensuring software you use is free, you can ensure that you retain your rights when using your computer by granting you basic freedoms (the four freedoms). One of those freedoms is to use the software commercially, just FYI. Even if such projects are forked, it is not a good outcome, since they are to (and unnecessarily) complex and community will have much problems in adding any additional features or other modifications, while companies can do it because they pay full time developers and they have both psychological interest to impress their users and to control direction of free software development. If anything looks like a Trojan horse, it's an init system controlled by a big company. If someone is rushing this decision, it may be only in interest of companies that want by the (false) argument of urgency use Tech Committee to make such decision without taking into consideration neither interests nor attitude of whole Debian community. my day job is not in Debian development. I pushed it to the tech ctte out of my own free will, and I assure you no big corp is using me as a sock puppet. it's urgent, and it *is* causing social problems in Debian. We don't want free software becomes just a marionette of big business. The fun thing about F/OSS is free software *can* become a marionette and we're still much more free than before (and can still express the same rights as if it wasn't a mega-corp). That being said I do like the non commercial nature of Debian, but this is not central to good free software. If a software insists on depending on any particular init system for some only to them knows reason, then it cannot be default or we are becoming hostages of such software. We shall not stand in the way of progress. logind, systemd (such as socket based activation, dependency booting) in particular, and friends are technical wins. We'd be silly to not take them. If you want to hold your own system back, there's nothing stoping you (and your rights granted by f/oss software allow you to do so). Users who want to use it should take care on their own about installing needed dependencies. users generally don't care about dependencies, and care more about a working system. Gnome all the time keeps making us unpleasant surprises. Gnome is bloated, depend on to many software, and now even on specific init system. Its configuration system is surely not to much like Windows registry as it looks based on gconftool, but it is obviously to complex and far away from UNIX philosophy. When GDM3 appeared, I couldn't change theme, most options were missing. The picture was hardcoded in exe. Since then I don't use GDM anymore. And now Gnome depend on systemd. If systemd one day puts us in similar situation, will it be possible to remove it? What will systemd depend on a few years later? This is an argument unrealted to your main point, and I suggest you post this elsewhere. And SysVInit just works well and it is simply enough. It has much less dependencies than systemd. Do not make unneeded weight on people to learn systemd in addition to shell
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
previously on this list Ben Hutchings contributed: In other words, Canonical gets the right to take a free software contribution and make it proprietary. The contributors gets to own the software, and can continue releasing it as free software, but can't prevent Canonical from making non-free versions of it. I don't find that an acceptable situation. But I saw today that this paragraph goes on with: As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the license or licenses which We are using for the Material on the Submission Date. My understanding (as a non-expert on legalese en_*) is, that Canonical would only be allowed to re-license the Contribution under a dual-license scheme, with (a) the original license, and (b) $whatever-they-want. [...] Yes, but that says nothing about the rest of the program that it's a part of, nor that they will continue to distribute the Contribution. Since the contributor, retaining copyright, can give that license to anyone anyway, this condition doesn't appear to have any meaningful effect. Ben. I don't see why this should affect the decision at all personally especially far less than less co-operative upstreams though perhaps a pure BSD license could be seen as a free-er plus point. It basically means they have reserved the right that they may never use but put in jut in case likely for other projects to stop contributing or publishing the source of their work to the project but continue to use the communities past work. The community could even then decide that just canonical was not allowed to use any of their changes from then on whilst still benefiting from Canonical's past work. At the end of the day whatever increases the chance of code being done for good reasons and the good of the community is what is important and forcing publication may?? help twist the arms of the less important contributors but also hinders that likelihood in reduced initial take up anyway possibly including partial release. Apache's BSD based and Googles BSD based licenses and many others would all allow this, what has been and is going to be contributed in a constructive and forth coming way for the good of all is what is important. -- ___ '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/304170.20633...@smtp139.mail.ir2.yahoo.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 10/30/2013 11:58 PM, Tollef Fog Heen wrote: ]] Wouter Verhelst Yes, absense of documentation is common on Unix and Linux systems; but no, I do not think that this is okay, or that we should in any way encourage that sort of thing. By absense of documentation, are you referring to the almost 10% of the source base that are comments or the 15% that is DocBook XML based documentation? (Almost 14kLOC and almost 36kLOX, respectively.) Wouter was very clear in his message. If you didn't get it, I would suggest that you re-read. 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/5271f580.2040...@debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, 30 Oct 2013 21:50:53 -0400, Theodore Ts'o wrote: It's not necessarily the init script author who might want the degrees of freedom, but the local system administrator. The most basic is the idea that whether you can control (via shell scrpit fragments) whether or not a service should start at all, and what options or environments should be enabled by pasing some file. The fact that we can put that sort of thing in configuration files such as /etc/default/*, for example. Yes, yes, you can do this via if you use system V init scripts scripts in backwards compatibility mode, but you've argued that we should be moving briskly away from that. In which case system administrators will need to hand-edit the services files by hand, which will no doubt increase the chances of conflicts at package upgrade time, compared to if the configuration options were isolated away in files such as /etc/default/rsync (for example). Both upstart and systemd allow you to source any file and run any script from their .conf/.service files. In Fedora 19: You can source anything with EnvironmentFile= and run anything from ExecStartPre=, ExecStart=, ExecStartPost=. /usr/lib/systemd/system/iptables.service has ExecStart=/usr/libexec/iptables/iptables.init start where /usr/libexec/iptables/iptables.init is the /etc/rc.d/init.d/iptables sysvinit script of Fedora 15. iptables also has /usr/libexec/initscripts/legacy-actions/iptables/save and it runs exec /usr/libexec/iptables/iptables.init save. Also, /usr/lib/systemd/system/nfs-server.service sources /etc/sysconfig/nfs with EnvironmentFile=/etc/sysconfig/nfs and runs scripts in /usr/lib/nfs-utils/scripts/. (It's surprising that there isn't a canonical location for custom systemd scripts. I don't have an Arch instance on which to check, but AFAIK its iptables.service calls a script that's in /usr/lib/systemd/scripts/.) In Ubuntu 13.10: I would've liked to compare like for like but neither iptables-persistent and nfs-kernel-server have upstart jobs. Let's assume that /etc/init/nfs-kernel-server.conf exists and that you want to override it. # vi /etc/init/nfs-kernel-server.override ... script [ -r /home/ted/ted-nfs-kernel-server ] \ . /home/ted/ted-nfs-kernel-server either call a script or put your commands here end 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/5272144a.3000...@gmail.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Oct 30, 2013 at 08:41:10PM -0400, Theodore Ts'o wrote: On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote: Well, I've said this before, but I think it's worth reiterating. Either upstart or systemd configurations are *radically better* than init scripts on basically every axis. They're more robust, more maintainable, easier for the local administrator to fix and revise, better on package upgrades, support new capabilities, etc. Can you please go in to more detail why you believe this was true? The lsat time I played with Upstart, I saw a lot of policy moved from shell scripts into C code (which I would have to edit and recompile) if I wanted to change things. I'm surprised by this comment. Very little policy is actually encoded in upstart's C code; in fact, the only policy I can think of offhand that is is some basic stuff around filesystems, which, aside from some must-have kernel filesystems without which it can't boot the rest of the system, should be entirely overrideable via /etc/fstab. Perhaps you could expand on what policies you saw a need to change? I also was extremely frustrated with a massive lack of documentation, where at least with shell scripts I could read the scripts to understand what was going on. There's an awful lot of documentation available for upstart, but of course people look for documentation in lots of different ways and we aren't necessarily presenting the documentation where and when we need it. There's comprehensive documentation available at http://upstart.ubuntu.com/cookbook/, but from context it's possible that's not what you were looking for. Aside from adding links to manpages to all of the upstart jobs themselves (which I don't think is reasonable), are there things you think should be done to make the right documentation easy to find? (For starters, what were you trying to find documentation of?) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Op 31-10-13 02:50, Theodore Ts'o schreef: On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote: I suspect you and I have a root disagreement over the utility of exposing some of those degrees of freedom to every init script author, but if you have some more specific examples of policy that you wanted to change but couldn't, I'd be interested in examples. It's not necessarily the init script author who might want the degrees of freedom, but the local system administrator. The most basic is the idea that whether you can control (via shell scrpit fragments) whether or not a service should start at all, and what options or environments should be enabled by pasing some file. The fact that we can put that sort of thing in configuration files such as /etc/default/*, for example. This, in my opinion, is one of the worst abominations we currently have in Debian. Whether an init script should run at boot time has no relation whatsoever to whether it should run when the system administrator calls it manually. Yet, with ENABLE= variables in /etc/default, this is related, because the initscript will say I'm disabled, go edit this file if you want to start me, even if you just want to start a daemon just this once manually, for testing. AIUI, both upstart and systemd have configuration options where you can tell the system that this particular service should not start at boot; that will then, however, not affect the result when one manually tries to start the service. I'm not sure that's a very good argument ;-) -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- 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/52721ab2.7030...@debian.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Op 30-10-13 16:58, Tollef Fog Heen schreef: ]] Wouter Verhelst Yes, absense of documentation is common on Unix and Linux systems; but no, I do not think that this is okay, or that we should in any way encourage that sort of thing. By absense of documentation, are you referring to the almost 10% of the source base that are comments or the 15% that is DocBook XML based documentation? (Almost 14kLOC and almost 36kLOX, respectively.) That particular comment was not referring to systemd specificaly. I haven't looked at the systemd code in much detail myself. What I wrote in the above-quoted post was based on the comment of this OpenRC developer. Perhaps I should have checked some more before repeating that comment, though. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- 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/527223c6.7000...@debian.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
* Theodore Ts'o: The most basic is the idea that whether you can control (via shell scrpit fragments) whether or not a service should start at all, and what options or environments should be enabled by pasing some file. Curiously, a lot of system administrators do not do this correctly using sysvinit, causing system daemons to start unexpectedly after installing package updates. I hope that a new init system will finally allow us to have something like chkconfig (not the best name in the world, I admit) that works reliably. -- 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/87sivhofxq@mid.deneb.enyo.de
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, Oct 31, 2013 at 01:41:53AM -0700, Steve Langasek wrote: I'm surprised by this comment. Very little policy is actually encoded in upstart's C code; in fact, the only policy I can think of offhand that is is some basic stuff around filesystems, which, aside from some must-have kernel filesystems without which it can't boot the rest of the system, should be entirely overrideable via /etc/fstab. Perhaps you could expand on what policies you saw a need to change? The details are a bit fuzzy, because this was a quite a while ago, when Upstart was first introduced into Ubuntu, and it was so frustrating that it was what caused me to abandon Ubuntu and switch back to Debian. The high bit was I couldn't get a particular service to start (it might have been bind, or some such), and I had no idea how to debug the darned thing. With shell scripts, it's possible to insert echo debug 1 $variable /tmp/debug.log to figure out what's going on. With upstart, I had no way of figuring out what was going on, and why it was failing, and the no user-serviceable parts inside was extremely frusrtating. I'm sure part of the problem was lack of documentation. That seems to be a common theme with many of these higher level language systems. They may be powerful if you know the magic XML file to edit (in the case of policy kit), but it took me several hours before I figured out even something as simple as say 'yes' to for all authorization questions, which is how I still run to this day, because (a) the default of prompting for the root password in popup windows all the time was too painful, and (b) trying to figure out how to XML language, and all of the triggeers, etc., was ***far*** too painful. One of the nice things about shell scripts is that they are far more self-documenting, and easier to debug, than XML and other 'higher-level' configuration files (at least for this dumb kernel hacker :-). So hopefully that is something the technical committee will take into account --- how well things are documented, both in terms of a comprehensive reference manual, and a tutorial that helps people with common things that system administrators might want to do. The docuementation you pointed to at http://upstart.ubuntu.com/cookbook/ is something I wish I had access to when I first was forced to use Upstart; maybe if Upstart was as polished back then, I might not have given up on Ubuntu in disgust. Regards, - Ted -- 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/20131031112012.gc9...@thunk.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Oct 30, 2013 at 10:52:15PM -0700, Russ Allbery wrote: You can do quite a bit with the hooks that are part of the specification of both types of files. For example, logic that you may add to control whether the service should start at all can be implemented by adding a pre-start stanza to the upstart configuration. ExecStartPre=/bin/false will make the service be considered failed. The ExecStartPre line can of course be an executable that implements more checking or logic. Ah, thank you! I got lost in the systemd.* man pages and didn't find the systemd.service one somehow (even though it's right there listed first; sigh). I found the systemd man pages, and came across the definition ExecStartPre, but I didn't make the connection that returning false would be sufficient to stop the daemon from starting. It was there, but that's the difference between a reference manual and a tutorial/cookbook -- a reference manual won't necessarily explain the implifications of the unit fails. The upstart documentation, from my brief examination, seems to be much more approachable for someone who is starting from ground zero. - Ted -- 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/20131031112352.gd9...@thunk.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On a different subject, which I don't think has been raised so far --- has the Debian maintinares for the upstart package made any comments about bug fixes or code contributions from Debian Developers who are personally opposed to being forced to sign copyright assignment agreements, or for whom their employers forbid them from signing copyright assignment aggrements (both of which apply to me). If I submit a bugfix as part of a bug report, will the Upstart maintainers reject it out of hand if I have not executed a copyright assignment with Canonical, or will they be willing to consider either carrying it as a local Debian patch, and/or rewrite the commit and submit it upstream to Canonical? I don't think copyright assignment is a concern which afflicts Systemd, although there is a related concern which is that the upstream systemd developers appear to have a very strong point of view, and if there is some change which is needed for Debian or Debian's users, and it conflicts with their point of view, I could imagine situations where the Debian maintainers for systemd might need to carry a Debian-specific change, perhaps indefinitely. Is this something that has been considered by the maintainers, and is this something which is important to other DD's and the tech-committee? - Ted -- 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/20131031114537.ge9...@thunk.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi, On 31/10/13 12:45, Theodore Ts'o wrote: On a different subject, which I don't think has been raised so far --- has the Debian maintinares for the upstart package made any comments about bug fixes or code contributions from Debian Developers who are personally opposed to being forced to sign copyright assignment agreements, or for whom their employers forbid them from signing copyright assignment aggrements (both of which apply to me). If I submit a bugfix as part of a bug report, will the Upstart maintainers reject it out of hand if I have not executed a copyright assignment with Canonical, or will they be willing to consider either carrying it as a local Debian patch, and/or rewrite the commit and submit it upstream to Canonical? I don't think copyright assignment is a concern which afflicts Systemd, although there is a related concern which is that the upstream systemd developers appear to have a very strong point of view, and if there is some change which is needed for Debian or Debian's users, and it conflicts with their point of view, I could imagine situations where the Debian maintainers for systemd might need to carry a Debian-specific change, perhaps indefinitely. That's no different to any other package. Is this something that has been considered by the maintainers, and is this something which is important to other DD's and the tech-committee? See e.g. https://wiki.debian.org/Debate/initsystem/upstart https://wiki.debian.org/Debate/initsystem/systemd (look for agreement) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 (look for CLA) Personally I think this is an issue that the TC should take into account, though it is true that we could always fork upstart and take patches from upstream as needed. Cheers, Emilio -- 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/52724c30.2090...@debian.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, 31 Oct 2013, Florian Weimer wrote: Curiously, a lot of system administrators do not do this correctly using sysvinit, causing system daemons to start unexpectedly after installing package updates. What *is* the correct way, anyway? My coworkers tell me to delete the symlinks in /etc/rc*.d/ but that’s sysv-rc specific, and file-rc’s config is now always autogenerated from insserv (which is a major PITA). Most initscripts do not have a real option to disable it from /etc/defaults/ either, and chmod -x’ing the dæmon is unsuitable when you want to run it from some other compo- nent and/or manually (e.g. I have a custom rngd setup). And chmod -x on the init script itself is most likely not persistent across package upgrades. So I ended up writing 'exit 0' as the first line into the respective /etc/default/ file to disable them… or changing the initscript directly (also 'exit 0' as first line after the shebang), leading to conffile prompts. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- 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/alpine.deb.2.10.1310311324320@tglase.lan.tarent.de
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi Thorsten, On Wed, Oct 30, 2013 at 04:05:48PM +, Thorsten Glaser wrote: * Write scripts for one system and generate the other from it or even * Write ???Debian init declaration??? and let something take care of generating an initscript and whatever the other systems use out of it You are welcome to show that this works. Heck, you don't even do the full work, because Joachim Breitner and others have done it for you: https://wiki.debian.org/MetaInit Please notify me when you upload a package that uses metainit (or your own solution to the problem of too many standards[1]), so I can evaluate it. Helmut [1] http://xkcd.com/927/ -- 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/20131031124141.ga2...@alf.mars
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 31/10/13 12:27, Thorsten Glaser wrote: On Thu, 31 Oct 2013, Florian Weimer wrote: Curiously, a lot of system administrators do not do this correctly using sysvinit, causing system daemons to start unexpectedly after installing package updates. What *is* the correct way, anyway? My understanding is that something like `update-rc.d $service disable` is the recommended way these days, and I recommend that in a couple of game server packages (which seem like a likely thing to want to install but only run infrequently or manually). sysv-rc's update-rc.d understands how to disable either insserv/sysv-rc or systemd services; it doesn't appear to understand Upstart or OpenRC yet, but perhaps one or both of those dpkg-diverts it, and has a replacement that does. file-rc ships its own update-rc.d implementation (at least, according to the package description it does) which hopefully has the enable/disable subcommands. 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/52725537.2090...@debian.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, 31 Oct 2013, Simon McVittie wrote: file-rc ships its own update-rc.d implementation (at least, according to the package description it does) which hopefully has the enable/disable subcommands. It does, but… My understanding is that something like `update-rc.d $service disable` … isn’t that overwritten by the update-rc.d commands in the maintainer scripts (postinst) when the package is upgraded? bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- 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/alpine.deb.2.10.1310311406010@tglase.lan.tarent.de
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
* Thorsten Glaser [Thu Oct 31, 2013 at 01:27:12PM +0100]:
On Thu, 31 Oct 2013, Florian Weimer wrote:
Curiously, a lot of system administrators do not do this correctly
using sysvinit, causing system daemons to start unexpectedly after
installing package updates.
What *is* the correct way, anyway?
My coworkers tell me to delete the symlinks in /etc/rc*.d/
but that’s sysv-rc specific,
[...]
And wrong, you'll get the symlinks restored on package upgrades.
| Disabling a daemon service is quite simple. You either remove the
| package providing the program for that service or you remove or
| rename the startup links under /etc/rc${runlevel}.d/. If you rename
| them make sure they do not begin with 'S' so that they don't get
| started by /etc/init.d/rc. Do not remove all the available links or
| the package management system will regenerate them on package
| upgrades, make sure you leave at least one link (typically a 'K',
| i.e. kill, link).
--
http://www.debian.org/doc/manuals/securing-debian-howto/ch3.en.html#s-disableserv
So mv /etc/rc#.d/S*foo /etc/rc#.d/K*foo is supposed to do the
trick for sysv-rc.
regards,
-mika-
signature.asc
Description: Digital signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 31/10/13 13:06, Thorsten Glaser wrote:
My understanding is that something like `update-rc.d $service disable`
… isn’t that overwritten by the update-rc.d commands in the
maintainer scripts (postinst) when the package is upgraded?
Not in the sysv-rc implementation, at least. `update-rc.d $service
disable` does not remove the symlinks: instead, it renames the S??
symlinks to K??, so the service is stopped in all runlevel changes.
sysv-rc interprets this as installed, but disabled by the sysadmin.
For the defaults (and deprecated start/stop) actions, If any files
named /etc/rc${runlevel}.d/[SK]??${name} already exist then update-rc.d
does nothing, according to the man page, so maintainer scripts that do
the obvious thing shouldn't accidentally re-enable daemons.
In the past, some packages' maintainer scripts might have incorrectly
re-enabled daemons as a side-effect of adjusting the boot sequence order
(e.g. moving a daemon's start links from S20foo to S30foo), but AIUI
that was always considered to be a bug, and now that we have insserv,
it's a piece of error-prone maintainer script that isn't needed any more.
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/52725ded.5080...@debian.org
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, 31 Oct 2013 06:33:44 +0100 John Paul Adrian Glaubitz wrote: two places where to place systemd service files. One is located below /usr/lib/systemd which is the directory where service files provided by the package are placed, and one is /etc/systemd where your own, custom service files are located. If you created a custom local script, just to append something to the daemon's command line, is that going to clobber the package's service file indefinitely? So if a new version or security update adds a -s flag telling the daemon to 'run in secure mode' your local definition might never pick that up? In this situation, I think I'd prefer to see a conffile prompt. And overriding the *entire* service file seems excessive if you wish to override just one line of the package's service file. 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/52725f79.4020...@pyro.eu.org
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, Oct 31, 2013 at 01:47:37PM +, Steven Chamberlain wrote: And overriding the *entire* service file seems excessive if you wish to override just one line of the package's service file. You add a file /etc/systemd/system/xxx.service.d/yyy.conf with the following contents: [Service] SettingToOverride=whatever This is appended on top of the original file, overriding SettingToOverride. http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Description, around the middle. You can view the overrides with systemd-delta (http://www.freedesktop.org/software/systemd/man/systemd-delta.html). Zbyszek -- 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/20131031135743.gt28...@in.waw.pl
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
]] Theodore Ts'o The upstart documentation, from my brief examination, seems to be much more approachable for someone who is starting from ground zero. Have you read the «The systemd for Administrators Blog Series» linked to from http://www.freedesktop.org/wiki/Software/systemd/ ? -- 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/87ob65sflr@qurzaw.varnish-software.com
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, 31 Oct 2013 06:33:44 +0100 John Paul Adrian Glaubitz wrote:
messed up custom code may end up rendering your whole system unusable
if you are smart enough to mess up an rm command. Just have a look
at this wonderful bug in upstart [1].
[1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177
This doesn't appear to be a bug in Upstart. A service file assumed the
caller would set MOUNTPOINT=/tmp in the environment, and invoked this
(inline) shell script:
cd ${MOUNTPOINT}
find . -depth -xdev $TEXPR $EXCEPT ! -type d -delete
I assume you could launch bad code from systemd just as easily.
(Actually, if you can't, that's probably a limitation).
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/52726368.5060...@pyro.eu.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
]] Theodore Ts'o I don't think copyright assignment is a concern which afflicts Systemd, although there is a related concern which is that the upstream systemd developers appear to have a very strong point of view, and if there is some change which is needed for Debian or Debian's users, and it conflicts with their point of view, I could imagine situations where the Debian maintainers for systemd might need to carry a Debian-specific change, perhaps indefinitely. systemd is not burdened with copyright assignment, no. So far, it has not been necessary to carry patches forever as upstream is generally interested in unifying and getting one way that works well for everybody. This does mean that Debian might need to change in some cases, but in other cases it's the other Linux distros that change. (An example here is the unification and use of /etc/hostname where Fedora and SUSE changed to match Debian.) Depending on the reasons, the size and the complexity of the patch, I would be willing to carry patches for a long time. I want to work closely with upstream to ensure we don't introduce incompatibilities, and I expect them to do the same in the other direction. That's also been my experience so far. Examples I can think of here are keeping the insserv and LSB support around for a long time, even if they're removed upstream. Another would be keeping support for early-boot sysvinit scripts, since we need that for at least a while. -- 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/87k3gtsf80@qurzaw.varnish-software.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Oct 31, 2013, at 07:45 AM, Theodore Ts'o wrote: On a different subject, which I don't think has been raised so far --- has the Debian maintinares for the upstart package made any comments about bug fixes or code contributions from Debian Developers who are personally opposed to being forced to sign copyright assignment agreements, or for whom their employers forbid them from signing copyright assignment aggrements (both of which apply to me). Actually, contributing to Upstart does not require copyright assignment (as for example, would contributing to an FSF-owned GNU project). Instead, it requires a Contributor License Agreement be signed: http://www.canonical.com/contributors The upstart wiki is using inaccurate terminology in the text that gets you here, and it should be corrected. The difference of course is that with the CLA, you continue to own the copyright in the contribution, with full rights to re-use, re-distribute, and continue modifying the contributed code, but it allows Canonical to use your contribution in certain ways. Read the above link and the linked FAQ for details. Cheers, -Barry signature.asc Description: PGP signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, Oct 31, 2013 at 10:14:06AM -0400, Barry Warsaw wrote: The difference of course is that with the CLA, you continue to own the copyright in the contribution, with full rights to re-use, re-distribute, and continue modifying the contributed code, but it allows Canonical to use your contribution in certain ways. Read the above link and the linked FAQ for details. That is indeed different, but no one should sign either one. Ever. -- 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/20131031143840.ga13...@scru.org
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, Oct 31, 2013 at 02:04:24PM +, Steven Chamberlain wrote: [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177 This doesn't appear to be a bug in Upstart. Strictly, no, but there was a surprising amount of resistance to adding some boilerplate to that script to something sane when MOUNTPOINT was undefined. Of course that resistance was from the former maintainer who is no longer involved in Upstart development, and so this should not be used as a con point against Upstart nowadays. -- 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/20131031155925.ga21...@bryant.redmars.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 10/31/2013 03:04 PM, Steven Chamberlain wrote: On Thu, 31 Oct 2013 06:33:44 +0100 John Paul Adrian Glaubitz wrote: messed up custom code may end up rendering your whole system unusable if you are smart enough to mess up an rm command. Just have a look at this wonderful bug in upstart [1]. [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177 This doesn't appear to be a bug in Upstart. A service file assumed the caller would set MOUNTPOINT=/tmp in the environment, and invoked this (inline) shell script: That wasn't my point either. I just meant to illustrate how dangerous shell scripts can be in the context of init systems and this bug was the first one that came to my mind in this context. 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/52727e7f.8040...@physik.fu-berlin.de
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Oct 30, 2013 at 09:50:53PM -0400, Theodore Ts'o wrote: On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote: I suspect you and I have a root disagreement over the utility of exposing some of those degrees of freedom to every init script author, but if you have some more specific examples of policy that you wanted to change but couldn't, I'd be interested in examples. It's not necessarily the init script author who might want the degrees of freedom, but the local system administrator. The most basic is the idea that whether you can control (via shell scrpit fragments) whether or not a service should start at all, and what options or environments should be enabled by pasing some file. The fact that we can put that sort of thing in configuration files such as /etc/default/*, for example. Yes, yes, you can do this via if you use system V init scripts scripts in backwards compatibility mode, but you've argued that we should be moving briskly away from that. In which case system administrators will need to hand-edit the services files by hand, which will no doubt increase the chances of conflicts at package upgrade time, compared to if the configuration options were isolated away in files such as /etc/default/rsync (for example). FYI, the recommended, simplest way to administratively disable a service in upstart is: # echo manual /etc/init/$service.override You can certainly do more complex checks by adding a pre-start script if you want, but for the common case of administratively disabling, the above is more than sufficient. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, Oct 31, 2013 at 03:59:25PM +, Jonathan Dowland wrote: On Thu, Oct 31, 2013 at 02:04:24PM +, Steven Chamberlain wrote: [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177 This doesn't appear to be a bug in Upstart. Strictly, no, but there was a surprising amount of resistance to adding some boilerplate to that script to something sane when MOUNTPOINT was undefined. No, there was not. See comment #24: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177/comments/24 That script is not in the upstart package. If the bug should have been fixed by changing the mountall package, then a bug report against upstart is indeed invalid. And an observation that you shouldn't randomly run scripts from early boot on a running system without understanding what they do (Don't Do That Then), while not the most helpful remark to make to someone who just stepped on a land mine and deleted their whole filesystem, doesn't actually say anything about whether he was resistant to adding that boilerplate. The mountall fix was pushed to the VCS the same day the bug came to Scott's attention. Scott had an idiosyncratic approach for handling bug flow, and his bedside manner when dealing with external bug reporters was occasionally less than perfect; but nothing here warrants excoriating him as being cavalier towards users' data. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, Oct 31, 2013 at 10:14:06AM -0400, Barry Warsaw wrote: Actually, contributing to Upstart does not require copyright assignment (as for example, would contributing to an FSF-owned GNU project). Instead, it requires a Contributor License Agreement be signed: http://www.canonical.com/contributors Quoting from the PDF linked from that page (Canonical Individual Contributor License Agreement for individual contributors): Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses. In other words, Canonical gets the right to take a free software contribution and make it proprietary. The contributors gets to own the software, and can continue releasing it as free software, but can't prevent Canonical from making non-free versions of it. I don't find that an acceptable situation. Compare that to the FSF, where they guarantee the contributed software will always remain free software. (Also, not all GNU projects require copyright assignment.) Both Canonical and the FSF want you to give them something, but the FSF promises to keep it free, and indeed, goes to great lengths to define (in the copyright assignment contract) what it means for the software to be free: it's not just whatever license the FSF wants to use. Disclaimer: I've not assigned any copyrights to the FSF, I have merely read around the debates on this and listened to many Free as in freedom oggcast episodes with Bradley Kuhn and Karen Sandler (http://faif.us/). -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- 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/20131031181031.GG4670@holywood
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
previously on this list Theodore Ts'o contributed: So hopefully that is something the technical committee will take into account --- how well things are documented, both in terms of a comprehensive reference manual, and a tutorial that helps people with common things that system administrators might want to do. The docuementation you pointed to at http://upstart.ubuntu.com/cookbook/ is something I wish I had access to when I first was forced to use Upstart; maybe if Upstart was as polished back then, I might not have given up on Ubuntu in disgust. I would like to have seen that, I think the man page found via apropos upstart should point to that doc in /usr/share as well as the http for offline use at the very least, even if a pdf/html has to be copied off to be read on a server. I don't use Linux for any servers that I currently deploy but I can see that being very annoying in certain situations. I have had my time wasted with almost every init system except OpenRC which is pretty much intuitive but still not so intuitive as OpenBSD's being my favourite where you have around 6 files (few for lockdownability but actually simplicity too) ALL in /etc and with rc in the name and one directory called rc.d all of which have very good man pages including giving reasons for why things are done in as few files as possible even though you could work it out yourself rather quickly. Of course good man pages is one of OpenBSD's watch words or primary goals and security and minimal defaults comes before speed and ease of average user use so it shouldn't be that surprising. rc.conf has the defaults and the line . /etc/rc.conf.local rc.conf.local can have overrides such as sshd_flags=NO for off or sshd_flags= for default or sshd_flags=-4 for ipv4 only -- ___ '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/947826.52397...@smtp103.mail.ir2.yahoo.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
previously on this list Wouter Verhelst contributed: By absense of documentation, are you referring to the almost 10% of the source base that are comments or the 15% that is DocBook XML based documentation? (Almost 14kLOC and almost 36kLOX, respectively.) That particular comment was not referring to systemd specificaly. I haven't looked at the systemd code in much detail myself. What I wrote in the above-quoted post was based on the comment of this OpenRC developer. Perhaps I should have checked some more before repeating that comment, though. Well he actually said that seperating/finding the logind code and any relevent documentation was difficult. So an accurate rebuttal would be ?kLOC and ?kLOX concerning logind and perhaps a description of all the functionality of logind from those comments. -- ___ '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/290887.44189...@smtp132.mail.ir2.yahoo.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Oct 31, 2013, at 06:10 PM, Lars Wirzenius wrote: Quoting from the PDF linked from that page (Canonical Individual Contributor License Agreement for individual contributors): Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses. In other words, Canonical gets the right to take a free software contribution and make it proprietary. The contributors gets to own the software, and can continue releasing it as free software, but can't prevent Canonical from making non-free versions of it. I don't find that an acceptable situation. All developers need to make up their own[*] minds on such issues of course, so I would never tell you that you're wrong. I could tell you my own opinion, but I'm not sure that anyone would really care. :) As a project leader for a GNU project owned by the FSF that does require copyright assignments, I can tell you that FSF policy occasionally prevents me from accepting code from people who can't or won't sign the copyright assignments. The argument goes: why should I have to give up my ownership rights in order for you to accept my changes? The analogy is made to a musician who had (has?) to give their copyrights over to the record company in order to make an album. Those musicians lost control over their music. (Of course, I'm not morally equating the FSF to record companies. :) The trade-off in the two approaches is between retaining copyright while allowing the possibility of non-free use (CLA) vs. giving up copyright but guaranteeing free use (FSF). The FLOSS world has a very wide range of such contributor agreements, such as the Python Software Foundation license which lets you retain copyright and promises that your changes (and derivatives there-of) to always be available under an open source license. In any event, my point was to be factually accurate about exactly the deal that you agree to in order to contribute to upstart. Cheers, -Barry [*] or have their employers make up their minds for them. ;) signature.asc Description: PGP signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
--text follows this line-- Theodore Ts'o writes (Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.): On a different subject, which I don't think has been raised so far --- has the Debian maintinares for the upstart package made any comments about bug fixes or code contributions from Debian Developers who are personally opposed to being forced to sign copyright assignment agreements, or for whom their employers forbid them from signing copyright assignment aggrements (both of which apply to me). If I submit a bugfix as part of a bug report, will the Upstart maintainers reject it out of hand if I have not executed a copyright assignment with Canonical, or will they be willing to consider either carrying it as a local Debian patch, and/or rewrite the commit and submit it upstream to Canonical? I expect that Debian's upstart maintainers will take patches from refusenik submitters into the Debian version without demanding that they get involved with upstream and the CLA. That means that the patches might not go upstream, but that's how Free Software works, after all: we have the legal right to make our own version without reference to upstream, and with something the size of upstart doing so is entirely practical. Indeed, I think the Debian maintainers of a package with a legally-recalcitrant upstream have a duty not to insist on external legal formalities when taking patches into the Debian version of a program, and that includes a duty to take into Debian, and carry, patches which really ought to go upstream but which are being rejected because of upstream's legal policy. Is this something that has been considered by the maintainers, and is this something which is important to other DD's and the tech-committee? If I thought there was going to be a problem with this it would be a show-stopper for upstart for me. But my understanding is that this is not going to be a problem. CLA-less patches will simply live in Debian, as would be expected. Ian. -- 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/21106.49115.363059.178...@chiark.greenend.org.uk
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, Oct 31, 2013 at 07:20:12AM -0400, Theodore Ts'o wrote: On Thu, Oct 31, 2013 at 01:41:53AM -0700, Steve Langasek wrote: I'm surprised by this comment. Very little policy is actually encoded in upstart's C code; in fact, the only policy I can think of offhand that is is some basic stuff around filesystems, which, aside from some must-have kernel filesystems without which it can't boot the rest of the system, should be entirely overrideable via /etc/fstab. Perhaps you could expand on what policies you saw a need to change? The details are a bit fuzzy, because this was a quite a while ago, when Upstart was first introduced into Ubuntu, and it was so frustrating that it was what caused me to abandon Ubuntu and switch back to Debian. The high bit was I couldn't get a particular service to start (it might have been bind, or some such), and I had no idea how to debug the darned thing. With shell scripts, it's possible to insert echo debug 1 $variable /tmp/debug.log to figure out what's going on. With upstart, I had no way of figuring out what was going on, and why it was failing, and the no user-serviceable parts inside was extremely frusrtating. Ah. Sounds like you may have been hit by upstart's lack of logging support for jobs at the time. Upstart has supported logging of all output from jobs (stderr,stdout) since 1.5, which was included in 12.04 LTS. This was added precisely because of that sort of frustrating experience you describe - an experience that was shared not only by administrators, but also Ubuntu developers trying to debug remaining corner cases in the init system integration itself. So on 12.04 and later, you just look at /var/log/upstart/$job.log to get the debugging info you're looking for. And if you need to debug upstart's own state, you can boot with --verbose (or if necessary, --debug) to get useful information dumped to kmsg - or turn this on with 'initctl log-priority info' after boot. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, 31 Oct 2013 18:10:31 +, Lars Wirzenius wrote: On Thu, Oct 31, 2013 at 10:14:06AM -0400, Barry Warsaw wrote: Actually, contributing to Upstart does not require copyright assignment (as for example, would contributing to an FSF-owned GNU project). Instead, it requires a Contributor License Agreement be signed: http://www.canonical.com/contributors Quoting from the PDF linked from that page (Canonical Individual Contributor License Agreement for individual contributors): Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses. I also re-read this PDF today, and I'm a bit confused. My prior understanding (and personal POV) was, as you say: In other words, Canonical gets the right to take a free software contribution and make it proprietary. The contributors gets to own the software, and can continue releasing it as free software, but can't prevent Canonical from making non-free versions of it. I don't find that an acceptable situation. But I saw today that this paragraph goes on with: As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the license or licenses which We are using for the Material on the Submission Date. My understanding (as a non-expert on legalese en_*) is, that Canonical would only be allowed to re-license the Contribution under a dual-license scheme, with (a) the original license, and (b) $whatever-they-want. Is this interpretation correct? Or am I mis-reading the which We are _using_ part, or something else? Of course, relicensing under $free+$whatever is still debatable but at least it's a different issue then they can turn it into proprietary software, at least for me. I think a clarification from the upstart maintainers and/or other savvy people on this issue would be helpful for the whole discussion, since -- as I understand it -- this CLA question is one of the major roadblocks for the adoption of upstart as the default init system in Debian. 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 `- NP: Ry Cooder: I Got Mine signature.asc Description: Digital signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Thu, Oct 31, 2013 at 11:40:20PM +0100, gregor herrmann wrote: [...] In other words, Canonical gets the right to take a free software contribution and make it proprietary. The contributors gets to own the software, and can continue releasing it as free software, but can't prevent Canonical from making non-free versions of it. I don't find that an acceptable situation. But I saw today that this paragraph goes on with: As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the license or licenses which We are using for the Material on the Submission Date. My understanding (as a non-expert on legalese en_*) is, that Canonical would only be allowed to re-license the Contribution under a dual-license scheme, with (a) the original license, and (b) $whatever-they-want. [...] Yes, but that says nothing about the rest of the program that it's a part of, nor that they will continue to distribute the Contribution. Since the contributor, retaining copyright, can give that license to anyone anyway, this condition doesn't appear to have any meaningful effect. Ben. -- Ben Hutchings For every complex problem there is a solution that is simple, neat, and wrong. -- 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/20131031231159.gc3...@decadent.org.uk
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Russ, It seems we don't have at all the same reading of Patrick post. Note that what's below is my comments on your comments about Patrick's comments, and do not represent my view (which I do not wish to express it more at this point). On 10/30/2013 07:16 AM, Russ Allbery wrote: the core content was that he doesn't think cgroup management is particularly difficult The core content of Patrick post is that Lennart is using circular thinking and is pretending that nobody but him can implement things. The person who is being overly pretentious here is Lennart, not Patrick. On 10/30/2013 07:16 AM, Russ Allbery wrote: it's not a very useful statement from a practical viewpoint Did you find the part where Lennart tells Canonical is incompetent (or anyone else) more useful? I didn't... And I don't think it's a bad to debunk this. On 10/30/2013 07:16 AM, Russ Allbery wrote: GNOME is not depending on systemd out of some nefarious plot. It's depending on systemd because GNOME wants to use those pieces of functionality systemd provides. Patrick didn't deny that. He claims that Systemd author do not document what the different modules are doing, and do not separate them, because there's an agenda that is followed. Patrick isn't the first person to write this. On 10/30/2013 07:16 AM, Russ Allbery wrote: Therefore, I think it's important for arguments against using systemd to somehow engage directly with the questions about functionality. Either there needs to be an argument that the functionality is not important and can be done without (which raises questions about how one would build GNOME in such an environment), or there needs to be some sort of plan for how equivalent functionality to systemd will be provided. I'm very surprised to read this, when it appears very clear in Patrick's post that he is working on re-implement logind (and the systemd API). So, who exactly is denying the usefulness of the functionality of Systemd/Logind exactly? Russ, I would advise you to read a 2nd time this post from Patrick. 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/5270a87b.7060...@debian.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 29/10/13 23:51, Svante Signell wrote: On Tue, 2013-10-29 at 00:51 -0700, Steve Langasek wrote: (Also, do remember that any decisive outcome other than “support multiple ones including systemd” and “systemd-only” will need to lead to the removal of GNOME from Debian. Absolutely not true. As Tollef mentions in his follow-up, one of the options is to fork logind and maintain it. This is not an improbable outcome. Logind is a good interface, and there's a lot of value in continuing to use it, regardless of what init system we choose. If Debian chooses to ship upstart as the default, I will almost certainly be inteested in making sure that logind continues to be well-supported on top of upstart, in both Debian and Ubuntu. The work to do this on Ubuntu has so far been straightforward; while there are some technical hurdles in the future for making logind continue to work on non-systemd systems, these are known issues and not at all insurmountable. Some more systemd-login0 dependencies: apt-cache rdepends libsystemd-login0 weston gnome-disk-utility build-rdeps libsystemd-login-dev (not only [linux-any]) gnome-disk-utility gnome-disk-utility also depends on libudisks2-dev which depends on udev, which is linux-any/built from systemd?, so this one might be impossible outside linux anyway. weston is Architecture: linux-any but isn't it supposed to run on other architectures in the future? That should probably be any and not linux-any, but it makes no difference at the moment as wayland only builds on linux. When wayland is ported (there were patches upstream to port it to *BSD but they needed some more work) then I see no reason for weston not to work on BSD or Hurd. The systemd integration in weston is optional and could be disabled on !linux when the time comes, but until wayland is ported there's no point in further discussing this. Same for gnome-disk-utility. The systemd bits are optional and could be disabled on !linux, but there are other bigger issues here. Looks like systemd is creping in everywhere. Because it's useful and easy to integrate with, so people take advantage of that. I'm not sure what your point is. See also the problems with gdm3 not starting #724731, systemd-login0 and libpam-systemd. That bug hit me too, on a brand new box as reported earlier. That is a bug, and a grave bug, that I hope to have time to look at soon. I don't see how that is relevant at all. Emilio -- 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/5270db84.6080...@debian.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Op 29-10-13 09:26, Steve Langasek schreef: I see no reason that, if upstart were chosen as the default, porters could not use it for our non-Linux ports as well. With some work, sure. This is a much better outcome across our distribution as a whole than to require developers to continue maintaining init scripts just for our non-Linux ports. I did not say require, I said encourage. I agree that it's unreasonable to expect developers to maintain init scripts that they themselves do not use in addition to init configuration for whatever init system we end up with; and I do agree that it should be fair game for people to drop the init script from their package. However, there are some advantages to be had in continue to ship init scripts (while I can see no downsides, apart from the fact that they need to be written), and in that light it can make sense for us to encourage people to continue shipping init scripts. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: OpenPGP digital signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi, Le mardi, 29 octobre 2013 15.08:01 Russ Allbery a écrit : However, making all package maintainers continue to go through the pain of maintaining SysV init scripts to support Hurd and kFreeBSD doesn't strike me as a good outcome. It does for me. First we're not talking about _all_ package maintainers but only those maintaining init scripts; we should refrain from inflating this problem as affecting _all_ of Debian. Second, if we were to have different init systems [0] for different kernels, I think it would be reasonable to put the burden of maintaining the init systems on the shoulders of those using (and maintaining) these ports; that wouldn't be asking too much. (Booting a machine requires what? 5-20 scripts? Add 3-5 for launching a webserver and friends?) [0] Pid1 is only part of the problem, the bigger picture is pid1 + services machinery, IMHO. I, for one, would happily accept patches for the sysvinit scripts in my packages it that helps different-kernel ports (as I've tried to accomodate other ports from debian-ports when possible), but as I'm not currently running any non-Linux Debian host, I can't reasonably test these; they would then need to come from the people using (and maintaining) these different-kernel ports. I expect that pattern to continue: we will try our best to port Debian as broadly as possible, and we will occasionally give up on a porting target (at least outside of the secondary debian-ports infrastructure) because there's too much work to do and insufficient resources. Sure. That said, I do think that requiring package maintainers to accept patches for non-Linux ports init systems would be a reasonable compromise. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
on Tue, 29 Oct 2013 15:08:01 -0700 Russ Allbery wrote: However, I, as a packager, want to stop writing and maintaining SysV init scripts because they're awful. I didn't really expect this. I'd assumed until now that most maintainers would be concerned that existing init scripts don't work properly on the new system, and having to fix them. But you actually want to do that, and get rid of SysV init scripts too. We now have at least one new option available to the ports which is OpenRC[0]. If for example it was supported alongside systemd (or substitute Upstart here if you prefer), each package's maintainer could: * keep their SysV init scripts and let both init systems use them * write a new systemd unit but keeping the init scripts for OpenRC * write a new OpenRC configuration (I don't even know what that looks like yet), keeping the SysV init scripts for systemd * write a new systemd unit and an OpenRC configuration, can then drop the SysV init scripts * write a new systemd unit and specifically depend on systemd, perhaps leaving the package unavailable to ports But I don't suggest this is only for the benefit of ports. Even Linux users have spoken concerns about systemd specifically. If it were introduced, I'd like to have a lightweight and less controversial alternative, and it's really convenient if it is portable. [0]: https://lists.debian.org/5270b735.8010...@debian.org 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/5270fce2.3030...@pyro.eu.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Hi Steve, On Tue, Oct 29, 2013 at 09:31:37AM -0700, Steve Langasek wrote: On Tue, Oct 29, 2013 at 10:22:54AM +0100, Helmut Grohne wrote: Having read the parts of the ctte bug, it feels odd to preclude the option of supporting multiple init systems from discussion or consideration. If Debian is to support only one init system and that one init system is systemd, then given my above analysis it will be very hard for non-Linux ports to catch up. I argue that in this case we should consider dropping support for non-Linux ports. So if we really are considering such an outcome, why not consider the outcome of supporting multiple init systems (but maybe only one per architecture)? While other members of the TC may wish to consider this option, I've ruled it out myself because we would lose most of the benefits of switching away from sysvinit and instead accrue significant maintenance costs to individual developers who would then have to support both init systems in their packages. What makes switching init systems worth doing is being able to *simplify* the interfaces between the init system and the services. Continuing to support different init systems across different architectures would add complexity instead. That's a pretty bleak outcome. I fully agree with your reasoning. Yet, I see that the options * drop support for non-Linux ports and * maintain some support for an alternate init system are similarly painful. I see neither of them a desirable, but if we really consider one of them, I'd ask for the other one to be considered and evaluated as well. Most participants in this thread appear to agree that the sysvinit *interface* for services (shell scripts) is suboptimal. We are currently mostly arguing about implementations, because each proposed interface has only one implementation. It might make sense to consider a subset of the interface that one implementation provides as our standard and provide a degraded experience to that interface on non-Linux ports. For example, if systemd were to be the init system of choice, it could be required to provide an init script for services with Type=notify. The interfaces of all init systems (except sysvinit, but are we really considering that one?) still are somewhat in flux, so this is the point where we can still influence and shape them. dream Imagine a world where upstart and systemd would use the same syntax (structure) but implement different and somewhat overlapping aspects. Maybe 50% of the daemons would work with either of them without needing changes. wakeup/ But now we call it exec here and ExecStart there, export here and Environment there, and chdir here and WorkingDirectory there. Bummer. /dream Oh wait, I am talking to one of the guys who can actually fix this. :) This would become radically easier if gnome were to become Architecture: linux-any. GNOME may be the trigger for this being raised to the TC, but it's not the core question that we need to address. Even though I did mention gnome over there, the argument is not restricted to gnome in any way. It can be applied to any other package not deemed worthy to support on non-Linux ports (and I should have made this explicit). Furthering this thought leads to turning non-Linux ports into derivatives as presented by others in this thread. I argue that a resolution of this bug needs to answer: What is going to happen with non-Linux ports? Helmut -- 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/20131030141015.ga15...@alf.mars
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Oct 30, 2013 at 03:10:16PM +0100, Helmut Grohne wrote: The interfaces of all init systems (except sysvinit, but are we really considering that one?) still are somewhat in flux, so this is the point where we can still influence and shape them. dream Imagine a world where upstart and systemd would use the same syntax (structure) but implement different and somewhat overlapping aspects. Maybe 50% of the daemons would work with either of them without needing changes. wakeup/ But now we call it exec here and ExecStart there, export here and Environment there, and chdir here and WorkingDirectory there. Bummer. /dream Hi Helmut, exec vs. ExecStart= and export vs. Environment= is easy. Anyone can whip up a sed script to convert between those. The question is how to deal with more advanced options. Let's say that I have a systemd unit with CapabilityBoundingSet=CAP_SYS_TIME# limit the capability bounding set to CAP_SYS_TIME PrivateTmp=yes# run with unshared /tmp InaccessibleDirectories=/home # run without access to /home WatchdogSec=60# consider the service dead if it hasn't pinged the # manager for in the last minute Restart=on-failure# restart service on watchdog failure or unclean exit This isn't a question of syntax, it's a question of significant functionality in the manager. I think that sharing service descriptions between disparate init managers is infeasible, unless we forbid the use of anything but the basic features. Another thing that is turning into a significant gap is socket activation. In systemd, socket activation allows the service to receive multiple open sockets (e.g. ports 80 and 443 for an httpd server). Socket activation of daemons is cool: - it is very easy to write such a daemon, it must just do accept(), read() and write() - resource efficent because of activation on demand - great for running unpriviledged, since the daemon only does accept(), read() and write() - we get rid of a lot of inter-daemon ordering dependencies. With the recent addition of (experimental) systemd-socket-proxyd[1], even daemons like apache which do not support socket activation internally can be launched on demand by wrapping them with a helper. Socket activation is a great technique, bound to be used more. Achieving the same functionality with init scripts is very hard, and AFAIK, upstart doesn't support socket activation with more than one socket. [1] http://www.freedesktop.org/software/systemd/man/systemd-socket-proxyd.html Oh wait, I am talking to one of the guys who can actually fix this. :) Zbyszek -- 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/20131030145246.gq28...@in.waw.pl
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Op 30-10-13 00:16, Russ Allbery schreef: Carlos Alberto Lopez Perez clo...@igalia.com writes: On 28/10/13 20:14, Christoph Anton Mitterer wrote: For those who haven't seen it, Lennart has posted some of his comments about all this on G+: https://plus.google.com/u/0/115547683951727699051/posts/8RmiAQsW9qf And here is the reply from Gentoo developer Patrick Lauer: http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt This, sadly, was not particularly useful or interesting. I disagree. His point isn't argued very well (seems more like a rant than a discussion), but it's there. As near as I can tell, the core content was that he doesn't think cgroup management is particularly difficult (fine, but I don't think that was the point; the point, instead, was that it's important to have a single arbitrator, which if true poses specific technical challenges) and he believes that the components to systemd would be easy to implement as separate daemons if they were properly documented. I'm one of those people who thinks that nearly everything in Linux is horribly underdocumented, so I'm not going to argue with that point, but it's not a very useful statement from a practical viewpoint. systemd offers specific pieces of integrated functionality. By and large, no one seems to question that the operations enabled by that functionality are useful (although there is some debate over how useful). GNOME is not depending on systemd out of some nefarious plot. It's depending on systemd because GNOME wants to use those pieces of functionality systemd provides. Therefore, I think it's important for arguments against using systemd to somehow engage directly with the questions about functionality. Either there needs to be an argument that the functionality is not important and can be done without (which raises questions about how one would build GNOME in such an environment), or there needs to be some sort of plan for how equivalent functionality to systemd will be provided. From the above link: The only thing stopping me from reimplementing that functionality is that I have no idea what it's supposed to *do* ... and I don't enjoy reading through all of systemd to find out. (about logind) While I agree with your point, it's pretty difficult to reimplement the interesting parts of systemd in other implementations of pid1 if whoever wrote the interesting parts does not document it, does not say what it's supposed to do, does not want to accept patches for things they're not interested in, and is by and large uninterested in anyone who prefers to use something else than whatever their kool-aid is. I'll grant that maybe logind provides interesting functionality which other projects might want to depend on, and that there's nothing wrong with that. The problem, however, is that the functionality is not defined: if I want to provide an alternative pid1 implementation, then the specifications are clear, and I should Just Do It (not that I'm going to muddle the waters even more by doing so, but you understand the point). If I want to provide an alternative implementation of logind, however, then the only spec out there is the logind code, which might change one day to the next just because the logind developer feels like it. This wouldn't be much of a problem if I could just take logind (and udev, and dbus, and more things) out of the systemd source tree and use it without systemd, should I want to. But you can't; the problem is that the upstream of all these projects is by and large uninterested in doing so, and also does not seem to support other people who are, and at least the Debian maintainers of systemd have gone on record as saying that they won't guarantee this would remain possible (if the systemd developers would be willing to do so, then I suppose that could ameliorate some concerns). The obvious solution would be that the world changes to systemd because what, essentially, amounts to a level of sabotage by the systemd developers of things that aren't systemd. If systemd is in fact the best choice out there, of which I'm not convinced at this point in time, then I wouldn't mind that (much). But I'd like us to do so for the right technical reasons, not just because it means we make our lives easier in not having to fight with a stubborn upstream all the time. We could, after all, fork, like we have done on other occasions of stubborn upstreams. Given all of the above, I would even argue that perhaps Debian should *not* adopt systemd as init system, out of principle; if we were to do so, then almost all the major distributions would be using systemd (with the sole exception of Ubuntu; I expect redhat to switch to systemd for their next EL version), which could go a long way to making it part of what it means to be running Linux. At that point, any competing innovative implementations would simply face an almost insurmountable heap of
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, 30 Oct 2013 15:10:16 +0100 Helmut Grohne wrote: Furthering this thought leads to turning non-Linux ports into derivatives as presented by others in this thread. If packages are no longer required to provide SysV init scripts, producing a non-Linux Debian derivative would at least entail bringing back SysV init scripts in those packages, or perhaps adding new OpenRC runscripts. If that were to happen though, that same work could enable the use of OpenRC as an alternative init system, even on Linux. 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/527127dc.6020...@pyro.eu.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
]] Wouter Verhelst Yes, absense of documentation is common on Unix and Linux systems; but no, I do not think that this is okay, or that we should in any way encourage that sort of thing. By absense of documentation, are you referring to the almost 10% of the source base that are comments or the 15% that is DocBook XML based documentation? (Almost 14kLOC and almost 36kLOX, respectively.) -- 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/m21u32g383@rahvafeir.err.no
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Steven Chamberlain dixit: […] substitute Upstart here if you prefer), each package's maintainer could: […] * Write scripts for one system and generate the other from it or even * Write “Debian init declaration” and let something take care of generating an initscript and whatever the other systems use out of it bye, //mirabilos -- hecker cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten die nicht noch 3 Jahre warten können? mirabilos bis dahin gibts google nicht mehr hecker ja, könnte man meinen. wahrscheinlich ist der angekündigte welt- untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum müssen die die doodles vorher noch raushauen -- 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/pine.bsm.4.64l.1310301604350.14...@herc.mirbsd.org
Re: Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, 30 Oct 2013 16:05:48 +, Thorsten Glaser wrote: * Write scripts for one system and generate the other from it or even * Write “Debian init declaration” and let something take care of generating an initscript and whatever the other systems use out of it Perhaps an existing definition like Upstart's could become that? We'd want proper documentation and some reassurance it won't change drastically. Upstream might be open to suggestions for improvement. Any thoughts? Then try to add support for it wherever it is easiest to do so, like OpenRC (seems to be rather simply designed, ought to work on all ports, and is under a free license without CLA). It just depends how much functionality Upstart has, that most packages really need, which OpenRC doesn't already have. (The GNOME logind issue would have to be handled anyway for Upstart to be considered.) 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/52713661.2090...@pyro.eu.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
2013/10/30 Helmut Grohne hel...@subdivi.de: What is going to happen with non-Linux ports? Debian is not Debian without non-Linux ports. As for me, I think it is not very hard to maintain diffrent init systems for different kernels. Especially if Debian GNU/Linux get rid of sysvinit: writing systemd or upstrart services is simple (as well as SMF). Just one example from OSDyson (lighttpd): 1. dh-smf: http://cgit.osdyson.org/dh-smf.git 2. lighttpd depends on dh-smf for illumos kernel: http://cgit.osdyson.org/lighttpd.git/tree/debian/control#n10 3. No changes in d/rules (!): http://cgit.osdyson.org/lighttpd.git/tree/debian/rules 4. DH automatically peeks up dh_smf: http://cgit.osdyson.org/debhelper.git/tree/dh?id=3769023faf4758f944e710480c43cda220821690#n524 5. dh_smf looks into this directory: http://cgit.osdyson.org/lighttpd.git/tree/debian/lighttpd.smf 6. dh_installinit is no-op on Dyson -- 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/call-q8zvzx9lr74v6erazu6dgj8ez6kvyigzswq+v77fbwr...@mail.gmail.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Oct 30, 2013 at 04:29:24PM +0100, Wouter Verhelst wrote: While I agree with your point, it's pretty difficult to reimplement the interesting parts of systemd in other implementations of pid1 if whoever wrote the interesting parts does not document it, does not say what it's supposed to do, does not want to accept patches for things they're not interested in, and is by and large uninterested in anyone who prefers to use something else than whatever their kool-aid is. I'll grant that maybe logind provides interesting functionality which other projects might want to depend on, and that there's nothing wrong with that. The problem, however, is that the functionality is not defined: if I want to provide an alternative pid1 implementation, then the specifications are clear, and I should Just Do It (not that I'm going to muddle the waters even more by doing so, but you understand the point). If I want to provide an alternative implementation of logind, however, then the only spec out there is the logind code, which might change one day to the next just because the logind developer feels like it. Are there things missing from http://www.freedesktop.org/wiki/Software/systemd/logind/ from an implementor's perspective? For my part I regard this as a tempest in a teapot. Lennart has been effective at making people worry that not using systemd is too dangerous to consider. But Ubuntu has done just fine with splitting the dbus services off of init up through systemd 204, and while we know there are some big issues on the horizon with the cgroup manager and kdbus questions, these are not settled matters across the Free Software ecosystem. There are lots of other people besides the upstart and Debian non-Linux-port community who have reservations about the systemd gravity well, including anyone using cgroups today on top of lxc or using the Google tools. So I'm not going to give anyone a roadmap today for how these capabilities will be made available in a non-systemd environment, because a lot of this has to do with decisions that need to be made in the relevant wider technical communities and have nothing to do with the init system per se. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
previously on this list Zbigniew Jędrzejewski-Szmek contributed: Hi Helmut, exec vs. ExecStart= and export vs. Environment= is easy. Anyone can whip up a sed script to convert between those. The question is how to deal with more advanced options. Let's say that I have a systemd unit with CapabilityBoundingSet=CAP_SYS_TIME# limit the capability bounding set to CAP_SYS_TIME PrivateTmp=yes# run with unshared /tmp InaccessibleDirectories=/home # run without access to /home WatchdogSec=60 # consider the service dead if it hasn't pinged the # manager for in the last minute Restart=on-failure# restart service on watchdog failure or unclean exit This isn't a question of syntax, it's a question of significant functionality in the manager. I think that sharing service descriptions between disparate init managers is infeasible, unless we forbid the use of anything but the basic features. Couldn't they just be ignored not to mention already having existing or far more functional and robust *options* that work with any init system. Even SElinux has people wanting to use RSBAC or grsecurities RBAC because they have a better security record due to more secure architectures and rules. and on another matter I personally much prefer a setcap (again or other options like RBAC) shell line to CapabilityBoundingSet=CAP_SYS_TIME Another thing that is turning into a significant gap is socket activation. In systemd, socket activation allows the service to receive multiple open sockets (e.g. ports 80 and 443 for an httpd server). Socket activation of daemons is cool: No it isn't and has been argued over not long ago, so as I have been requested to and am now trying (even harder) it would be good if we could keep the S/N ratio down. -- ___ '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/527896.83523...@smtp118.mail.ir2.yahoo.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
previously on this list Helmut Grohne contributed: Most participants in this thread appear to agree that the sysvinit *interface* for services (shell scripts) is suboptimal. Not so sure, I have various thoughts on this and even the reasons that it is considered sub optimal but think some like me have chosen not to bring this up out of fear of opening another can of worms which has already been discussed many times. I have always found OpenRC quite nice in being intuitive, quick and flexible to administer though compared to debian's sysv implementation, upstart and systemd. The freedom arguments can be combatted somewhat with the 'modern' init having options to use shell scripts but then the question becomes whether services start needing hacking and recompiling for things like embedded usage or any other unexpected scenario or desire and I guess Gentoo is heavily into embedded and unexpected scenarios like debian. On the other hand if those disrespectful services choose to ignore unix philosophy then it may simply be an extension of dependency hell in any case and so is of little matter except discouragement. -- ___ '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/922863.83523...@smtp118.mail.ir2.yahoo.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Oct 30, 2013 at 08:59:00PM +0400, Игорь Пашев wrote: Debian is not Debian without non-Linux ports. You are entitled to your opinion, which is what this is. Debian certainly was Debian without non-Linux ports prior to February 2011, and some are of the opinion that it should be again in future. Let's wait and see what the tech committee come out with. Merely pronouncing our opinions does nothing to further the debate. -- 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/20131030203932.gd12...@bryant.redmars.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Oct 30, 2013 at 07:25:55PM +, Kevin Chadwick wrote: Couldn't they just be ignored not to mention already having existing or far more functional and robust *options* that work with any init system. A cursory glance at the example above… PrivateTmp=yes InaccessibleDirectories=/home …would suggest that simply ignoring such things could be a major security concern. So, no. and on another matter I personally much prefer a setcap (again or other options like RBAC) shell line to CapabilityBoundingSet=CAP_SYS_TIME Presumably your preference is not purely down to syntax. What is it down to? No it isn't and has been argued over not long ago, so as I have been requested to and am now trying (even harder) it would be good if we could keep the S/N ratio down. I'm afraid you're failing with sentences such as the above. -- 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/20131030204323.ge12...@bryant.redmars.org
Re: Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, 30 Oct 2013 20:39:32 + Jonathan Dowland wrote: [...] Debian without non-Linux ports prior to February 2011, [...] That's only when a non-Linux Debian port (GNU/kFreeBSD) first became a _release architecture_; it existed as a port since May 2003. Hurd has been an official unstable port since before that I think. Debian is also upstream to more unofficial ports such as Dyson that many of us don't ever hear about. So clearly, Debian has always been a very portable OS; taking a very Linux-specific direction such as systemd would be significant. Merely pronouncing our opinions does nothing to further the debate. It wouldn't be much of a debate if people didn't speak their opinions. Others had already done so in the tech-ctte bug so I think he was justified in challenging this. And... if everyone was of the same opinion, there probably wouldn't have been a debate in the first place. 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/527177cd.50...@pyro.eu.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
previously on this list Jonathan Dowland contributed: Couldn't they just be ignored not to mention already having existing or far more functional and robust *options* that work with any init system. A cursory glance at the example above… PrivateTmp=yes InaccessibleDirectories=/home …would suggest that simply ignoring such things could be a major security concern. So, no. Well I meant that they would be used by systemd and ignored likely noisily by default by others. However this really should be the job of the service in any case as depending on a third party service for security that isn't extra such as potentially PrivateTmp that apache/php may need (likely in a /var chroot in this case though) is asking for trouble. and on another matter I personally much prefer a setcap (again or other options like RBAC) shell line to CapabilityBoundingSet=CAP_SYS_TIME Presumably your preference is not purely down to syntax. What is it down to? For something that is as long and no more descriptive than the shell it replaces it is simply adding obfuscation that fails to teach anything useful to users for use in other contexts and doesn't have a man page which like so often on Linux needs improving for setcap but that is of no importance to the better practice of empowering users who may become the next generation of devs. No it isn't and has been argued over not long ago, so as I have been requested to and am now trying (even harder) it would be good if we could keep the S/N ratio down. I'm afraid you're failing with sentences such as the above. True and certainly could have been worded more tactfully. I was referring to the thread from the 27th Aug entitled Custom Reload command/signal in upstart -- ___ '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/818151.66282...@smtp124.mail.ir2.yahoo.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Kevin Chadwick ma1l1i...@yahoo.co.uk writes: Well I meant that they would be used by systemd and ignored likely noisily by default by others. However this really should be the job of the service in any case as depending on a third party service for security that isn't extra such as potentially PrivateTmp that apache/php may need (likely in a /var chroot in this case though) is asking for trouble. No, it should *not* be the job of each service to reimplement tricky security measures. They should be implemented in one place or a small number of competing places that are thoroughly tested and that have been examined with lots of eyeballs, and then reused by everyone else rather than having them attempt to roll their own strategies. This applies to several features in upstart and systemd. Socket activation is another excellent example. Anyone care to guess how much badly-written code to handle listening to a network socket currently exists in the archive? How much of it causes the daemon to fork and exit in the parent before it's actually listening to the network, thus breaking boot ordering? And that's despite the existence of the inet superserver, which hopefully a lot of packages are using rather than rolling their own. It's one thing to avoid a monoculture. It's quite another to chase avoidance of a monoculture into a nasty case of Not Invented Here. Services should not be responsible for doing things that can be done properly by well-tested and robust system services for exactly the same reason that services should not use their own implementation of AES and should instead rely on one of the several robust and well-tested crypto libraries. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87vc0eqo23@windlord.stanford.edu
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
previously on this list Russ Allbery contributed: Well I meant that they would be used by systemd and ignored likely noisily by default by others. However this really should be the job of the service in any case as depending on a third party service for security that isn't extra such as potentially PrivateTmp that apache/php may need (likely in a /var chroot in this case though) is asking for trouble. No, it should *not* be the job of each service to reimplement tricky security measures. They should be implemented in one place or a small number of competing places that are thoroughly tested and that have been examined with lots of eyeballs, and then reused by everyone else rather than having them attempt to roll their own strategies. This applies to several features in upstart and systemd. Socket activation is another excellent example. Anyone care to guess how much badly-written code to handle listening to a network socket currently exists in the archive? How much of it causes the daemon to fork and exit in the parent before it's actually listening to the network, thus breaking boot ordering? And that's despite the existence of the inet superserver, which hopefully a lot of packages are using rather than rolling their own. It's one thing to avoid a monoculture. It's quite another to chase avoidance of a monoculture into a nasty case of Not Invented Here. Services should not be responsible for doing things that can be done properly by well-tested and robust system services for exactly the same reason that services should not use their own implementation of AES and should instead rely on one of the several robust and well-tested crypto libraries. Well I completely disagree, yes they should use or atleast reference good well audited shared references but code for security should be tailored to the almost always simpler job at hand otherwise you will always be less secure and doing so actually increases eyeballs on the code. Bringing it back to PrivateTmp what you are certainly doing is adding complexity about whether systemd is running and has done this or not and for what good reason, which then raises questions and less audited code for all the other use cases. If you analyse the really secure packages on the two sides guess which has the extremely low vulnerability track record. You may also stop the dev from providing extra layers of security because the generalised behaviour is out of their domain and they don't need to think about it. If on the other hand you are talking about making it easier for some programmers who are not willing to take the time to be careful then you may have a point for backing things like polkit but I would say they should stick to unpriviledged user operations then as this generalisation and misunderstanding/unfamiliarity does and will lead to more exploits and they shouldn't be doing anything risky as root if they are not willing to be careful anyway. And no it isn't exactly the same reason as well defined libraries with very specific low level jobs at all, often even standard c libraries functions are the right tool but sometimes you take part of it and make something more correct. -- ___ '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/68396.31640...@smtp104.mail.ir2.yahoo.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Theodore Ts'o ty...@mit.edu writes: On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote: Well, I've said this before, but I think it's worth reiterating. Either upstart or systemd configurations are *radically better* than init scripts on basically every axis. They're more robust, more maintainable, easier for the local administrator to fix and revise, better on package upgrades, support new capabilities, etc. Can you please go in to more detail why you believe this was true? I think it's painfully obvious if you compare an init script to an upstart or systemd configuration file for a simple daemon like, say, my lbcd package. For those who don't agree, please try the exercise of writing systemd and upstart configuration files for some typical daemon package and look at the number of lines of code in both and the behavior in edge cases (daemon already running, daemon running but with no PID file because something else deleted it, daemon part of a dependency chain that shouldn't fire until the daemon is actually listening to the network, correct exit status for various failure conditions, stopping the daemon when there is a user process with the same name as the daemon also running, and the other cases Policy says one must handle). Now compare the length of time it took you to make an init script correctly handle all those cases versus how long it took to write the upstart or systemd configuration. (Note that I have found, IIRC, two different edge-case bugs in /etc/init.d/skeleton while working on Debian, so even if you start from that file, which is only applicable to a relatively narrow range of circumstances, you can still fail edge cases.) I have prior experience here both as Policy editor dealing with the Policy sections related to init scripts and as a Lintian maintainer dealing with Lintian checks for init scripts. Both of those experiences were, shall we say, convincing. Another way to look at this is that both upstart and systemd provide a high-level programming language for writing init scripts. Not only does it implement a higher level of abstraction, it's also better-suited to the problem space because it's declarative rather than imperative. (systemd somewhat more so than upstart, although that makes it somewhat more awkward to use in cases where you really need to run some shell script on various actions.) As with any move to a higher-level programming interface, there are drawbacks; if you really want to do your own memory management, you don't get to any more. And as with most moves to a higher-level programming interface well-suited to the task at hand, the advantages outweigh the drawbacks. (And in this case, I'd go a step farther and say that I think most of the drawbacks people cite around loss of flexibility are at least arguably benefits. The world would be a better place with fewer init scripts doing weird and unexpected things to paper over bugs better fixed somewhere else.) This really shouldn't be a particularly controversial stance. Ever since Solaris SMF, various UNIX implementations have been abandoning traditional init scripts for exactly these reasons. I really don't think that all those completely independent technical teams, which at this point include most major Linux distributions (counting OpenRC as another higher-level implementation), are all wrong. This is an area of personal interest of mine. I followed daemontools development back when Dan Bernstein was tackling this same basic problem in his distinctively radical way, and have subsequently been paying at least casual attention to various different daemon management facilities ever since. A lot of people have tried to solve various aspects of the problem that init scripts are actually horrible at what they do, and the solutions have been slowly improving and becoming more and more robust. AFS attempted to solve this problem all the way back in the 1980s. Even back then, it was obvious that init scripts were insufficiently powerful to manage production services properly, hence the whole bosserver system that persists in OpenAFS to this day and which, coming from MIT, you may be familiar with. Not that I would advocate use of bosserver for anything other than AFS these days, as there are now lots of newer technologies that have surpassed it, although (relatively) secure network management of services is still an interesting feature. The lsat time I played with Upstart, I saw a lot of policy moved from shell scripts into C code (which I would have to edit and recompile) if I wanted to change things. I also was extremely frustrated with a massive lack of documentation, where at least with shell scripts I could read the scripts to understand what was going on. I suspect you and I have a root disagreement over the utility of exposing some of those degrees of freedom to every init script author, but if you have some more specific examples of policy that you wanted to change
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Mon, Oct 28, 2013 at 06:21:27PM -0700, Russ Allbery wrote: Well, I've said this before, but I think it's worth reiterating. Either upstart or systemd configurations are *radically better* than init scripts on basically every axis. They're more robust, more maintainable, easier for the local administrator to fix and revise, better on package upgrades, support new capabilities, etc. Can you please go in to more detail why you believe this was true? The lsat time I played with Upstart, I saw a lot of policy moved from shell scripts into C code (which I would have to edit and recompile) if I wanted to change things. I also was extremely frustrated with a massive lack of documentation, where at least with shell scripts I could read the scripts to understand what was going on. Maybe things have changed, but that was my impression with both Systemd and Upstart (and policykit, and consolekit, etc. all of which has caused me no end of frustration). - Ted -- 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/20131031004110.ga9...@thunk.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote: I suspect you and I have a root disagreement over the utility of exposing some of those degrees of freedom to every init script author, but if you have some more specific examples of policy that you wanted to change but couldn't, I'd be interested in examples. It's not necessarily the init script author who might want the degrees of freedom, but the local system administrator. The most basic is the idea that whether you can control (via shell scrpit fragments) whether or not a service should start at all, and what options or environments should be enabled by pasing some file. The fact that we can put that sort of thing in configuration files such as /etc/default/*, for example. Yes, yes, you can do this via if you use system V init scripts scripts in backwards compatibility mode, but you've argued that we should be moving briskly away from that. In which case system administrators will need to hand-edit the services files by hand, which will no doubt increase the chances of conflicts at package upgrade time, compared to if the configuration options were isolated away in files such as /etc/default/rsync (for example). I realize that the local administrator may have other goals, and they should have ways of achieving them, but both systemd and upstart support running SysV init scripts for those cases. If the package does not ship a SysV init script (which is your ideal long-term outcome), that may not be very practical option for a system adminsitrator who may need to recreate a SysV init script, especially if the service file is rather complicated, or is using some of the more advanced feature of systemd/upstart. - Ted -- 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/20131031015053.gb9...@thunk.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Theodore Ts'o ty...@mit.edu writes: On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote: I suspect you and I have a root disagreement over the utility of exposing some of those degrees of freedom to every init script author, but if you have some more specific examples of policy that you wanted to change but couldn't, I'd be interested in examples. It's not necessarily the init script author who might want the degrees of freedom, but the local system administrator. The most basic is the idea that whether you can control (via shell scrpit fragments) whether or not a service should start at all, and what options or environments should be enabled by pasing some file. The fact that we can put that sort of thing in configuration files such as /etc/default/*, for example. Yes, yes, you can do this via if you use system V init scripts scripts in backwards compatibility mode, but you've argued that we should be moving briskly away from that. In which case system administrators will need to hand-edit the services files by hand, which will no doubt increase the chances of conflicts at package upgrade time, compared to if the configuration options were isolated away in files such as /etc/default/rsync (for example). Ah, I see. However, I do think this is mostly a solvable problem. We should provide meaningful flexibility in our init script configuration, which may include providing hooks so that local administrators have a place to put that local policy. You're right that some of this functionality will probably be lost in the initial conversion to something other than init scripts, but I would consider that to (usually) be a bug, and as people report problems, we can be sure it's added back in after understanding the issues involved. Yes, this may be a bit annoying for people in the short term, but I do think it gets us to a better place in the long run by way of supporting clean and documented interfaces for those policy settings. It is true that currently init scripts are full-blown programs, allowing anyone who is capable of programming in that language to make arbitrary policy modifications. We lose that by switching to a higher-level language, and only policy decisions anticipated by that language will be easily implemented. More complex policy decisions would have to be handled at a higher level, via selectively creating or removing the configuration files. It's certainly a disruptive change. I'm not convinced it's a net negative, but it will depend on how strong the available hooks are and what types of policy the local administrator wants to easily change. I do think that being able to treat the init scripts as real configuration files will make maintaining such local policy easier than it is currently. The prospect of modifying init scripts was already dire enough that we pushed most meaningful configuration into /etc/default instead of asking that people change the complicated init scripts and then handle merges on package upgrades. *Most* local changes are fairly simple, and would only require small and mergable changes to upstart configuration files, and small overrides to systemd files. I personally like upstart's model a little better, but systemd's model of /etc overrides /lib is, I think, workable as long as people remember to change only the setting they want and then include the original instead of making copies of the whole configuration. (That being said, I'm worried about how the systemd model handles the common case of wanting to change the command-line arguments to a daemon, and then having the package also change the command-line arguments in some orthogonal way.) If the package does not ship a SysV init script (which is your ideal long-term outcome), that may not be very practical option for a system adminsitrator who may need to recreate a SysV init script, especially if the service file is rather complicated, or is using some of the more advanced feature of systemd/upstart. You can do quite a bit with the hooks that are part of the specification of both types of files. For example, logic that you may add to control whether the service should start at all can be implemented by adding a pre-start stanza to the upstart configuration. This particular action appears to be harder to do in systemd, which doesn't, at least from the documentation that I've found, support running arbitrary shell code to determine whether to start a unit, but there are a bunch of other possible built-in checks. I suppose one could also change the command started to wrap it and put the check there, although that feels quite ugly. In general, upstart's integration with arbitrary actions in shell fragments is considerably better than systemd's, at least based on the documentation I've read. upstart feels like it provides more useful flexibility. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Oct 30, 2013 at 09:50:53PM -0400, Theodore Ts'o wrote: On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote: I suspect you and I have a root disagreement over the utility of exposing some of those degrees of freedom to every init script author, but if you have some more specific examples of policy that you wanted to change but couldn't, I'd be interested in examples. It's not necessarily the init script author who might want the degrees of freedom, but the local system administrator. The most basic is the idea that whether you can control (via shell scrpit fragments) whether or not a service should start at all, and what options or environments should be enabled by pasing some file. The fact that we can put that sort of thing in configuration files such as /etc/default/*, for example. Both systemd and upstart support this well enough. With systemd you can say EnvironmentFile=/etc/default/whatever and use the variables in ExecStart=/path/to/prog $VAR1 $VAR2. This is usually discouraged, not because it doesn't work, but because it uses two files to provide very little value. In majority of cases it turns out that the settings in /etc/default either can't be changed in an useful way, or are better read by the daemon itself from a different configuration file. But if you want this, then it's there. If the settings are to complicated for the declarative style, you can always use an helper shell script to launch the daemon. Again, discouraged, but certainly supported. Yes, yes, you can do this via if you use system V init scripts scripts in backwards compatibility mode, but you've argued that we should be moving briskly away from that. In which case system administrators will need to hand-edit the services files by hand, which will no doubt increase the chances of conflicts at package upgrade time, compared to if the configuration options were isolated away in files such as /etc/default/rsync (for example). Actually this doesn't happen that often. Typical systemd service file has 1-3 lines of documentation, 1+ lines of ExecStart stuff, and a few additional settings. They are mostly orthogonal, so you just override the one you need. Probably most common case is to override ExecStart=, done by adding the file like /etc/systemd/system/myservice.d/custom-start.conf which only overrides ExecStart. Nice and simple, no conflicts on upgrade. I realize that the local administrator may have other goals, and they should have ways of achieving them, but both systemd and upstart support running SysV init scripts for those cases. If the package does not ship a SysV init script (which is your ideal long-term outcome), that may not be very practical option for a system adminsitrator who may need to recreate a SysV init script, especially if the service file is rather complicated, or is using some of the more advanced feature of systemd/upstart. Why would you recreate the whole script? Let the init manager take care of starting and stopping and supervising, and only do the custom stuff in the script. Then it should be just a few lines. Zbyszek -- 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/20131031022135.gs28...@in.waw.pl
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 10/31/2013 02:50 AM, Theodore Ts'o wrote: The most basic is the idea that whether you can control (via shell scrpit fragments) whether or not a service should start at all, and what options or environments should be enabled by pasing some file. The fact that we can put that sort of thing in configuration files such as /etc/default/*, for example. Yes, yes, you can do this via if you use system V init scripts scripts in backwards compatibility mode, but you've argued that we should be moving briskly away from that. In which case system administrators will need to hand-edit the services files by hand, which will no doubt increase the chances of conflicts at package upgrade time, compared to if the configuration options were isolated away in files such as /etc/default/rsync (for example). Ted, I'm sorry, but it's very obvious you have no clue how systemd is supposed to be used. First of all, systemd - like udevd - supports two places where to place systemd service files. One is located below /usr/lib/systemd which is the directory where service files provided by the package are placed, and one is /etc/systemd where your own, custom service files are located. If systemd finds an appropriate service file in /etc/systemd it will ignore the appropriate service file in /usr/lib/systemd, always. So there is never a problem with service files being overwritten during an upgrade like you describe. The same holds true, btw, for udevd with it's rules files which are located in /lib/udev/rules.d and /etc/rules.d respectively. And everything that you might want change in the configuration of a service can be done by editing the service file and this in a much easier and consistent way. Editing a file in the .ini file format is a no-brainer which, in the worst mistake case, will probably lead to an error message from the daemon or systemd while messed up custom code may end up rendering your whole system unusable if you are smart enough to mess up an rm command. Just have a look at this wonderful bug in upstart [1]. If the package does not ship a SysV init script (which is your ideal long-term outcome), that may not be very practical option for a system adminsitrator who may need to recreate a SysV init script, especially if the service file is rather complicated, or is using some of the more advanced feature of systemd/upstart. No, System V Init scripts are not ideal on the long-term outcome since they are highly distribution-specific, error-prone and annoying to maintain. We have had tons of bugs in the bug tracker because of broken init scripts, like this one [2]. I don't understand why anyone would think that having to write a small piece of code to start another program is a sensible and good design, especially when this is done for dozens of programs (= daemons) in very much the same way. It absolutely makes sense to encode the logic to start and control a daemon through a single piece of C code rather than writing more-or-less the same bash script for every single daemon on your machine. Adrian [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668890 -- .''`. 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/5271ebb8.8040...@physik.fu-berlin.de
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
]] Russ Allbery (Cleaned up the Cc line somewhat) You can do quite a bit with the hooks that are part of the specification of both types of files. For example, logic that you may add to control whether the service should start at all can be implemented by adding a pre-start stanza to the upstart configuration. ExecStartPre=/bin/false will make the service be considered failed. The ExecStartPre line can of course be an executable that implements more checking or logic. -- 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/m2habydmmu@rahvafeir.err.no
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Tollef Fog Heen tfh...@err.no writes: ]] Russ Allbery (Cleaned up the Cc line somewhat) You can do quite a bit with the hooks that are part of the specification of both types of files. For example, logic that you may add to control whether the service should start at all can be implemented by adding a pre-start stanza to the upstart configuration. ExecStartPre=/bin/false will make the service be considered failed. The ExecStartPre line can of course be an executable that implements more checking or logic. Ah, thank you! I got lost in the systemd.* man pages and didn't find the systemd.service one somehow (even though it's right there listed first; sigh). ExecStartPre and ExecStartPost add most of the functionality that I wasn't seeing in other examples. It's a bit awkward compared to the upstart script directive since you have to externalize the shell script somewhere or write inline shell in a rather irritating format, but that's really a minor complaint. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87siving1c@windlord.stanford.edu
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Thorsten, On Mon, Oct 28, 2013 at 05:23:33PM +, Thorsten Glaser wrote: Lucas Nussbaum leader at debian.org writes: I think that it would be a failure of the Debian project if we had to have a GR about such a technical decision. I think that we need to trust that the Technical Committee will make the right decision. A GR about this will likely result in splitting and hurting the project even more. In my perception, it’s the other way round: a CTTE decision will be seen as dictated from a small group, and the possible conflict of interest has been raised, no matter whether it indeed matters in the CTTE decision or not, people are saying it’s fishy. There is a lot of indirection in your message here: will be seen, some people. You don't say that *you* mistrust the Technical Committee's decision on this issue. If you do, please come out and say so directly. As it stands, I don't find your argument here very compelling at all. Yes, there will be some people who criticize the TC decision as being that of a small cabal; but how many of the people levelling that criticism are actually Debian deveolpers? I don't think you were around in the years immediately after the constitutional bugfixing that enabled Debian to start having GRs again after a long hiatus, but I was. The experience of that time convinced me more than anything else that direct democracy is a very poor system of government for an organization of any size, because it wastes a lot of people's time and causes a lot of anguish over issues that at the end of the day are not very important. GRs on controversial subjects are not healthy for the project, and we should not go out of our way to pull the trigger on GRs if we don't have to. The decisions of the Technical Committee are always subject to review by the developers at large via the GR process. If a sufficient number of developers disagree sufficiently strongly with the decision of the Technical Committee that they wish to raise a GR, it is always their prerogative to do so. But even if this happens, it is a much better process for Debian as a whole to let the TC do its work first, evolve the pro/con arguments in a small group, and then present their conclusion to the project rather than to have all developers immediately pile on and tackle the question directly from scratch. In the common case, everyone is reasonably happy with the TC's conclusion and there's no further need to spend time on a controversial project-wide discussion. In the exceptional case, some group of developers disagree strongly enough with the outcome, and think the majority may support them, that they will submit a GR to overturn the decision - but in that case they have specific technical discussions from the TC that they can refer to instead of having to start the discussion from scratch. Either way, it's much less of a time sink for Debian developers as a whole to let the TC do the hard work first while the rest of the project can continue being productive elsewhere. (Also, do remember that any decisive outcome other than “support multiple ones including systemd” and “systemd-only” will need to lead to the removal of GNOME from Debian. Absolutely not true. As Tollef mentions in his follow-up, one of the options is to fork logind and maintain it. This is not an improbable outcome. Logind is a good interface, and there's a lot of value in continuing to use it, regardless of what init system we choose. If Debian chooses to ship upstart as the default, I will almost certainly be inteested in making sure that logind continues to be well-supported on top of upstart, in both Debian and Ubuntu. The work to do this on Ubuntu has so far been straightforward; while there are some technical hurdles in the future for making logind continue to work on non-systemd systems, these are known issues and not at all insurmountable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 28/10/13 at 18:21 -0700, Russ Allbery wrote: Wouter Verhelst wou...@master.debian.org writes: Also, since all alternative init implementations under consideration do support sysv-style init scripts, I think that whatever init system we (well, you, the TC) end up choosing, the requirement in policy should be that a package should ship either some init configuration for the default init system, or a sysv-style init script. In fact, I think we should continue to encourage the latter, in cases where it does make sense (e.g., when a given daemon doesn't have any init system specific features that could be enabled), since that will help our non-Linux ports without significantly impacting performance of the new init system. Well, I've said this before, but I think it's worth reiterating. Either upstart or systemd configurations are *radically better* than init scripts on basically every axis. They're more robust, more maintainable, easier for the local administrator to fix and revise, better on package upgrades, support new capabilities, etc. I believe that much of the benefit for adopting a new init system is dropping init scripts and using a much better configuration language. If we're not going to take advantage of that benefit, it calls into question whether we should change init systems at all. Note that there are two options that could be explored, to remove the need to maintain init scripts: - generating sysvinit scripts from systemd service files or upstart job files at build time (this was explored, for systemd service files, during a GSoC project in 2012, without much success) - having a .service/job files runtime interpreter (that sounds quite promising) Even if it cannot be used for all services, using such as interpreter could maybe provide an easy support path for sysvinit on non-linux platforms for a large number of simple services. There's a subthread about that starting at https://lists.debian.org/debian-devel/2013/05/msg01309.html Helmut Grohne (Cced) did most of the work on analyzing those possibilities. Lucas -- 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/20131029082010.ga17...@xanadu.blop.info
