Re: overriding udev rules
On 09/10/2013 02:50 AM, Lennart Poettering wrote: On Mon, 26.08.13 01:22, Thomas Goirand (z...@debian.org) wrote: On 08/24/2013 03:53 PM, Ben Hutchings wrote: There is a very clear standard that distinguishes globally and locally administered addresses. While you would possibly to buy your own OUI and make global assignments to your VMs, I seriously doubt you are doing that. Don't steal address space. Ben. By reading the above, I don't think I made myself clear enough. In the case of a bare-metal driver for cloud computing IaaS, you would an have operating system image that could be booted once on one physical machine, then shutdown and later restarted on another hardware. In such use case, physical hardware is used to run the virtual machine images without virtualization. It is *not possible to choose the MAC*, as this is the one that is physically in the hardware, though udev should continue to behave as if it was a virtual machine MAC address. Therefore, I think there should be an easy, documented way, of telling udev to behave one way or another. I'd say /etc/udev/udev.conf could be the correct place to configure this. If we want to keep the current behavior of double-guessing the use case of the network interface (which I recognize is the most useful case), then it could stay as default, as long as there is a reliable way to configure udev. systemd/udev upstream do not assign persistent fixed names anymore to network interfaces, in order not to race against the kernel. Instead we now assign predictable names insteads, which avoids the whole issue. See http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ The resulting names are somtimes a bit ugly, but predictable and stable, and do not change on every VM reboot... They are predictable from within a booted linux install with a new kernel. They are stable as long as the kernel and the hardware do not change too much; e.g. enabling the other graphics card in a hybrid setup sometimes adds a PCIe bus, so all names shift around. There are still race conditions. It's now a Debianism to stick to the persistant names, all support for it has been removed upstream. From upstream we hope DEbian eventually drops support for the old persistant names too. As a side note, also note that the MAC address range definitions are all blurred these days, MAC addresses are reused by manufacturers and most parsable meaning of MAC addresses has been removed (simply because the namespace is mostly depleted these days...) Reusing would be extremely bad - Medion once shipped a few charges of machines with the same MACs on all, so people that bought more than one had fascinating network failures. I hope no vendor is *THAT* insane and still allowed to assign MACs. -- 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/522e6270.1010...@gentoo.org
Re: Gentoo guys starting a fork of udev
On 11/14/12 18:37, martin f krafft wrote: also sprach Thomas Goirand z...@debian.org [2012.11.14.0412 +0100]: As Gentoo guys and some major kernel people are protesting about the insanity Kay and Lennart have done to udev, I cannot help but notice that Kay and Lennart were both Gentoo-freaks when they took on udev You make my head hurt. These guys are throwing mud at Gentoo at any chance they get, how on earth did you get an impression that they'd consider Gentoo to be more than a kinky toy for bored kiddies? and at least I always attributed much of what was wrong with udev from the start (e.g. the configuration file format) to being born in an environment where people still compile from source. ;) And you compile from what? ;) But anyway, we're getting tired of their ADHD-driven changes just to change things - maybe we can build up enough momentum so that things might just be less frustrating for us all. You're all welcome to join, ignore us or do what you want. Have a nice day, Patrick -- 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/50a3a153.2000...@gentoo.org
Re: Gentoo guys starting a fork of udev
On 11/14/12 19:53, Matthias Klumpp wrote: What are the problems they try to address? Removal of features, broken build system, etc. Just the little things that make things exciting (and we prefer things to be boring so we can sleep at night) Plus an unpredictable upstream that can't be trusted anymore. (See recent rants by kernel people about udev breaking firmware loading completely because LOL FASTOR) The strong binding to systemd is good and makes much sense to me, If you wanted to use systemd maybe. But since we don't want it it's a strong negative point and udev is still usable without systemd (and will be in the future). It's slowly losing features or getting broken in funny ways because upstream wants you to migrate into the exciting future. It's becoming more and more troublesome, and we don't know what they'll change next just because they can Also, both systemd and udev are Linux-only, so the situation here at Debian hasn't changed. The problems we had in the past with bad udev+kernel combinations and changing config file format etc. can also be addressed in udev, without the need of forking. Most of the issues we've had since the merge have been declared features by upstream. Discussing with them appears to be futile. In general, I think a fork of udev would do much more harm than trying to solve the problems in udev. Of course, they're free to fork, but the separation will hurt both projects and everything relying on udev/the fork. An API-compatible fork should not cause any problems. Since we cannot cooperate with upstream I don't see any other way forward. I do agree that it's stupid - would be nice if we could work together etc. etc. Regards, Matthias -- 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/50a3a387.4020...@gentoo.org
Re: Gentoo guys starting a fork of udev
On 11/14/12 22:04, John Paul Adrian Glaubitz wrote: On Wed, Nov 14, 2012 at 09:49:07PM +0800, Patrick Lauer wrote: But anyway, we're getting tired of their ADHD-driven changes just to change things TBH, I'm getting tired of people who are constantly shooting against them because these people are unwilling to accept changes. We're not bringing Linux forward if we stick to 30-year-old concepts. Y'know ... I like progress. There's some pretty nice new things that are an actual improvement, like GPT. At last more than 4 partitions (and no longer compatible to MS-DOS 3.3) ... But then there's for example UEFI (which I've never seen working as suggested by documentation), grub2 (should be called blinky cursor app), then the random changes to udev that make it unable to load firmware, moving things around (well, no script hardcodes /sbin/ip, right?) just for fun ... I'm tired of these changes that don't solve any problems. Half-baked stuff that is deployed before it is even feature-complete with the boring old stuff it is supposed to replace. How would you feel about a forced upgrade of apt to yum? After all newer is better ... systemd is a good design and most people actually agree otherwise it wouldn't become standard on so many distributions (except Ubuntu, but that's rather a political decision IMHO). It does have some good ideas, and it is better than the random bits of unmaintained shell it replaces - but it's mediocre at best. No real design, just things nailed together with screws and secured with tape. I'm waiting for the one that comes to replace it :) One of the Arch developers actually made a couple of good points why they switched to systemd as default [1]. Their users really appreciate it, especially those that are now migrating to other distros because they preferred their OS when it was booting as intended. -- 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/50a3aa92.1060...@gentoo.org
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 09/02/12 20:43, Matthias Klumpp wrote: Hi! Just for the record (and I might be wrong with this information, because I don't have it from a official Gentoo source): I heard from a Gentoo dev that they will switch from OpenRC to systemd, No. and find the possibility very funny that Gentoo switches to systemd from OpenRC and Debian switches to OpenRC from init. :-) So, it looks like Gentoo devs see value in systemd so they're consider dropping OpenRC for systemd. There is a non-empty set of people that thinks it's a good idea. They are a small but very annoying minority that makes life hard for everyone else, so they risk getting severely ignored if they continue to cause problems. About the general issue: I think whoever wants to work on stuff should be able to work on it, so having OpenRC packages is not really a bad thing. So, if someone wants to do it, just do it :-) For making OpenRC default I have an other opinion: I consider systemd superior and I think making OpenRC default is just the wrong way. That's where opinions go apart. But right now systemd doesn't have many features (well, things I consider features) over OpenRC. And I really seriously prefer things I can fix, if I wanted magic blackbox stuff I'd be using a Mac. The added complexity of systemd is definitely not a feature at all for me. Oh well. The arguments are basically the same, it depends on your priorities. You can easily argue for or against both sides just by shifting the weight you give to things like ease of use. (Which makes most of these discussions so hilarious because we all violently agree ...) Personally I'm slowly getting tired of the forced vertical integration and change just to change things, so I'll be over there in the corner, working on obsolete technologies ;) (thanks, Lennart, you're such a funny prankster) And if you get tired of chasing a constantly changing target, well, be welcome back :) Have a nice day, Patrick -- 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/50435c94.6030...@gentoo.org
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On 09/01/12 04:06, John Paul Adrian Glaubitz wrote: On Fri, Aug 31, 2012 at 08:28:27PM +0300, Serge wrote: It's often someone says something similar about many ITPs. I believe noone should say things like that, unless he wants to scare everybody away and have Debian forgotten and dead. Saying that you not only reduce the number of bugs in Debian, but you also reduce the number of people working on Debian, because when they hear that they just turn around and go away. I don't see how these people help Debian if they start pushing their own solution instead of helping to improve what is already there. Sometimes those two are the same thing ... -- 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/504198a7.4010...@gentoo.org
Re: RFC: OpenRC as Init System for Debian
On 05/09/12 21:37, Tollef Fog Heen wrote: ]] Philipp Kern You will not, however, get a conffile update prompt when the system file changes (e.g. to update your own local copy to incorporate the fix). This is something I'm pondering if we should handle in either a systemd trigger or a tool that packages shipping systemd files can call to tell the user about any changes. (Basically a wrapper around ucf, probably.) Why this arbitrary limit to only one application? http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3chap=4 Something along those lines makes life a lot easier and avoids these schizophrenic hacks around package managers that don't respect files - but it needs support in the package manager to work reliably. Have a nice day, Patrick -- 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/4faa77e4.2070...@gentoo.org
Re: RFC: OpenRC as Init System for Debian
On 05/09/12 21:58, Fernando Lemos wrote: Hi, On Wed, May 9, 2012 at 10:57 AM, Patrick Lauer patr...@gentoo.org wrote: On 05/09/12 21:37, Tollef Fog Heen wrote: ]] Philipp Kern You will not, however, get a conffile update prompt when the system file changes (e.g. to update your own local copy to incorporate the fix). This is something I'm pondering if we should handle in either a systemd trigger or a tool that packages shipping systemd files can call to tell the user about any changes. (Basically a wrapper around ucf, probably.) Why this arbitrary limit to only one application? http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3chap=4 Something along those lines makes life a lot easier and avoids these schizophrenic hacks around package managers that don't respect files - but it needs support in the package manager to work reliably. Are you aware of how ucf works? Sorry, this discussion got a heavy rpm-slant because of the progeny of systemd, and there these evil hackaround are needed. And the way this was phrased I got side-tracked ... So the proper way for everyone using a package manager would be to put the unit files in the right place in /etc/ and not worry about this confusion :) I understand you love Gentoo, but we do have our own tools (that probably precede Gentoo's, actually). :-) Yeah, just sometimes a bit hard to discover, and here we're mixing apt, rpm and other things ... grmbl :) Regards, -- 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/4faa7ad7.9030...@gentoo.org
Re: RFC: OpenRC as Init System for Debian
On 04/26/12 00:42, Roger Leigh wrote: On Wed, Apr 25, 2012 at 08:52:59PM +0800, Patrick Lauer wrote: I'd like to ask you to evaluate OpenRC as candidate to replace the old have-always-been-there sysvinit/insserv init scripts in Debian. While as others have mentioned that ideally a more dynamic init system such as systemd or upstart is where I think the general consensus is Define dynamic please, and don't use lines of code changed per month as metric ;) As long as we don't even agree what that (and event driven) mean it'll be needlessly confusing for all involved to discuss without a shared vocabulary. Have fun, Patrick -- 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/4fa7ce82.70...@gentoo.org
Re: RFC: OpenRC as Init System for Debian
On 04/26/12 01:49, Marco d'Itri wrote: On Apr 25, Patrick Lauer patr...@gentoo.org wrote: in the last months there have been many discussions about init systems, especially systemd. The current state seems to make no one really happy Not true. systemd and upstart do not make /everybody/ happy, but nothing does. Having read the source of both (and how much I laughed!) ... They do have some mostly good ideas, but ... no thanks. Ideas are cheap, execution matters. I'd like to ask you to evaluate OpenRC as candidate to replace the old have-always-been-there sysvinit/insserv init scripts in Debian. What we need is an event-driven init system, anything else will just make us waste more time. Waste time where how? and what does event-driven mean? (and how does udev *not* do that already? especially if one assumes that init scripts have dependencies properly expressed) [sidenote: a context-free response like anything else will just waste time is the fastest way to get emotional responses that can be misunderstood so that you can randomly flame everyone and everything. Not helpful, but kinda fun] What we offer you is a modern, slim, userfriendly init system with Sorry, no. upstart, systemd or the Apple thing are modern init systems, this one is not. Elaborate please. A random statement like that doesn't allow informed debates But I agree that it would have been nice 5 years ago. Well, Gentoo has had OpenRC for about 5 years, and the predecessor (which was basically the same, but pure shell scripts whereas openrc has some bits in C) was written just over a decade ago. If y'all didn't suffer so much from NIH and everyone else is silly you could have planned the switch 5 years ago and thus wouldn't have anything to complain about now ;) Oh well. Your decision, I've enjoyed having named runlevels and such things for so long that I still wonder how everyone else took a decade to even think about it ... Take care (and try to be less passive-agressive in emails), Patrick -- 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/4fa7d451.2070...@gentoo.org
Re: RFC: OpenRC as Init System for Debian
On 04/27/12 03:08, Ben Hutchings wrote: [snip] Don't assume dynamic device detection is only about personal machines or USB. It's useful in a much wider context. Agreed it is *useful* in many cases. But I also agree that it is not *required* in *all* cases. I believe Debian still supports running locally compiled kernels which do not depend on udev, and that some setups do not require udev either (not everyone use fibre channel). It is supported only in the sense that it is not yet impossible. Please don't ask anyone to spend time to avoid udev dependencies; hotplugging is normal and udev is the proper way to handle all devices the Linux kernel finds. Actually ... mdev does the job quite nicely. All (well, almost all) udev does is listen on a netlink socket for kernel events, then look which rule matches and then do what the rule tells you to do. There's no strict dependency on udev, it's just a convenient default implementation. And as it has gotten more inconvenient maybe we should just add a udev rule parser to mdev and be done with it? Have fun, Patrick -- 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/4fa7d56d.9080...@gentoo.org
Re: RFC: OpenRC as Init System for Debian
On 04/27/12 15:54, Josselin Mouette wrote: Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit : Yes of course, because event-driven init systems have *always* been *only* about mounting USB devices. Then explain the _real_ reasons for having an event driven boot system! BECAUSE THE LINUX KERNEL IS EVENT DRIVEN. Full stop. End of story. Bye bye. Calm down, take a breath, think about ponies or butterflies or whatever lets your mind go to the happy place ... This must have been explained HUNDREDS of times in the endless threads full of stupid messages from stupid dumbasses who don’t understand a thing about init systems but don’t want their precious, idiotic, buggy init scripts to go away. Ok, you're mixing a few concepts *and* insulting everyone who tried to have a technical discussion here. That's rude. Please don't do that. Now, let's take these issues apart into simple problems we can understand and fix: * buggy initscripts - well, just fix them * idiotic because no dependencies - that's why some people suggest OpenRC or maybe upstart if that's your cup of tea. Solved problem, so don't go on a NIH rampage ... * event driven - I really (really!) hate repeating myself, but, *sigh* what does event driven mean in that context? (now I feel the need to wash my hands. Don't make me repeat myself again!) * how does the current combo of udev/mdev and OpenRC not cover that? * abuse of capital letters - no, caps lock isn't cruise control for cool. Finding new hardware for example can be related to software like hwdata. And why is udev classified as important, what's the use of that on servers? Because Linux, in its current architecture, won’t work correctly without it. Blah. The only things that won't work are the two big desktop environments that have a dependency on libudev / gudev. And that is easily rectified. Having a udev-free system is surprisingly easy and without big surprises. You should try it :) So, if you want to have a polite discussion among adults, feel free to join ... Take care, Patrick -- 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/4fa7d6ce.7030...@gentoo.org
Re: non-event-based init systems are unfixable [Was: Re: RFC: OpenRC as Init System for Debian]
On 04/30/12 02:09, Steve Langasek wrote: On Sun, Apr 29, 2012 at 03:59:03PM +0200, Stephan Seitz wrote: On Sun, Apr 29, 2012 at 10:33:16PM +0900, Miles Bader wrote: Isn't mounting filesystems, which can depend on the network, part of the boot process? Yes, but how do you check if the network is configured and operational? - when the link is up? - when the IP address is configured (how do you check this with IPv6?)?What are you doing if more than one IP address is configured for this NIC or more than one NIC is available? - when the switch accepts traffic on the port you are connected to? - when the router/firewall accepts traffic from your IP address? Retransmitting your packets because the network is not yet delivering them is an entirely different error handling scenario from rebinding because your service was started before the system has an address (or interface). The former is handled transparently by the protocol stack and the latter requires every application to handle it manually - and the only way the application can handle it is by stupid polling. This becomes quite esoteric and theoretical. The usual conventions are when you have an IP that interface is up or, if you have something really funky, maybe when you can send ICMP and get a reply the interface is up. All those corner cases need specific checks added for that specific deviation from what we call standard either way. It's not easily fixable in the general case. Linux is an event-based system, and we need to do event-based activation of the software, so that we don't have to patch a hundred processes to poll for the network to show up underneath them. What a confusing idea. If your init scripts had dependencies (I know, a radical new idea that won't work anyway) it'd be trivial to not start foo until bar reports to be started. And bar could make that is-started-check as elaborate and complex as you want ... The fact that v6 addresses may come and go without generating events seen by userspace is a deficiency with the current system; but a) it's a solvable one, b) having reliable events for all the *other* scenarios is a huge reliability improvement over the sysvinit status quo. For some insight into how upstart structures its events to ensure reliable start of network services on boot, see the Upstart Cookbook: http://upstart.ubuntu.com/cookbook/ No event based init system will solve these problems when you have dependencies outside the box you are booting. The local admin has to check if all timings are right and must adjust them if they are not fitting. IOW, the admin has to add a bunch of sleep's everywhere? Pass, thanks. Old-skool. Haven't seen that style in a while, I thought it had died out in the last decade. Maybe you should spend some more time with these newfangled gizmos and thingamajigs before claiming they are ugly and don't work anyway? Take care, Patrick -- 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/4fa7d9c7.7050...@gentoo.org
Re: RFC: OpenRC as Init System for Debian
On 05/02/12 04:55, Carlos Alberto Lopez Perez wrote: On 27/04/12 19:33, Tollef Fog Heen wrote: ]] Martin Wuertele * Josselin Mouette j...@debian.org [2012-04-27 09:53]: Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit : Yes of course, because event-driven init systems have *always* been *only* about mounting USB devices. Then explain the _real_ reasons for having an event driven boot system! BECAUSE THE LINUX KERNEL IS EVENT DRIVEN. That's a reason for udev/mdev, however I still fail to see why this results in the requirement for an event based boot process. A trivial example is $remote_fs isn't satisfied until /srv/somewhere is mounted and /srv/somewhere comes off iscsi, which means it requires networking to be up, which means network drivers loaded, etc. So the event «network driver loaded» causes ifup to be spawned, which causes $network to be satisfied which causes the iscsi daemons to be started which causes mount to be called. A better example is bluetooth. In my Debian system I have /usr/sbin/bluetoothd running and I don't have any bluetooth devices on my system... So wouldn't be better that instead of launching the bluetooth daemon and let it waiting for the day that I plug a USB bluetooth device (and still I never did that) to just launch this daemon only when the kernel detects a bluetooth device? You mean like udev triggering an init script? Yeah, that's kinda cool. If only someone actually used that ohwait :) For a fast and efficient boot-up two things are crucial: * To start less. Which means less mandatory deps. I'm down to ~2 seconds for userspace on most of my servers, or about 15 seconds if a stupid service like mysql is involved that just takes 5 seconds to figure out what to do next. Before that the kernel takes about 2-3 seconds, that's hard to get faster. And anyway the BIOS will fiddle around and do nothing useful for 30-90 seconds - userspace is by far the smallest chunk of that, but for some reason everyone tries to make that faster. How strange. * And to start more in parallel. Been there done that. It gets very hard to define dependencies in a way that is cycle-free and efficient. And you can hit the funny spot where IO becomes your bottleneck, which is mildly silly. What does that mean? Starting less means starting fewer services or deferring the starting of services until they are actually needed. Deferring is bad and should be optional. Makes failures so much more exciting because they happen at random times later where no one is watching them and things get annoying to untangle ... There are some services where we know that they will be required sooner or later (syslog, D-Bus system bus, etc.), but for many others this isn't the case. For example, bluetoothd does not need to be running unless a bluetooth dongle is actually plugged in or an application wants to talk to its D-Bus interfaces. Same for a printing system: unless the machine physically is connected to a printer, or an application wants to print something, there is no need to run a printing daemon such as CUPS. Avahi: if the machine is not connected to a network, there is no need to run Avahi, unless some application wants to use its APIs. Or you enjoy parallel bootup where cupsd starting has no effect on the rest, because ... parallel 'n stuff. And even SSH: as long as nobody wants to contact your machine there is no need to run it, as long as it is then started on the first connection. (And admit it, on most machines where sshd might be listening somebody connects to it only every other month or so.) Yeah, and if the machine slows down because it is swapping I can't login because suddenly you need to start services ... hey, with cgroups you can even make openssh OOM-safe and with a guaranteed share of system resources. *that* is awesomesauce. Starting more in parallel means that if we have to run something, we should not serialize its start-up (as sysvinit does), but run it all at the same time, so that the available CPU and disk IO bandwidth is maxed out, and hence the overall start-up time minimized. http://0pointer.de/blog/projects/systemd.html as sysvinit does ... no, sysvinit doesn't. Sysvinit calls whatever is defined in /etc/inittab for the default runlevel (usually 5). And what that thing does ... your choice, man. You could even use monit or runit to start your init scripts. Well, or you could be a bore and just use OpenRC (run /sbin rc default from inittab), set rc_parallel=YES in /etc/rc.conf and be happy. Yeah, I know, such a conservative boring working solution, where's the excitement? :) Have a nice day, Patrick -- 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/4fa7ddbf.3050...@gentoo.org
Re: RFC: OpenRC as Init System for Debian
On 05/08/12 00:04, Marco d'Itri wrote:
On May 07, Ben Hutchings b...@decadent.org.uk wrote:
Means that services can be started (and stopped?) in response to events
such as hardware discovery, incoming network connections, the status of
other services, and so on. (With dependencies still taken into
account.)
I want to add another major event: the service exiting.
Being able to reliably monitor and automatically restart a failed
service is critical.
well, that's another 10 lines of shell worst case. We haven't agreed on
how exactly to handle it and make it configurable and stuff (especially
as tools like monit cover that niche better)
but - here's the magic:
$ cat /sys/fs/cgroup/openrc/release_agent
/lib64/rc/sh/cgroup-release-agent.sh
So, whenever a CGroup becomes empty we trigger a script. That script now
can do ... well ... everything.
Including restarting ${SVCNAME}.
Where we disagree is mostly the policy - is that enabled by default?
(potentially bad)
What if a service gets restarted multiple times? (infinite loop)
Do we want to add a general notifier? (send an email, foo crashed, I
restarted it)
Apart from that it's trivial to add restarting functionality.
No, enough politeness. We get that you like the way Gentoo does things
(lots of options, you get to keep the pieces when they break), but some
of us are trying to make Debian better than that. We don't need more
half-assed options, we need a solution.
AOL.
Y'all really want to play that game?
Ok, let me play too. I like games.
Bash - debian had netdevices disabled for the longest time, which made
it impossible to just use a normal script that leveraged that awesome
feature. So, uhm, not cool.
Some packages broken on purpose. See nginx (old stupid version not
supported by upstream) that has some random broken thirdparty modules
compiled in so that the upstream documentation doesn't apply for
loadbalancing. Extra bonus: that breakage got imported into other
distros like ubuntu.
But a single package is not representative of the distro yeah right,
now suddenly that's not fair game?
OpenSSL.
Now, we can just continue mudslinging, and in the end it's great fun but
nothing productive, or you guys could just stop looking down on
everything else and accept that sometimes other people do produce decent
things.
If you want to make Debian better you could start by looking at where
others have eclipsed you already and figure out how to catch up. Unless
you are willing to accept that possibility and learn you'll be stuck in
NIH hell and rediscover every little corner case and trivial bug that
others already fixed years ago.
But, hey, that's not my fight. I won't stop you from being silly, I just
reserve the right to point and laugh at appropriate times.
Have a nice day,
Patrick
--
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/4fa7f859.7050...@gentoo.org
Re: smaller than 0 but not negative (Re: question about Conflicts:
On 05/03/12 23:16, Holger Levsen wrote: Hi, On Donnerstag, 3. Mai 2012, Guillem Jover wrote: RPM has now support for ~ in latest git. http://rpm.org/ticket/56 oh shiny! thanks for that pointer! anybody know by chance whether gentoo is jumping on this too? Not this decade - we're ahead of the pack, as usual ;) http://dev.gentoo.org/~ulm/pms/4/pms.html#x1-270003.2 This allows foo-1.0_alpha to be smaller than foo-1.0 without having to add any extra magic. Have a nice compile, Patrick -- 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/4fa2a61c.4000...@gentoo.org
Re: smaller than 0 but not negative (Re: question about Conflicts:
On 05/04/12 00:14, Tollef Fog Heen wrote: ]] Patrick Lauer Not this decade - we're ahead of the pack, as usual ;) So you don't support for instance 1.0~git20120503, then? (the git snapshot from today of what will become 1.0) What a weird idea. 1.0_pre20120503 maybe, but why package a snapshot like that when you can just have a live packages that checks out and builds from git directly ... (and have that updated whenever it tickles your fancy) -- 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/4fa2b1dc.4090...@gentoo.org
Re: RFC: OpenRC as Init System for Debian
On 05/04/12 01:58, David Weinehall wrote: On Thu, May 03, 2012 at 08:54:11AM +0800, Patrick Lauer wrote: On 05/03/12 02:16, Michael Biebl wrote: On 02.05.2012 19:05, Martin Wuertele wrote: I don't think this is a better example. Actually I think this is an example where udev/mdev could launch/stop bluetoothd. Long running daemons should *not* be started by udev. udev is *not* a service manager. What udev should do is signal the init system that the device is available and the init system will start and manage the daemon. That's what systemd and upstart do. So, this whole sub-thread boils down to this: Our current init scripts don't handle dependencies properly Once you fix that you can just let udev trigger /etc/init.d/bluetooth start, and that will do all the needed magic properly. ... and OpenRC has been doing that for such a long time that I find it hard to understand that people are still not using it ;) I'm still slightly confused what people mean with event based, I think there are at least three similar, but distinct definitions going around. A good part of that is already handled by the device manager, and the rest appears to be user actions - if someone can find me a good example of an event that doesn't fit into these categories I might understand why from my point of view people seem to be violently agreeing so hard. So, what you're saying is that we should fork udev to do things that neither its upstream developer nor its Debian maintainer doesn't intend for it to do, Not at all. I'm possibly suggesting actually using udev features, but then I guess upstream will remove all of them that are fun all to make it possible to use an init-system that doesn't support events, instead of using an event based system that's designed to work with udev? Somehow I get the feeling that I've asked this before, in which case I'd be repeating myself, which is very rude of you ... but ... *which* events !? If it's only device hotplugging / uevents we already have a handler for that that can execute arbitrary code (udev/mdev), if not then someone should at some point in time enlighten me what event based means to them so I can finally see why people are disagreeing there. 'cause right now it looks like violent agreement to me, which makes little sense :) Yeah, makes perfect sense... Sense ... if we had some more of that this discussion wouldn't have started at all ;) -- 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/4fa323ea.4000...@gentoo.org
Re: RFC: OpenRC as Init System for Debian
On 05/03/12 02:16, Michael Biebl wrote: On 02.05.2012 19:05, Martin Wuertele wrote: I don't think this is a better example. Actually I think this is an example where udev/mdev could launch/stop bluetoothd. Long running daemons should *not* be started by udev. udev is *not* a service manager. What udev should do is signal the init system that the device is available and the init system will start and manage the daemon. That's what systemd and upstart do. So, this whole sub-thread boils down to this: Our current init scripts don't handle dependencies properly Once you fix that you can just let udev trigger /etc/init.d/bluetooth start, and that will do all the needed magic properly. ... and OpenRC has been doing that for such a long time that I find it hard to understand that people are still not using it ;) I'm still slightly confused what people mean with event based, I think there are at least three similar, but distinct definitions going around. A good part of that is already handled by the device manager, and the rest appears to be user actions - if someone can find me a good example of an event that doesn't fit into these categories I might understand why from my point of view people seem to be violently agreeing so hard. Thanks, Patrick -- 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/4fa1d733.5040...@gentoo.org
Re: RFC: OpenRC as Init System for Debian
On 04/27/12 18:50, Martin Wuertele wrote: * Josselin Mouette j...@debian.org [2012-04-27 09:53]: Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit : Yes of course, because event-driven init systems have *always* been *only* about mounting USB devices. Then explain the _real_ reasons for having an event driven boot system! BECAUSE THE LINUX KERNEL IS EVENT DRIVEN. That's a reason for udev/mdev, however I still fail to see why this results in the requirement for an event based boot process. Especially as your device manager can trigger services, so you already have the mechanism for an event-driven system, what's missing then is only policy ... Could you enlighten me please. Kind regards, Martin -- 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/4f9a7e1f.8060...@gentoo.org
Re: RFC: OpenRC as Init System for Debian
On 04/27/12 03:32, Adam Borowski wrote: On Thu, Apr 26, 2012 at 08:08:01PM +0100, Ben Hutchings wrote: On Thu, Apr 26, 2012 at 02:03:17PM -0400, Jonas Smedegaard wrote: I believe Debian still supports running locally compiled kernels which do not depend on udev, and that some setups do not require udev either (not everyone use fibre channel). It is supported only in the sense that it is not yet impossible. Please don't ask anyone to spend time to avoid udev dependencies; hotplugging is normal and udev is the proper way to handle all devices the Linux kernel finds. udev is just the reference implementation. mdev [part of busybox] can do the same (modulo rules: it has a slightly simpler format that doesn't provide exactly the same features (yet)) All you need is a netlink socket and a listener that understands the kernel events coming in ... They are even enumerated so you can choose to serialize them (which, in general, is a good idea). And I still haven't figured out what things you can do with /sys/kernel/uevent_helper :) No udev dependencies in the userland are a good thing: this simplifies chroots, vservers, etc. No udev dependencies wrt handling real hardware are a waste of time, and complicate stuff. on a vserver you might be able to work with a devtmpfs only, but using mdev seems to work quite well too. The only real dependency on udev is libudev/gudev, and that only affects the Big Desktop Environments for now, as far as I can tell. Take care, Patrick -- 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/4f99ee6d.3020...@gentoo.org
Re: RFC: OpenRC as Init System for Debian
On 04/27/12 08:02, Russ Allbery wrote:
Petter Reinholdtsen p...@hungry.com writes:
Say you want to mount a network disk during boot. This depend on the
network being configured. This in turn might depend on a DHCP reply
from a DHCP server, and to send the DHCP request the network card need
to be detected. To detect the network card, the network driver need to
be loaded, and the network card need to be found on the PCI or some
other internal bus. And with the Linux kernel today, there is no way to
know when during boot the network card will be found on the bus. To
make this work reliably, the boot system need to be event based, not
sequence based.
I disagree. If you have stateful init scripts you just wait until the
needed event arrives / statechange happens, *then* mark it as started.
And during that time you let the init script handler run in a loop that
polls, say, every second if the other init script declares itself started.
And lest someone think this is a theoretical exercise, we *frequently* get
bugs filed against packages like OpenAFS, the Kerberos KDCs, or OpenLDAP
that are boot-order-dependent and network-dependent and either don't start
or start in unuseful ways or at unuseful times because of lack of event
notification for when interfaces are *actually* ready or when network
devices are *really* available.
That looks like a lack of design to me - and random timeouts are
dangerous. It might work on a lightly loaded machine, most of the time.
It makes more sense to me to have meaningful return values :)
These bugs are essentially unresolvable without something that understands
kernel events
... udev/mdev/ /sys/kernel/uevent_helper to the rescue ...
and can use them as input into boot dependency processing.
and now you're just reimagining OpenRC ;)
This is why so many packages resort to adding sleep calls with random
delays to their init scripts in the hope that everything will be ready
after some arbitrary delay.
The alternative is to add significantly additional complexity to every
package like those listed above that needs the network to loop and retry
if the network isn't available when it first starts. This is a huge waste
of effort.
... or make the wrappers around init scripts smart enough, so you have
marginal complexity in one place.
Don't Repeat Yourself applies to init scripts too, there's no need to
have more than a #! line as boilerplate.
Just for fun, here's all the logic we need to get rsyncd started, *and*
it only starts once network is properly up (where the definition of up
is user-configurable as we often disagree on it):
#!/sbin/runscript
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/net-misc/rsync/files/rsyncd.init.d-r1,v 1.1
2012/03/22 22:01:21 idl0r Exp $
command=/usr/bin/rsync
command_args=--daemon ${RSYNC_OPTS}
pidfile=/var/run/${SVCNAME}.pid
depend() {
use net
}
Because repeating yourself is tedious we have default functions now, so
no need for explicit start and stop - it just works.
Enjoy,
Patrick
--
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/4f99f18a.10...@gentoo.org
RFC: OpenRC as Init System for Debian
Greetings, in the last months there have been many discussions about init systems, especially systemd. The current state seems to make no one really happy - the current debian init system is a bit minimal and doesn't even do stateful services in an elegant way (e.g. /etc/init.d/apache2 start; /etc/init.d/apache2 start). On the other hand systemd is just Not The Unix Way, it consolidates everything into one huge process and forces some imppossible dependencies (dbus? udev? on my server?! and you expect a linux 3.0+ kernel? waaah!). But everyone else is moving to systemd, so where does that leave us? (One might notice that everyone else is just Fedora/RHEL at the moment, with (open)SuSE tagging along, and most others still not committed to a migration yet) I'd like to ask you to evaluate OpenRC as candidate to replace the old have-always-been-there sysvinit/insserv init scripts in Debian. While Gentoo is by far the largest user it's definitely not the only one - there are the direct derivatives (Sabayon, pentoo, funtoo, sysrescuecd, tinhat, ...) and some foreign users (Alpine, a debian derivative, uses OpenRC) What we offer you is a modern, slim, userfriendly init system with minimal dependencies. All you need is a C99 compiler and a posix sh! The list of features is long and tedious (see http://wiki.gentoo.org/wiki/OpenRC ), but the critical bits are: * portable - we have it running on Linux, *BSD, and there's no reason why it should fail on other unixoid platforms * dependency-based init scripts - no need to manually figure out the startup order, something like before apache, after logger is all you need to specify * small footprint - 10k LoC C99, ~3k LoC Posix SH out of the box (plus your own init scripts, of course) * friendly responsive upstream (let's figure out how we can cooperate, eh?) * boring - deterministic reproducable bootup, including interactive mode and verbose debug output For a long time we haven't done any active advertising, but OpenRC is now about 5 years old, and it is a drop-in replacement for our previous baselayout init system (which was started over a decade ago). We don't try to take over the world, we just create the best solution for our needs. And those go all the way from embedded systems (where you can use busybox for all the shell tools) to servers (minimal deps! No mandatory udev or dbus!) and desktops (including optional splash screen eyecandy and whatever makes you happy). There's pretty good support for advanced usage like SELinux, built-in support for ulimit and cgroups to do per-service resource limits, and it even comes with a friendly license (although some might say that a 2-clause BSD license it too friendly and promiscuous). And as a random bonus feature you get stupid-fast bootup - We've seen 5sec from bootloader handover to login prompt (depending on hardware and amount of services started, of course) and 5sec for rebooting a kvm guest. Should you decide to switch (or just evaluate if switching is possible / makes sense) you'll get full support from us in migrating init scripts and figuring out all the nontrivial changes. Just visit us on IRC ( #openrc on irc.freenode.net), send us a mail ( ope...@gentoo.org ) or meet us for a beer or two. Thanks for your consideration, Patrick Lauer Gentoo Developer, OpenRC co-maintainer -- 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/4f97f3ab.4090...@gentoo.org
Re: RFC: OpenRC as Init System for Debian
On 04/25/12 21:40, Arto Jantunen wrote: [snip] I'd like to ask you to evaluate OpenRC as candidate to replace the old have-always-been-there sysvinit/insserv init scripts in Debian. Based on this text it seems to me that OpenRC doesn't do anything that our current init wouldn't do (we already have dependencies and concurrent startup), * stateful init scripts (e.g. /etc/init.d/apache2 start - * WARNING: apache2 has already been started) * nice management tools (rc-status shows what init scripts are in the current runlevel and their current state) And many small features that just make life a bit easier like named runlevels (so it's single instead of 1) and also that it wouldn't solve the problem upstart and systemd were created to solve. I might be wrong here since I don't know OpenRC, so correct me if I'm missing something. Both upstart and systemd suffer from NIH and (imo) fail to be simple and reliable. But you are right, OpenRC is not revolutionary, it's more a consequent evolution that happened as we were slowly fixing all the little bugs that annoyed us. It seems to me that many of the conversations about init systems have been missing the point quite badly as well, so it might be that this isn't obvious. To me the point is clearly reliable bootup, not speed or dependencies themselves (the dependencies are required for implementing reliable bootup, and the speed is produced as a side effect of correctness). In my experience OpenRC has the most reliable and deterministic bootup, and it makes it easy to figure out your current state (is apache still running? Should it be running?) Performance and all that is just a bonus for me, always correct is more important than fast :) Reliability in the case of modern kernels and modern hardware means event based, not static. The hardware in a modern computer comes and goes as it pleases (usb devices being the worst example, but scanning for pci or sata busses and loading drivers isn't exactly instant in all cases either), and the kernel has little choice in the matter. It can either sleep until everything is surely detected by now before passing control to userspace, or pass control and the problem along (by providing event notification when the device set changes). The kernel made its choice about this years ago, and we have been living on borrowed time and kludges since then. I mildly disagree there. The init system doesn't need to know about such things, it only provides the actions. The device manager (what used to be udev+hal, then was udev/gudev and is now systemd) should handle the policy. So - connecting a usb wlan card triggers a kernel event, which udev processes, and udev then decides from its rules what action to take - say /etc/init.d/net.wlan0 start (Although there is a considerable overlap between rules and actions) For me there's no reason why udev / mdev can't stay standalone, integrating it into the startup scripts doesn't feel right. Have a nice day, Patrick Lauer -- 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/4f980e8e.6020...@gentoo.org
