Re: Bits from the Debian GNU/Hurd porters
Hey Michael, Michael Banck mba...@debian.org writes: This is an update to the last Debian GNU/Hurd bits from February 2012[0] [...] Thank you very much for this comprehensive wrap up. I am excited to see these advancements around GNU/Hurd, so excited that I am seriously planning to install it on my primary (at the same time old enough) laptop. In late April, the hurd-i386 port has achieved the 80% mark of packages built for the first time[2], an improvement of 10% since the last bits in 2012. This is on the one hand due to improvements and better compatibility in glibc, and on the other hand due to the work of many porters, notably Svante Signell, Pino Toscano, Gabriele Giacone and others. [...] I see familiar names here. Good job! Cheers, Benda pgpZUnVtDdOjQ.pgp Description: PGP signature
Balance of portability and maintenance burden (Re: default init on non-Linux platforms)
Hey Adrian, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: That's correct. However, the problem with kFreeBSD is that I - as a package maintainer - have to invest extra time to make sure my packages don't FTBFS on these architectures as otherwise my packages wouldn't be allowed to migrate to testing. Time which I rather invest into more important packaging work. If you are that concerned about the maintenance burden, I am happy to say OpenRC packagers are willing to help in this situation for any OpenRC related issues. Just bug us. On kFreeBSD, IMHO, diversity is quite a good thing, even from a packager maintainer PoV. Making your package portable in the correct way (say, not temperary conditional block hacks) is generally good for its rubostness. Implicit assumptions to a single environment ease our tasks in the short run, but accumulate and exploit the health of the package in the long run. Cheers, Benda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86a9dhs71i.fsf...@moguhome00.in.awa.tohoku.ac.jp
Re: default init on non-Linux platforms
Dear Kevin, Kevin Chadwick ma1l1i...@yahoo.co.uk writes: The benefit that Linux and even firefox etc. has gained from OpenBSD's practically paranoid bug fixing as well as finding the bugs for all the platforms it's userland still runs on especially in compiler tools should be realised and not underestimated. To some degree it will be true for debians HURD and is it kfreebsd too. So I don't get the holding Linux back rubbish especially when it is often based on superficial arguments that carry little weight, atleast in my eyes. Isolating Linux would hold it back and make it a flakier system in my eyes. Thanks! That's exactly what I want to say. I would like to have Debian GNU/kFreeBSD and GNU/Linux, butterflies and human beings share this planet. Benda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/861tyts6di@moguhome00.in.awa.tohoku.ac.jp
Re: default init on non-Linux platforms
Dear Adrian, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: So, OpenRC actually also relies on files - like System V Init - to track the state of a service? Isn't that approach somewhat unreliable and hacky? I bet you are going to tell me the only reliable and non-hacky way to track the state of a service is not forking/writing to files but starting it foreground by a long-living daemon. I agree with you. OpenRC leverages cgroups when available. We are also working on a plugin framework for external supervisors such as djbtools, runit and s6 (maybe launchd, smf, systemd, ... as well if they're hackable) to do this foreground status tracking while integrated with OpenRC: We are not there yet though. These advanced features are optional. We can still use the unreliable and hacky way of trakcing files when the task is trivial, like a personal VPS or laptop which do not care much about running sshd/httpd for 3 years non-stop. Thanks for the insight. Benda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86eh2w8ylo@moguhome00.in.awa.tohoku.ac.jp
Re: default init on non-Linux platforms
Dear Adrian, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: On 02/21/2014 01:00 PM, hero...@gentoo.org wrote: So, OpenRC actually also relies on files - like System V Init - to track the state of a service? Isn't that approach somewhat unreliable and hacky? I bet you are going to tell me the only reliable and non-hacky way to track the state of a service is not forking/writing to files but starting it foreground by a long-living daemon. I agree with you. Well, I was thinking about something like CGroups. I don't like the idea of having to rely on files for an init system to be able to track the processes it has started. I agree and understand that this was the way to go back in the old days, but we shouldn't be using that on current setups. At my department, we stumbled right over this design when the /var filesystem was full and System V Init could no longer create PID files to be able to track services, yet it started services without complaining. Since we had to restart our dhcpd several days on a particular day, System V Init was unable to track whether the daemon was already running and we ended up with several dozen instances. Sure, it's probably a bug in the init script used as it didn't check for enough disk space and wasn't failing when the disk is full. But again, this is a core component depending on external scripts being bug free which is not the correct approach when you are aiming for something robust. Thank your for sharing with us your real life story. I can reasonate with it: having a dhcpd malfunctioning and hundreds of people complaining about the resulting unstable network is no fun at all. How to cope with this will be a matter of personal taste. You might think a robust framework will make it fool-proof. While I might think running a central dhcp server along with something else which possibly fill up the /var is questionable itself. I appreciate both. OpenRC leverages cgroups when available. We are also working on a plugin framework for external supervisors such as djbtools, runit and s6 (maybe launchd, smf, systemd, ... as well if they're hackable) to do this foreground status tracking while integrated with OpenRC: We are not there yet though. Can external supervisors like djbtools or runit actually reliably track processes and if, yes, how? From my understanding, it's impossible to be able to really track a process once it has started when you don't have the possibility to use something like CGroups as services could always just double-fork. The tracking has to be done through a mechanism provided by the kernel, doesn't it? I've meant foreground, the opposite of double-fork, which has been discussed in the list, like: http://article.gmane.org/gmane.linux.debian.devel.general/152538 This does not require a special tracking mechanism in the kernel. Double-fork is not a reliable way to track process. People invented it as a hack back in history (from BSD community if I remember it right). And grepping through the output of ps or similar is not what I would consider reliable and robust either. Nod. grepping `ps` is what we should avoid at all cost. These advanced features are optional. We can still use the unreliable and hacky way of trakcing files when the task is trivial, like a personal VPS or laptop which do not care much about running sshd/httpd for 3 years non-stop. Sure, I fully agree. But there are actually many enterprises who need something with 99% service availability. Our department runs a webserver, a login node for 1200 users and a large compute clusters with over 200 nodes and an SGI UV1000 (1024 CPUs, 2 TiB), so we need something which is able to control resources and track processes. Many enterprises and websites run Debian. Yes, though I am a casual user, I actually had systemd and monit to supervise httpd in one of our mirror servers. And I myself am even using a computing cluter running RHEL5 (for stability and paid customer service). So I am quite sharing the view with you. Different people in different situations have different needs: Using a bad old pid-file tracking, or no tracking at all is like wearing jeans at home, or even naked. It happily coexists with the situation of wearing suites doing public speech. --- super light-hearded, just for fun, don't take it seriously --- modern activists: com'on, just us, or you'll not be supported. (com'on, wear suites, or you're out) old nerds: fine, we will support ourselves. (fine, we will find somewhere comfortable to be naked) --- end --- Hope this explains why I am devoting to something alternative and even counter-advertised as suboptimal. Let's coexist and have fun. This universe is ultimately a friendly place to live in after all. Coming back to our starting point: service relying on file-tracking is hackish and is recommended to be avoided in serious business in preferrence to a better available supervising solution.
Re: default init on non-Linux platforms
Hey Ondřej,
Ondřej Surý ond...@sury.org writes:
I have split openrc into openrc and openrc-sysv moving the conflicting
parts to openrc-sysv on my system, and it install just fine, but running
script with /sbin/openrc-run needs:
mkdir -p /run/openrc
touch /run/openrc/softlevel
and then it still doesn't work as expected:
root@howl:/etc/init.d# /etc/init.d/rsyslog start
* WARNING: rsyslog is already starting
root@howl:/etc/init.d# /etc/init.d/rsyslog stop
* ERROR: rsyslog stopped by something else
root@howl:/etc/init.d# /etc/init.d/rsyslog status
* status: stopped
OpenRC needs a proper directory structure in /run/openrc to track the
status of services. It is handled by init.sh and friends, you may need
to hack that.
root@howl:/etc/init.d# ps uax | grep rsyslo[g]
root 6743 0.0 0.0 52592 1752 ?Ssl 20:28 0:00
/usr/sbin/rsyslogd -n -c5
root 6764 0.0 0.0 7768 856 pts/0S+ 20:28 0:00 grep
rsyslog
Thomas, would it be possible to make openrc-run work even when the
openrc doesn't replace /etc/init.d/rc{,S}?
sure.
Or does it need too much from openrc infrastructure, so my idea is
just too crazy?
No, it not crazy. I am running OpenRC to manage services on the clusters
where I have only normal user privilege, it's in parallel to sysv-rc
like system of RHEL5. You might look into the MKPREFIX build option.
And out of curiosity, what are you trying to achieve here?
Cheers,
Benda
Re: default init on non-Linux platforms
Hi Tollef, Tollef Fog Heen tfh...@err.no writes: It's probably better to just contribute your changes to the sysv-rc version and so make that one able to manage openrc in addition to the others it already knows how to. No point in forking it. Forking was a decision made by me in the early phase of packaging OpenRC. At that time I referred to the way file-rc handled update-rc.d as in sysvinit: /usr/share/sysvinit/update-rc.d A central package providing update-rc.d and invoke-rc.d is nice. Though it should not be sysv-rc, which OpenRC is intending to replace. Cheers, Benda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86a9dmbbtp@moguhome00.in.awa.tohoku.ac.jp
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
Sergey B Kirpichev skirpic...@gmail.com writes: http://packages.qa.debian.org/m/monit.html Usually, you want to start this service last and stop first. The question is, before or after rc.local? -- 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/86ha8avpsh@moguhome00.in.awa.tohoku.ac.jp
Re: File naming of scripts in /etc/init.d
Petter Reinholdtsen petter.reinholdt...@usit.uio.no writes: Before concurrent running of init.d scripts were implemented in sysv-rc, the .sh scripts would be sourced by /etc/init.d/rc and /etc/init.d/rcS while the non-.sh scripts would be executed. This distinciton were removed when sysv-rc started to run scripts in parallell, as it no longer made sense. What a history! Provided that all the scripts are executed, is there any plan to strip the .sh suffix? -- 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/86zjm5yexc@moguhome00.in.awa.tohoku.ac.jp
Re: porting OpenRC on kFreeBSD and Hurd
Hey Svante, Svante Signell svante.sign...@gmail.com writes: Good news: openrc now boots fine on GNU/Hurd with a patched sysvinit, see #721917 Good job! and soon to be updated patches of openrc (0.12.4+20131230-7) side note: 0.12.4+20131230-7 is already in tree http://packages.qa.debian.org/o/openrc/news/20140122T091942Z.html that'll be an -8 then. for GNU/Hurd :-) bug #736636 Cheers, Benda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8638kbh55l@moguhome00.in.awa.tohoku.ac.jp
Re: porting OpenRC on kFreeBSD and Hurd
Hey Svante, Svante Signell svante.sign...@gmail.com writes: Good news: openrc now boots fine on GNU/Hurd with a patched sysvinit, see #721917 Good job! and soon to be updated patches of openrc (0.12.4+20131230-7) side note: 0.12.4+20131230-7 is already in tree http://packages.qa.debian.org/o/openrc/news/20140122T091942Z.html that'll be an -8 then. for GNU/Hurd :-) bug #736636 Cheers, Benda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/864n4rh572@moguhome00.in.awa.tohoku.ac.jp
Re: porting OpenRC to Debian GNU/kFreeBSD
Thomas Goirand z...@debian.org writes: I'm very happy to tell everyone that this is *FIXED* !!! http://youtu.be/zoNoi8BgQjs :D :D :D Wow. That's absolutely great zigo! Although the Caching service dependencies seems to be a regression to me months ago, where the cache should be generated only once and not on every boot. -- 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/86haby9gqv@moguhome00.in.awa.tohoku.ac.jp
Re: debian ova instance generator
Dear Lars, Lars Wirzenius l...@liw.fi writes: You can also just create usr/sbin/policy-rc.d as a shell script that exits with 101, which may or may not be easier to deal with. Like this: cat EOF $rootdir/usr/sbin/policy-rc.d #!/bin/sh exit 101 EOF chmod a+x $rootdir/usr/sbin/policy-rc.d Remember to delete it afterwards. Thanks a lot! This is a much cleaner solution than I did. commited. http://sourceforge.net/p/aire/code/ci/31f3924/tree/Makefile?diff=fa65dfa And Thank you Lukas and Jonas. I'll just use this simple one mentioned here, and will return to this topic when things get more complicated. BTW, I came upon the debian template from lxc[1] package, which does essentially the same thing with policy-rc.d. Cheers, Benda 1. http://packages.debian.org/sid/lxc -- 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/86a9ih8f1d@moguhome00.in.awa.tohoku.ac.jp
debian ova instance generator
Dear fellows, This is a simple Makefile which generates ova[1] of customized debian, inpired by an ova build script of sagemath[2], and a guide from archlinux[5]. It is a by-product of AireLinux[3], a customized Debian for astrophysics. It basically creates a hdd image with debian debootstrapped and additional packages installed, and then calls virtualbox to generate the ova from the hdd image. Why not automated d-i in a virtual machine(vm)? vm overhead can be avoided using kpartx and chroot, resulting in faster image build. Furthermore, commands in chroot can be controled from the building host (e.g. the file dependences by Makefile, while d-i has another command context inside virtual machine. Why not Debian Live[4]? While strong in creating iso and squashfs automagically, it is not mature in creating a plain simple hdd image (not to mention a grub2 powered hdd image). Future versions are tracked in the repo[6]. Enjoy! Benda Footnotes: 1. http://en.wikipedia.org/wiki/Open_Virtualization_Format 2. http://trac.sagemath.org/ticket/11330 3. http://www.airelinux.org 4. http://live.debian.net 5. https://wiki.archlinux.org/index.php/Creating_Arch_Linux_disk_image 6. https://sourceforge.net/p/aire/code/ci/master/tree/ Makefile Description: Binary data
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Hi William, William Giokas 1007...@gmail.com writes: * 'Graphical UI: yes': Nope. side note: it is from http://0pointer.de/blog/projects/why.html Cheers, Benda pgpLYHGdS_e5Z.pgp Description: PGP signature
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Dear Russ, Russ Allbery r...@debian.org writes: I would *hope* a lot of Debian developers would do things like that, for any of the options! There's no substitute for actually trying the software and seeing how easy it is to use, how well it works, and how difficult it is to support. There are a bunch of good reasons to install packages, even if one isn't going to use them regularly. Among other things, it's often the easiest way to read the documentation so that one knows what people are even talking about! Maybe at some point in the future when whatever options we've converged on have been widely publicized and everyone knows how to switch and test and whatnot we might be able to gauge something about levels of interest from popcon. But it's going to be a while before we're at that point. Your objective thinking is much appreciated! Actually I was thinking of setting up test environments of systemd upstart, OpenRC (and other candidates?) on Debian development boxes (or some third party boxes which is open to DD), when Steve (excuse me for not digging out your original words) mentioned in this thread that we need a _modern_ init system which can handle race conditions in a sophiscated setup (NFS, aufs, as / /usr etc.) reliably and expected OpenRC would fail in this realm. Then we can prove our points in public and open to peer review that something is not suited for such and such. Is it realistic? Yours, Benda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8761w6dwrk@proton.in.awa.tohoku.ac.jp
modern features and OpenRC (was: Re: Survey answers part 3: systemd is not portable and what this means for our ports)
Dear all, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes: Says the guy who posted this to back up his chain of arguments: http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems Excuse me for hijacking this reply. On the wiki page. I revised it into present form last year, after a *shadow* survey (using each to see its interface and features, by performing service add/remove/start/stop) of various init systems, including sysvinit + sysv-rc, Upstart, systemd, OpenRC, SMF and launchd. It is biased, not mature and started from the biased http://0pointer.de/blog/projects/why.html to counter-argue Lennart's points. For the '??' in Device-based Activation, sorry, at that time I didn't know what it was so just copy-n-pasted. Because of the bias, It was soon moved into Talk for archieving purpose. For a objective version have a look at the main page, http://wiki.gentoo.org/wiki/Comparison_of_init_systems. For the features that people care most in OpenRC (openrc herd, correct me if I am wrong): a. process supervising: no. But OpenRC can be integrated with runit (unofficial yet), my personal effort is targeting to use s6[1] together with OpenRC. b. event-driven, mostly hotplug events OpenRC provides a HOTPLUG virtual runlevel. to keep features minimal, it relies on udev to trigger it. An example of iPhone hotplugging[2]. I forgot if inotify could fit into this. If you need more info I can dig it out. c. socket activation no. At present no solution yet. Cheers, Benda 1. http://www.skarnet.org/software/s6/why.html 2. http://wiki.gentoo.org/wiki/Iphone_USB_Tethering#udev_trigger -- 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/87ob9ycgml.fsf...@proton.in.awa.tohoku.ac.jp
Re: openrc packaging status (Re: Survey answers part 3: systemd is not portable and what this means for our ports)
Dear Guys, Holger Levsen hol...@layer-acht.org writes: one which is at least installable with apt-get + sid sources. that's still not the case, despite 684396 being announced here a year ago. (Replying generally) There seems to be some doubts concerning why #684396 has taken a whole year without being finished. This fact is quoted by people to infer OpenRC is not serious and not for production. They are two things and should not be mixed. I am only going to respond to the first question here. On my side, I am offering to package OpenRC. I did not have a deep understanding of Debian packaging and learnt as I went, although I myself had been a user for 10 years. (My servers are Debian and Gentoo, laptop/desktops are Debian.) I was not in a hurry. After composing a wiki page[1] and having all my Debian boxes with OpenRC, I just spent a bit more time to evaluate the solution by actually using it for my own daily life and production. And yeah, it's partially because of laziness. I haven't seen people ping this bug and thought there is not a wide audience so I took my own pace. I don't think we are in a race with systemd. It feels that people developing or supporting systemd are competing against the world, as if they can dominate the community by rolling out more modern features, advancing fast enough, pushing others hard and finally rendering everything alternative into the museum. This is a nice commercial strategy and is more likely to succeed in competition. But I don't care about it. Things changed when it evolves into a GSoC project, where we have a student actively working on it. It becomes my duty to co-mentor with Thomas to realize the ITP. We are gaining momentum after the student, Bill Wang, has digested the basics. I can visualize that within two months we will have a off-the-shelf OpenRC package working with initscripts/sysvinit vanilla offering modern features like cgroups, at users' choice. Voice from upstream, the OpenRC team is well aware of the effort and is eager to take patches necessary to support Debian, provided it can both benefit Debian and Gentoo, as is often the case when we come down to this level of OS. Relax fellows. let's see what we can get and have fun. Cheers, Benda 1. http://wiki.debian.org/OpenRC pgpCmSlMH3VxH.pgp Description: PGP signature
Re: Survey answers part 3: systemd is not portable and what this means for our ports
Helmut Grohne hel...@subdivi.de writes: By far the more severe issue is socket activation, because it removes the need to spell out service dependencies. We cannot infer these dependencies later on. Instead such a wrapper must implement socket activation in order to work correctly. This is the non-trivial problem. Interesting point. I am wondering if it is feasible to use x/inetd for the socket activation. -- 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/87a9ln7ge8@proton.in.awa.tohoku.ac.jp
Re: Bug#684396: ITP: openrc -- alternative boot mechanism
Dear Guys, Thanks a lot for the input from Marco d'Itri, Holger Levsen and Thomas Goirand, as well as Aron Xu off list. m...@linux.it (Marco d'Itri) writes: openrc was recently discussed on debian-devel@ and there was a large consensus that it is not a credible alternative to upstart and systemd. I think you are referring to this thread http://lists.debian.org/debian-devel/2012/04/msg00547.html We do not need to be able to choose among multiple init implementations. Holger Levsen hol...@layer-acht.org writes: while we (thankfully) have 42++ window managers in Debian, we only have 5 (or so) init systems and certainly more alternatives will be welcomed by many people, thriving to develop the best OS... whatever that means ;-) The topic of if OpenRC suits Debian is still controvasial. That's understandable. Besides, even in Gentoo community, there is voice doubting if OpenRC suits Gentoo. Debian is about the freedom to choose. I am aware of systemd, upstart, and our good plain sysv-rc as well as file-rc. People in the last thread already debated about which is the best for Debian. Personally I like the unix way[1] of OpenRC to do things, and I want to let people understand my opinion by inviting Debian users to use, evaluate and criticize it. Cool jobs are done in Redhat community/enterprise, in Ubuntu community/enterprise. Thanks to them we have many choices to suit our needs. OpenRC from Gentoo community would like also serve as your choice, with a different styple: just do one thing and do it right, not about revolution to blow your mind. Thanks Marco d'Itri, I have carefully reflected whether introducing OpenRC to Debian really worth my time and effort. And I decided to do so. Let's have fun guys ;) Yours, Benda 1. http://en.wikipedia.org/wiki/Unix_philosophy pgpoTX6slbbn7.pgp Description: PGP signature
