From 95878586ec7611791f4001a4ee17abf943fae3c1 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14" Date: Mon, 16 Feb 2015 20:08:03 +0100 Subject: rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn --- .../systemd.mdwn | 3694 ++++++++++++++++++++ 1 file changed, 3694 insertions(+) create mode 100644 service_solahart_jakarta_selatan__082122541663/systemd.mdwn (limited to 'service_solahart_jakarta_selatan__082122541663/systemd.mdwn') diff --git a/service_solahart_jakarta_selatan__082122541663/systemd.mdwn b/service_solahart_jakarta_selatan__082122541663/systemd.mdwn new file mode 100644 index 00000000..d2506046 --- /dev/null +++ b/service_solahart_jakarta_selatan__082122541663/systemd.mdwn @@ -0,0 +1,3694 @@ +[[!meta copyright="Copyright © 2010, 2011, 2013, 2014 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + + * + + * , + + + * + +Will need to have something like Linux' +[*cgroups*](http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cgroups/cgroups.txt;hb=HEAD). +Introduction: [*Ressourcen-Verwaltung mit Control Groups (cgroups)* +(german)](http://www.pro-linux.de/artikel/2/1464/ressourcen-verwaltung-mit-control-groups-cgroups.html), +Daniel Gollub, Stefan Seyfried, 2010-10-14. + +Likely there's also some other porting needed. + + +# Discussion + +This also captures discussion about other init systems, not only systemd. Also +note the additional [[upstart]] page. + + +## IRC, OFTC, #debian-hurd, 2011-05-19 + + pochu: http://news.gmane.org/gmane.comp.gnome.desktop - the + "systemd as dependency" and all the messages in it don't give me a bright + future for gnome on hurd... + yeah, I've read the thread + it's only a proposal so far... hopefully it'll be rejected, or they + will only accept the interfaces that other OSes can implement... + we'll see + you can always help me with kde on hurd, would be nice ;) + hehe + pochu: well, even if the depenency is rejected, the whole «don't + give a damn about non-linux and only bless linux for the "gnome os"» is a + bit... worrying attitude + yeah... it doesn't come from all the community though + I'm sure some people have always thought that way + Or we could get systemd going? :-) + good luck with that :p + tschwinge: haha!? :) + That bad? + tschwinge: if you mean by that forking indefinitely then maybe + tschwinge: upstream has expressely stated multiple times, no + interest whatsoever in any kind of portability to anything non-Linux + or even older Linux versions! + to the point of rejecting patches, because they "clutter" the + source code... + Well, then let's ``just'' implement the Linux interfaces. :-) + tschwinge: then you'll be always playing catch up + tschwinge: for example several of the Linux-only things upstream + makes heavy use of, are pretty recent Linux-only additions to the kernel, + but equivalents have been present on FreeBSD for years + Yeah. I'm half-serious, half-joking. + I haven't looked at the systemd code at all. + + https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html + for a list of its dependencies + some are just glibc extensions though + and some are IMO optional and should be conditionalized, but... + pochu: I don't think that attitude is that old, there was a time + when Linux was not used widely, or even that functional, I think it has + been taking strength since the Linux Plumbers Cartel started :) + as in one thing is not caring about anything non-Linux, the other + is outright rejecting portability fixes + tschwinge: in any case, these "recent" events are "pissing me + off" to the point of having considered several times implementing + portable replacements for some of those Utopia projects, the problem as + always is time though :) + tschwinge: and the issue is not only with systemd, upstart's + upstream has the same approach to portability, if you want to port it, + you'll have to maintain a fork + let's create our own init system, make it better than anyone else, + and when people start switching to it, let's start using hurd-only APIs + :) + We already had someone work on that. Like ten years ago. DMD. + Daemon Managing Daemons. + the real problem with that attitude is not the lack of care for + portabilty, the real problem is that these people are pushing for their + stuff all over the stack, and most of the time deprecating their own + stuff after a while when they have rewritten it from scratch, leaving the + burden of maintaining the old stuff to the other ports + witness HAL, ConsoleKit, etc etc + (anyway enough ranting I guess :) + Yeah, it's true, though. + agreed + + +## IRC, freenode, #hurd, 2013-01-18 + + systemd relies on linux specific stuff that is difficult to + implement + notably cgroups to isolate the deamons it starts so it knows when + they stopped regardless of their pid + just assume you can't use systemd on anything else than linux + + +## IRC, OFTC, #debian-hurd, 2013-08-12 + + huh, Lennert Poettering just mentioned the Hurd in his systmd talk + well, in the context of you IPC in Unix sucks and kdbus + s/you/how/ + QED + what did you expect? :) + I didn't quite get it, but he seemed to imply the Hurd was a step + in the right direction over Unix + (which is obvious, but it wasn't obvious he had that opinion) + + +## IRC, OFTC, #debian-hurd, 2013-08-13 + + so cgroups seems to be most prominent thing the systemd people + think the Hurd lacks + azeem: In 2010, I came to the same conclusion, + . ;-) + heh + I don't think of any show-stopper for implementing that -- just + someone to do it. + azeem: which part of cgroups, like being able to kill a cgroup? + it shouldn't be very hard to implement what systemd needs + probably also the resource allocation etc. + the questions are I guess (i) do the cgroups semantics make sense + from our POV and/or do we accept that cgroups is the "standard" now and + (ii) should systemd require concrete implementations or just the concept + in a more abstract sense + being the first non Linux OS that runs systemd would be a nice + showcase of Hurds flexibility + maybe upstart is less trouble + azeem: possibly + teythoon: can you just include upstart in your GSOC? kthxbye + at least libnih (the library with base utilities and such used + by upstart) required a working file monitor (and the current + implementation kind of exposes a fd) and certain semantics for waitid + libnih/upstart have "just" the issue of being under CLA... + pinotree: yeah, true + I suggested "startup" as a name for a fork + imho there would be no strict need to fork + azeem: but upstart is a lot less interesting. last time I used + it it wasn't even possible to disable services in a clean way + pinotree: is that still so now that Scott works for google? + pochu: yeah, since it's a Canonical CLA, not rally something + tied to a person + (iirc) + sure, but scott is the maintainer... + shrug + nah, scott left upstart + AFAIK + at least James Hunt gave a talk earlier with Steve Langasek and + introduced himself as the upstart maintainer + also I heard in the hallway track that the upstart people are + somewhat interested in BSD/Hurd support as they see it as a selling point + against systemd + pochu: it's just like FSF CLA for GNU projects: even if the + maintainers/contributors change altogether, copyright assignment is still + FSF + but their accents were kinda annoying/hard to follow so I didn't + follow their talk closesly to see whether they brought it up + pinotree: well, it's not + azeem: looking at https://code.launchpad.net/libnih, I'm not sure + libnih has a maintainer anymore... + pinotree: first off, you're not signing over the copyright with + their CLA, just giving them the right to relicense + pinotree: but more importantaly, the FSF announced in a legally + binding way that they will not take things non-free + anyway, I'll talk to the upstart guys about libnih + + +### IRC, OFTC, #debian-hurd, 2013-08-15 + + btw, I talked to vorlon about upstart and the Hurd + so the situation with libnih is that it is basically + feature-complete, but still maintained by Scott + upstart is leveraging it heavily + and Scott was (back in the days) against patches for porting + for upstart proper, Steve said he would happily take porting + patches + + +### IRC, OFTC, #debian-hurd, 2013-11-28 + + teythoon: did you see they got libnih ported to kfreebsd? + http://lists.debian.org/debian-devel/2013/11/msg00395.html + "I haven't started looking into Hurd yet," sounds promising + saw that + i looked at libnih too + wrote a mail about that + + +## IRC, freenode, #hurd, 2013-08-26 + + < youpi> teythoon: I tend to agree with mbanck + < youpi> although another thing worth considering would be adding something + similar to control groups + < youpi> AIUI, it's one of the features that systemd really requires + < braunr> uhg, cgroups already + < braunr> youpi: where is that discussion ? + < youpi> it was a private mail + < braunr> oh ok + < teythoon> right, so about upstart + < teythoon> to be blunt, I do not like upstart, though my experience with + it is limited and outdated + < braunr> that was quick :) + < braunr> i assume this follows your private discussion with youpi and + mbank ? + < teythoon> I used it on a like three years old ubuntu and back then it + couldn't do stufft hat even sysvinit could do + < teythoon> there was not much discussion, mbank suggested that I could + work on upstart + < teythoon> b/c it might be easier to support than systemd + < teythoon> which might be very well true, then again what's the benefit of + having upstart? I'm really curious, I should perhaps read up on its + features + < pinotree> event-based, etc + < youpi> it is also about avoiding being pushed out just because we don't + support it? + < teythoon> yes, but otoh systemd can do amazing things, the featurelist of + upstart reads rather mondane in comparison + < youpi> I don't really have an opinion over either, apart from portability + of the code + < braunr> teythoon: the system requirements for systemd would take much + time to implement in comparison to what we already have + < braunr> i still have maksym's work on last year gsoc on my list + < braunr> waiting to push in the various libpager related patches first + < teythoon> so you guys think it's worthwile to port upstart? + < braunr> no idea + < braunr> teythoon: on another subject + < azeem_> teythoon: I like systemd more, but the hallway track at Debconf + seemed to imply most people like Upstart better except for the CLA + < azeem_> which I totally forgot to address + < youpi> CLA ? + < azeem_> contributor license agreement + < braunr> since you've now done very good progress, is your work available + in the form of ready-to-test debian packages ? + < teythoon> braunr: it is + < teythoon> braunr: http://teythoon.cryptobitch.de/gsoc/heap/debian/ + < braunr> i remember urls in some of your mails + < braunr> ah thanks + < braunr> "cryptobitch" hum :) + < azeem_> in any case, everbody assumed either Upstart or Systemd are way + ahead of systemvinit + < braunr> sysvinit is really ancient :) + < azeem_> apart from the non-event-driven fundamental issue, a lot of + people critized that the failure rate at writing correct init-scripts + appears to be too high + < azeem_> one of the questions brought up was whether it makes sense to + continue to ship/support systemvinit once a switch is made to + systemd/upstart for the Linux archs + < azeem_> systemvinit scripts might bitrot + < azeem_> but anyway, I don't see a switch happen anytime soon + < teythoon> well, did upstart gain the capability of disabling a service + yet? + < azeem_> teythoon: no idea, but apparently: + http://askubuntu.com/questions/19320/recommended-way-to-enable-disable-services/20347#20347 + < teythoon> azeem_: then there is hope yet ;) + < azeem_> the main selling point of Upstart is that it shipped in several + LTS releases and is proven technology (and honestly, I don't read a lot + of complaints online about it) + < azeem_> (I don't agree that SystemD is unproven, but that is what the + Upstart guys implied) + < teythoon> am I the only one that thinks that upstart is rather + unimpressive? + * azeem_ doesn't have an opinion on it + < azeem> teythoon: + http://penta.debconf.org/dc13_schedule/events/1027.en.html has slides and + the video + < azeem> teythoon: eh, appears the link to the slides is broken, but they + are here: + http://people.canonical.com/~jhunt/presentations/debconf13/upstart-debconf-2013.pdf + < braunr> teythoon: actually, from the presentation, i'd tend to like + upstart + < braunr> dependency, parallelism and even runlevel compatibility flows + naturally from the event based model + < braunr> sysv compatibility is a great feature + < braunr> it does look simple + < braunr> i admit it's "unimpressive" but do we want an overkill init + system ? + < braunr> teythoon: what makes you not like it ? + < azeem> Lennart critized that upstart doesn't generate events, just + listens to them + < azeem> (which is a feature, not a bug to some) + < braunr> azeem: ah yes, that could be a lack + < azeem> braunr: http://penta.debconf.org/dc13_schedule/events/983.en.html + was the corresponding SystemD talk by Lennart, though he hasn't posted + slides yet I think + < teythoon> braunr: well, last time I used it it was impossible to cleanly + disable a service + < teythoon> also ubuntu makes such big claims about software they develop, + and when you read up on them it turns out that most of the advertised + functionality will be implemented in the near future + < teythoon> then they ship software as early as possible only to say later + that is has proven itself for so many years + < teythoon> and tbh I hate to be the one that helped port upstart to hurd + (and maybe kfreebsd as a byproduct) and later debian choses upstart over + systemd b/c it is available for all debian kernels + < kilobug> teythoon: ubuntu has a tendency to ship software too early when + it's not fully mature/stable, but that doesn't say anything about the + software itself + < pinotree> teythoon: note the same is sometimes done on fedora for young + technologies (eg systemd) + < azeem> teythoon: heh, fair enough + < p2-mate> braunr: I would prefer if my init doesn't use ptrace :P + < teythoon> p2-mate: does upstart use ptrace? + < p2-mate> teythoon: yes + < teythoon> well, then I guess there won't be an upstart for Hurd for some + time, no? + < kilobug> p2-mate: why does it use ptrace for ? + < p2-mate> kilobug: to find out if a daemon forked + < kilobug> hum I see + < azeem> p2-mate: the question is whether there's a Hurdish way to + accomplish the same + < p2-mate> + http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/view/head:/init/job_process.c + < p2-mate> see job_process_trace_new :) + < kilobug> azeem: it doesn't seem too complicated to me to have a way to + get proc notify upstart of forks + < p2-mate> azeem: that's a good question. there is a linuxish way to do + that using cgroups + < azeem> right, there's a blueprint suggesting cgroups for Upstart here: + https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-overcome-ptrace-limitations + < teythoon> yes, someone should create a init system that uses cgroups for + tracking child processes >,< + < teythoon> kilobug: not sure it is that easy. who enforces that proc_child + is used for a new process? isn't it possible to just create a new mach + task that has no ties to the parent process? + < teythoon> azeem: what do you mean by "upstart does not generate events"? + there are "emits X" lines in upstart service descrpitions, surely that + generates event X? + < azeem> I think the critique is that this (and those upstart-foo-bridges) + are bolted on, while SystemD just takes over your systems and "knows" + about them first-hand + < azeem> but as I said, I'm not the expert on this + < teythoon> uh, in order to install upstart one has to remove sysvinit + ("yes i am sure...") and it fails to bring up the network on booting the + machine + < teythoon> also, both systemd and upstart depend on dbus, so no cookie for + us unless that is fixed first, right? + < pinotree> true + < teythoon> well, what do you want me to do for the next four weeks? + < youpi> ideally you could make both upstart and systemd work on hurd-i"86 + < pinotree> both in 4 weeks? + < youpi> so hurd-i386 doesn't become the nasty guy that makes people tend + for one or the other + < youpi> I said "ideally" + < youpi> I don't really have any idea how much work is required by either + of the two + < youpi> I'd tend to think the important thing to implement is something + similar to control groups, so both upstart (which is supposed to use them + someday) and systemd can be happy about it + < teythoon> looks like upstarts functionality depending on ptrace is not + required, but can be enabled on a per service base + < teythoon> so a upstart port that just lacks this might be possible + < teythoon> youpi: the main feature of cgroups is that a process cannot + escape its group, no? i'm not sure how this could be implemented atop of + mach in a secure and robust way + < teythoon> b/c any process can just create mach tasks + < youpi> maybe we need to add a feature in mach itself, yes + < teythoon> ok, implementing cgroups sounds fun, I could do that + < youpi> azeem: are you ok with that direction? + < azeem> well, in general yes; however, AIUI, cgroups is being redesigned + upstream, no? + < youpi> that's why I said "something like cgroups" + < azeem> ah, ok + < youpi> we can do something simple enough to avoid design quesetions, and + that would still be enough for upstart & systemd + < azeem> + (http://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign) + btw + < braunr> p2-mate: upstart uses ptrace ? + < p2-mate> yes + < youpi> teythoon: and making a real survey of what needs to be fixed for + upstart & systemd + < p2-mate> see my link posted earlier + < braunr> ah already answered + < braunr> grmbl + < braunr> it's a simple alternative to cgroups though + < braunr> teythoon: dbus isn't a proble + < braunr> problem + < braunr> it's not that hard to fix + < youpi> well, it hasn't been fixed for a long time now :) + < braunr> we're being slow, that's all + < braunr> and interested by other things + < gg0> 12:58 < teythoon> btw, who is this heroxbd fellow and why has he + suddenly taken interest in so many debian gsoc projects? + < gg0> http://lists.debian.org/debian-hurd/2013/05/msg00133.html + < gg0> i notice nobody mentioned openrc + < pinotree> he's the debian student working on integrating openrc + < gg0> pinotree: no, the student is Bill Wang, Benda as he says is a + co-mentor + https://wiki.debian.org/SummerOfCode2013/Projects#OpenRC_init_system_in_Debian + < pinotree> whatever, it's still the openrc gsoc + < azeem> well, they wanted to look at it WRT the Hurd, did they follow-up + on this? + < gg0> btw wouldn't having openrc on hurd be interesting too? + < pinotree> imho not really + < gg0> no idea whether Bill is also trying to figure out what to do, + probably not + < azeem> somebody could ping that thread you mentioned above to see whether + they looked at the Hurd and/or need help/advice + < gg0> azeem: yeah somebody who could provide such help/advice. like.. you? + for instance + * gg0 can just paste urls + < azeem> they should just follow-up on-list + + +## IRC, freenode, #hurd, 2013-08-28 + + anyone knows a user of cgroups that is not systemd? so far I + found libcg, that looks like a promising first target to port first, + though not surprisingly it is also somewhat linux specific + teythoon: OpenRC optionally uses cgroups IIRC. + Not mandatory because unlike systemd it actually tries (at all) + to be portable. + + +## IRC, freenode, #hurd, 2013-09-02 + + braunr: I plan to patch gnumach so that the mach tasks keep a + reference to the task that created them and to make that information + available + braunr: is such a change acceptable? + teythoon: what for ? + braunr: well, the parent relation is currently only implemented + in the Hurd, but w/o this information tracked by the kernel I don't see + how I can prevent malicious/misbehaving applications to break out of + cgroups + also I think this will enable us to fix the issue with tracking + which tasks belong to which subhurd in the long term + ah cgroups + yes cgroups should partly be implemented in the kernel ... + teythoon: that doesn't surprise me + i mean, i think it's ok + the kernel should implement tasks and threads as closely as the + hurd (or a unix-like system) needs it + braunr: ok, cool + braunr: I made some rather small and straight forward changes to + gnumach, but it isn't doing what I thought it would do :/ + braunr: http://paste.debian.net/33717/ + you added a field to task_basic_info + thereby breaking the ABI + braunr: my small test program says: my task port is 1(pid 13) + created by task -527895648; my parent task is 31(pid 1) + braunr: no, it is not. I appended a field and these structures + are designed to be extendable + hm + ok + although i'm not so sure + there are macros defining the info size, depending on what you ask + you may as well get garbage + have you checked that ? + i initialized my struct to zero before calling mach + teythoon: can you put some hardcoded value, just to make sure data + is correctly exported ? + braunr: right, good idea + braunr: my task port is 1(pid 13) created by task 3; my parent + task is 31(pid 1) -- so yes, hardcoding 3 works + ok + braunr: also I gathered evidence that the convert_task_to_port + thing works, b/c first I did not have the task_reference call just before + that so the reference count was lowered (convert... consumes a reference) + and the parent task was destroyed + braunr: I must admit I'm a little lost. I tried to return a + reference to task rather than task->parent_task, but that didn't work + either + braunr: I feel like I'm missing something here + maybe I should get aquainted with the kernel debugger + err, the kernel debugger is not accepting any symbol names, even + though the binary is not stripped o_O + err, neither the kdb nor gdb attached to qemu translates + addresses to symbols, gdb at least translates symbols to addresses when + setting break points + how did anyone ever debug a kernel problem under these + conditions? + teythoon: i'll have a look at it when i have some time + + +## IRC, freenode, #hurd, 2013-09-03 + + :/ I believe the startup_notify interface is ill designed... an + translator can defer the system shutdown indefinitely + it can + that's bad + yes + the hurd has a general tendency to trust its "no mutual trust + required" principle + to rely on it a bit too much + well, at least it's a privileged operation to request this kind + of notification, no? + why ? + teythoon: it normally is used mostly by privileged servers + but i don't think there is any check on the recipient + braunr: b/c getting the port to /hurd/init is done via + proc_getmsgport + teythoon: ? + braunr: well, in order to get the notifications one needs the + msgport of /hurd/init and getting that requires root privileges + teythoon: oh ok then + teythoon: what's bad with it then ? + braunr: even if those translators are somewhat trusted, they can + (and do) contain bugs and stall the shutdown + I think this even happened to me once, I think it was the pfinet + translator + teythoon: how do you want it to behave instead ? + braunr: well, /hurd/init notifies the processes sequentially, + that seems suboptimal, better to send async notifications to all of them + and then to collect all the answers + braunr: if one fails to answer within a rather large time frame + (say 5 minutes) shutdown anyway + i agree with async notifications but + i don't agree with the timeout + for reference, a (voluntary) timeout of 1 minute is hardcoded in + /hurd/init + the timeout should be a parameter + it's common on large machines to have looong shutdown delays + of the notification? + the answer means "ok i'm done you can shutdown" + well this can take long + most often, administrators simply prefer to trust their program is + ok and won't take longer than it needs to, even if it's long + and not answering at all causes the shutdown / reboot to fail + making the system hang + i know + in a state where it is not easily reached if you do not have + access to it + but since it only concerns essential servers, it should befine + essential servers are expected to behave well + it concerns servers that have requested a shutdown notification + ok so no essential but system servers + essential servers are only exec, proc, / + yes + the same applies + init and auth too, no? + yes + you expect root not to hang himself + I do expect all software to contain bugs + yes but you also expect them to provide a minimum level of + reliability + otherwise you can just throw it all away + no, not really + well + I know, that's my dilemma basically ;) + if you don't trust your file system, you make frequent backups + if you don't trust your shutdown code, you're ready to pull the + plug manually + (or set a watchdog or whatever) + what i mean is + we should NEVER interfere with a program that is actually doing + its job just because it seems too long + timeouts are almost never the best solution + they're used only when necessary + e.g. across networks + it's much much much worse to interrupt a proper shutdown process + because it "seems too long" than just trust it behaves well 99999%%%% of + the time + in particular because this case deals with proper data flushing, + which is an extremely important use case + it's hard/theoretically impossible to distinguish between taking + long and doing nothing + it's impossible + agreed + => trust + if you don't trust, you run real time stuff + and you don't flush data on disk + ^^ + (which makes a lot of computer uses impossible as well) + there are only 2 people I trust, and the other one is not + /hurd/pfinet + if this shutdown procedure is confined to the TCB, it's fine to + trust it goes well + tcb? + trusted computing base + http://en.wikipedia.org/wiki/Trusted_computing_base + * teythoon shudders + "trust" is used way to much these days + and I do not like the linux 2.0 ip stack to be part of our TCB + basically, on a multiserver system like the hurd, the tcb is every + server on the path to getting a service done from a client + then make it not request to be notified + or make two classes of notifications + because unprivileged file systems should be notified too + indeed + by the way, we should have a hurdish libnotify or something for + this kind of notifications + but in any case, it should really be policy + we should ... :) + ^^ + + +## IRC, freenode, #hurd, 2013-09-04 + + braunr: btw, I now believe that no server that requested + shutdown notifications can stall the shutdown for more than 1 minute + *unless* its message queue is full + so any fs should better sync within that timeframe + where is this 1 min defined ? + init/init.c search for 60000 + ew + did I just find the fs corruption bug everyone was looking for? + no + what corruption bug ? + not sure, I thought there was still some issues left with + unclean filesystems every now and then + *causing + yes but we know the reasons + ah + involving some of the funniest names i've seen in computer + terminology : + writeback causing "message floods", which in turn create "thread + storms" in the servers receiving them + ^^ it's usually the other way around, storms causing floods >,, + teythoon: :) + let's say it's a bottom-up approach + then the fix is easy, compile mach with -DMIGRATING_THREADS :) + teythoon: what ? + well, that would solve the flood/storm issue, no? + no + the real solution is proper throttling + which can stem from synchronous rpc (which is the real property we + want from migrating threads) + but the mach writeback interface is async + :p + + +## IRC, freenode, #hurd, 2013-09-05 + + teythoon: oh right, forgot about your port issue + don't worry, I figured by now that this must be a pointer + and I'm probably missing some magic that transforms this into a + name for the receiver + (though I "found" this function by looking at the mig + transformation for ports) + i was wondering why you called the convert function manually + instead of simply returning the task + and let mig do the magic + b/c then I would have to add another ipc call, no? + let me see the basic info call again + my problem with this code is that it doesn't take into account the + ipc space of the current task + which means you probably really return the ipc port + the internal kernel address of the struct + indeed, ipc_port_t convert_task_to_port(task) + i'd personally make a new rpc instead of adding it to basic info + basic info doesn't create rights + what you want to achieve does + you may want to make it a special port + i.e. a port created at task creation time + y? + it also means you need to handle task destruction and reparent + yes, I thought about that + see + http://www.gnu.org/software/hurd/gnumach-doc/Task-Special-Ports.html#Task-Special-Ports + for now you may simply turn the right into a dead name when the + parent dies + although adding a call and letting mig do it is simpler + mig handles reference counting, users just need to task_deallocate + once done + o_O mig does reference counting of port rights? + mig/mach_msg + is there anything it *doesn't* do? + i told you, it's a very complicated messaging interface + coffee ? + fast ? + ^^ + mig knows about copy_send/move_send/etc... + so even if it doesn't do reference counting explicitely, it does + take care of that + true + in addition, the magic conversions are intended to both translate + names into actual structs, and add a temporary reference at the same time + teythoon: everything clear now ? :) + braunr: no, especially not why you suggested to create a special + port. but this will have to wait for tomorrow ;) + + +## IRC, OFTC, #debian-hurd, 2013-09-06 + + teythoon: hi there + so I've been following your blog entries about cgroups on + hurd... very impressive :) + but I think there's a misunderstanding about upstart and + cgroups... your "conjecture" in + https://teythoon.cryptobitch.de/posts/what-will-i-do-next-cgroupfs-o/ is + incorrect + cgroups does not give us the interfaces that upstart uses to + define service readiness; adding support for cgroups is interesting to + upstart for purposes of resource partitioning, but there's no way to + replace ptrace with cgroups for what we're doing + vorlon: hi and thanks for the fish :) + vorlon: what is it exactly that upstart is doing with ptrace + then? + .,oO( your nick makes me suspicious for some reason... ;) + service readiness, what does that mean exactly? + teythoon: so upstart uses ptrace primarily for determining service + readiness. The idea is that traditionally, you know an init script is + "done" when it returns control to the parent process, which happens when + the service process has backgrounded/daemonized; this happens when the + parent process exits + in practice, however, many daemons do this badly + so upstart tries to compensate, by not just detecting that the + parent process has exited, but that the subprocess has exited + (for the case where the upstart job declares 'expect daemon') + cgroups, TTBOMK, will let you ask "what processes are part of this + group" and possibly even "what process is the leader for this group", but + doesn't really give you a way to detect "the lead process for this group + has changed twice" + now, it's *better* in an upstart/systemd world for services to + *not* daemonize and instead stay running in the foreground, but then + there's the question of how you know the service is "ready" before moving + on to starting other services that depend on it + systemd's answer to this is socket-based activation, which we + don't really endorse for upstart for a variety of reasons + hm, okay + so upstart does this only if expect daemon is declared in the + service description? + (in part because I've seen security issues when playing with the + systemd implementation on Fedora, which Lennart assures me are + corner-cases specific to cups, but I haven't had a chance to test yet + whether he's right) + and it is not used to track children, but only to observe the + daemonizing process? + yes + and it then detaches from the processes? + yes + once it knows the service is "ready", upstart doesn't care about + tracking it; it'll receive SIGCHLD when the lead process dies, and that's + all it needs to know + ok, so I misunderstood the purpose of the ptracing, thanks for + clarifying this + my pleasure :) + I realize that doesn't really help with the problem of hurd not + having ptrace + no, but thanks anyway + fwiw, the alternative upstart recommends for detecting service + readiness is for the process to raise SIGSTOP when it's ready + doesn't require ptracing, doesn't require socket-based activation + definitions; does require the service to run in a different mode than + usual where it will raise the signal at the correct time + right, but that requires patching it, same as the socket + activation stuff of systemd + (this is upstart's 'expect stop') + yes + though at DebConf, there were some evil ideas floating around + about doing this with an LD_PRELOAD or similar ;) + (overriding 'daemonize') + er, 'daemon()' + ^^ + and hey, what's suspicious about my /nick? vorlons are always + trustworthy + ;) + sure they are + but could this functionality be reasonably #ifdef'ed out for a + proof of concept port? + hmm, you would need to implement some kind of replacement... if + you added cgroups support to upstart as an alternative + that could work + i.e., you would need upstart to know when the service has exited; + if you aren't using ptrace, you don't know the "lead pid" to watch for, + so you need some other mechanism --> cgroups + and even then, what do you do for a service like openssh, which + explicitly wants to leave child processes behind when it restarts? + right... + oh, I was hoping you knew the answer to this question ;) Since + AFAICS, openssh has no native support for cgroups + >,< I don't, but I'll think about what you've said... gotta go, + catch what's left of the summer ;) + fwiw I consider fork/exec/the whole daemonizing stuff fubar... + see you around :) + later :) + + +## IRC, OFTC, #debian-hurd, 2013-09-07 + + vorlon: I thought about upstarts use of ptrace for observing the + daemonizing process and getting hold of the child + vorlon: what if cgroup(f)s would guarantee that the order of + processes listed in x/tasks is the same they were added in? + vorlon: that way, the first process in the list would be the + daemonized child after the original process died, no? + teythoon: that doesn't tell you how many times the "lead" process + has changed, however + you need synchronous notifications of the forks in order to know + that, which currently we only get via ptrace + + +## IRC, OFTC, #debian-hurd, 2013-09-08 + + vorlon: ok, but why do the notifications have to be synchronous? + does that imply that the processes need to be stopped until upstart does + something? + teythoon: well, s/synchronous/reliable/ + you're right that it doesn't need to be synchronous; but it can't + just be upstart polling the status of the cgroup + because processes may have come and gone in the meantime + vorlon: ok, cool, b/c the notifications of process changes I'm + hoping to introduce into the proc server for my cgroupfs do carry exactly + this kind of information + cool + are you discussing an API for this with the Linux cgroups + maintainers? + otoh it would be somewhat "interesting" to get upstart to use + this b/c of the way the mach message handling is usually implemented + :) + no, I meant in order for me to be able to implement cgroupfs I + had to create these kind of notifications, it's not an addition to the + cgroups api + is upstart multithreaded? + no + threads are evil ;) + ^^ I mostly agree + it uses a very nice event loop, leveraging signalfd among other + things + uh oh, signalfd sounds rather Linuxish + it is + I think xnox mentioned when he was investigating it that kfreebsd + now also supports it + but yeah, AFAIK it's not POSIX + it isn't, yes + but it darn well should be + :) + it's the best improvement to signal handling in a long time + systemd also uses signalfd + umm, it seems I was wrong about Hurd not having ptrace, the wiki + suggests that we do have it + FSVO "have" + ^^ + vorlon: teythoon: so ok kFreeBSD/FreeBSD ideally I'd be using + EVFILT_PROC from kevent which allows to receive events & track: exit, + fork, exec, track (follow across fork) + upstart also uses waitid() + so a ptrace/waitid should be sufficient to track processes, if Hurd + has them. + + +## IRC, freenode, #hurd, 2013-09-09 + + teythoon: yes, the shutdown notifications do stall the process + but no more than a minute, or so + teythoon: btw, did you end up understanding the odd thing in + fshelp_start_translator_long? + I haven't had the time to have a look + youpi: what odd thing? the thing about being implemented by hand + instead of using the mig stub? + the thing about the port being passed twice + XXX this looks wrong to me, please have a look + in the mach_port_request_notification call + ah, that was alright, yes + ok + so I can drop it from my TODO :) + this is done on the control port so that a translator is + notified if the "parent" translator dies + was that in fshelp_start_translator_long though? I thought that + was somewhere else + that's what the patch file says + +++ b/libfshelp/start-translator-long.c + @@ -293,6 +293,7 @@ fshelp_start_translator_long (fshelp_open_fn_t + underlying_open_fn, + + /* XXX this looks wrong to me, bootstrap is used twice as + argument... */ + bootstrap, + MACH_NOTIFY_NO_SENDERS, 0, + right + I remember that when I got a better grip of the idea of + notifications I figured that this was indeed okay + I'll have a quick look though + ok + ah, I remember, this notifies the parent translator if the child + dies, right + and it is a NO_SENDERS notification, so it is perfectly valid to + use the same port twice, as we only hold a receive right + + +## IRC, freenode, #hurd, 2013-09-10 + + braunr: are pthreads mapped 1:1 to mach threads? + teythoon: yes + I'm reading the Linux cgroups "documentation" and it talks about + tasks (Linux threads) and thread group IDs (Linux processes) and I'm + wondering how to map this accurately onto Hurd concepts... + apparently on Linux there are PIDs/TIDs that can be used more or + less interchangeably from userspace applications + the Linux kernel however knows only PIDs, and each thread has + its own, and those threads belonging to the same (userspace) PID have the + same thread group id + aiui on Mach threads belong to a Mach task, and there is no + global unique identifier exposed for threads, right? + braunr: ^ + teythoon: There is its thread port, which in combination with + its task port should make it unique? (I might be missing context.) + Eh, no. The task port's name will only locally be unique. + * tschwinge confused himself. + tschwinge, braunr: well, the proc server could of course create + TIDs for threads the same way it creates PIDs for tasks, but that should + probably wait until this is really needed + for the most part, the tasks and cgroup.procs files contain the + same information on Linux, and not differentiating between the two just + means that cgroupfs is not able to put threads into cgroups, just + processes + that might be enough for now + + +## IRC, freenode, #hurd, 2013-09-11 + + ugh, some of the half-backed Linux interfaces will be a real + pain in the ass to support + they do stuff like write(2)ing file descriptors encoded as + decimal numbers for notifications :-/ + teythoon: for cgroup ? + braunr: yes, they have this eventfd based notification mechanism + braunr: but I fear that this is a more general problem + do we need eventfd ? + I mean passing FDs around is okay, we can do this just fine with + ports too, but encoding numbers as an ascii string and passing that + around is just not a nice interface + so what ? + it's not a designed interface, it's one people came up with b/c + it was easy to implement + if it's meant for compatibility, that's ok + how would you implement this then? as a special case in the + write(2) implementation in the libc? that sounds horrible but I do hardly + see another way + ok, some more context: the cgroup documentation says + write " " to cgroup.event_control. + where event_fd is the eventfd the notification should be sent to + theorically they could have used sendmsg + a custom payload + control_fd is an fd to the pseudo file one wants notifications + for + yes, they could have, that would have been nicer to implement + but this... + + +## IRC, freenode, #hurd, 2013-09-12 + + ugh, gnumachs build system drives me crazy %-/ + oh there's worse than that + I added a new .defs file, did as Makerules.mig.am told me to do, + but it still does not create the stubs I need + teythoon: gnumach doesn't + teythoon: glibc does + well, gnumach only creates the stubs it needs + teythoon: you should perhaps simply use gnumach.defs + braunr: sure it does, e.g. vm/memory_object_default.user.c + teythoon: what are you trying to add ? + braunr: I was trying to add a notification mechanism for new + tasks + b/c now the proc server has to query all task ports to discover + newly created tasks, this seems wasteful + also if the proc server could be notified on task creation, the + parent task is still around, so the notification can carry a reference to + it + that way gnumach wouldn't have to track the relationship, which + would create all kind of interesting questions, like whether tasks would + have to be reparented if the parent dies + teythoon: notifications aren't that simple either + y not? + 1/ who is permitted to receive them + 2/ should we contain them to hurd systems ? (e.g. should a subhurd + receive notifications concerning tasks in other hurd systems ?) + that's easy imho. 1/ a single process that has a host_priv + handle is able to register for the notifications once + what are the requirements so cgroups work as expected concerning + tasks ? + teythoon: a single ? + i.e. the first proc server that starts + then how will subhurd proc servers work ? + 2/ subhurds get the notifications from the first proc server, + and only those that are "for them" + ok + i tend to agree + this removes the ability to debug the main hurd from a subhurd + this way the subhurds proc server doesn't even have to have the + host_priv porsts + yes, but I see that as a feature tbh + me too + and we can still debug the subhurd from the main + it still works the other way around, so it's still... + yes + what would you include in the notification ? + a reference to the new task (proc needs that anyway) adn one to + the parent task (so proc knows what the parent process is and/or for + which subhurd it is) + ok + 17:21 < braunr> what are the requirements so cgroups work as + expected concerning tasks ? + IOW, why is the parental relation needed ? + (i don't know much about the details of cgroup) + well, currently we rely on proc_child to build this relation + but any task can use task_create w/o proc_child + until one claims a newly created task with proc_child, its + parent is pid 1 + that's about the hurd + i'm rather asking about cgroups + ah + the child process has to end up in the same cgroup as the parent + does a cgroup include its own pid namespace ? + not quite sure what you mean, but I'd say no + do you mean pid namespace as in the Linux sense of that phrase? + cgroups group processes(threads) into groups + on Linux, you can then attach controllers to that, so that + e.g. scheduling decisions or resource restrictions can be applied to + groups + braunr: http://paste.debian.net/38950/ + teythoon: ok so a cgroup is merely a group of processes supervised + by a controller + for resource accounting/scheudling + teythoon: where does dev_pager.c do the same ? + braunr: yes. w/o such controllers cgroups can still be used for + subprocess tracking + braunr: well, dev_pager.c uses mig generated stubs from + memory_object_reply.defs + ah memory_object_reply ok + teythoon: have you tried adding it to EXTRA_DIST ? + although i don't expect it will change much + teythoon: hum, you're not actually creating client stubs + create a kern/task_notify.cli file + as it's done with device/memory_object_reply.cli + see #define KERNEL_USER 1 + braunr: right, thanks :) + + +## IRC, freenode, #hurd, 2013-09-13 + + hm, my notification system for newly created tasks kinda works + as in I get notified when a new task is created + but the ports for the new task and the parent that are carried + in the notification are both MACH_PORT_DEAD + do I have to add a reference manually before sending it? + that would make sense, the mig magic transformation function for + task_t consumes a reference iirc + ah yes + that reference counting stuff is some hell + braunr: ah, there's more though, the mig transformations are + only done in the server stub, not in the client, so I still have to + convert_task_to_port myself afaics + awesome, it works :) + :) + ugh, the proc_child stuff is embedded deep into libc and signal + handling stuff... + "improving" the child_proc stuff with my shiny new notifications + wrecks havoc on the system + + +## IRC, freenode, #hurd, 2014-01-03 + + openrc on debian + https://buildd.debian.org/status/package.php?p=openrc&suite=experimental + gg0: ah nice + + +## IRC, freenode, #hurd, 2014-01-11 + + teythoon: is the Hurd boot now fully init compatible? I would + like to try to boot with a ported openrc in a sandbox kvm:P + + +### IRC, freenode, #hurd, 2014-01-12 + + gnu_srs1: yes, go ahead + gnu_srs1: you'll have to switch to sysvinit first + for that, you need patched sysvinit packages + + teythoon: do you mean the parches in #721917? + gnu_srs: yes, mostly, but there is one final patch missing + uploading patched sysvinit to debian-ports? (or braunr's or + teythoon's repos) + gg0, gnu_srs: they are actually here + http://teythoon.cryptobitch.de/gsoc/heap/debian/ but outdated + teythoon: if the sysvinit patches are outdated, can you update + them please? and provide a package for upload to -ports (as gg0 proposed) + gnu_srs: i will + tks:) + + +### IRC, freenode, #hurd, 2014-01-13 + + gnu_srs: i updated the sysvinit patches + gnu_srs: for your convenience, here are packages: + http://darnassus.sceen.net/~teythoon/heap/sysvinit/ + gnu_srs: you have to install the sysvinit-core package first, + then the others + to switch to sysvinit, do update-alternatives --config runsystem + and select runsystem.sysv + then, do reboot-hurd and hope for the best ;) + + teythoon: thanks, will try soon. Are you submitting the updated + patches to #721917 too? + gnu_srs: i already did + good;-) + teythoon: rebooted with sysv:http://paste.debian.net/75925/ + gnu_srs: please, whenever you run into a problem, give more + context + which file are you talking about ? + also, as the postinst script advised you, you need to use + {halt,reboot}-hurd *whenever* you switch the runsystem + not doing so wont do any harm, but it wont work + shutdown: /run/initctl: No such file or directory <-- that's + what happens if you run reboot (=reboot-sysv) w/o sysvinit being run + if you don't get a getty on the console, check /etc/inittab + I did note see a message from any posinst script about + {halt,reboot}-hurd, only LC* related messages + A I missed it: You must use halt-hurd or reboot-hurd to halt or + reboot the + system whenever you change the runsystem. + I don't see anything suspicious in /etc/inittab, + eg. 1:2345:respawn:/sbin/getty 38400 tty1 is there + 7:2345:respawn:/sbin/getty 38400 console + then, you'll get a getty on the mach console, even if the + hurd-console does not start + teythoon: with 7:2345:respawn:/sbin/getty 38400 console in + /etc/inittab I get a (mach) console. + never seen that mentioned anywhere + anyway, the image is now booted with sysvinit. next to try will + be openrc:P + gnu_srs: you haven't heard of the inittab entry for the mach + console before b/c the inittab was not used before on the hurd + i should probably write that down in the wiki somewhere... + shouldn't the upgrade of the sysvinit package do it too? + (does it at least install a correct version on newer installs?) + it probably should / i'm not sure + + +## IRC, freenode, #hurd, 2014-01-13 + + gnu_srs: have you ported openrc already ? + I made it build (with temporary workarounds for PATH_MAX) but + need to change at least one file to be hurd-specific before trying to + boot + cool :) + i guess not much different from http://paste.debian.net/plain/75893/ + (i didn't say it sucks but one can find it out by taking a look) + gg0: Have you talked to zigo in #openrc?. He has partial patches + (submitted to the debian repo), you do and me too. + Maybe we should align our work. + The file to make Hurd-specific is: init.sh.GNU (you start with + copy of the Linux version, I start from a copy of the BSD version). + BTW: I don't think fstabinfo is available for GNU/Hurd! + gg0: Sorry, fstabinfo and moutinfo are parts of openrc, my bad:-D + mountinfo* + + +## IRC, freenode, #hurd, 2014-01-15 + + Hi, is these some simple way to find out the sequence of commands + executed during boot: + current using runsystem.gnu and with sysv-rc using runsystem.sysv + I need to edit on file of OpenRC before trying to boot with + it. (mainly mounting /run/*) + Is mount functional or is settrans .needed? + + +## IRC, freenode, #hurd, 2014-01-16 + + gnu_srs: you are adding OpenRC? cool! + ArneBab: Working on it, will try booting when my questions here + have been answered ;-) + gnu_srs: mount is functional enough to boot Debian/Hurd using + sysvinit + gnu_srs: you could add "set -x" to runsystem.*, or add "bash" to + just drop into a shell and examine the environment interactively + teythoon: Hi, is mount a wrapper on top of settrans ...? + yes + how to log the boot sequence, when booting the mach console is + cleared when the hurd console starts? + you could just disable the hurd console + and the kvm console does not have scrolling functionality + it's actually the mach console that lacks this + copying manually is cumbersome, even if all is readable + but as a workaround you can use kvm .... -curses and use xterms + backlog + and c&p works then :) + tks, I'll try with that:P + + +## IRC, freenode, #hurd, 2014-01-17 + + BTW: zigo successfully booted openrc on Hurd, I haven't tried + yet,, you know things coming in between. He used my patches to create + updated ones:) + that version is now in experimental (I still have to operate away + all those PATH_MAX issues, and fins at least one sh file). + :/ + + +## IRC, freenode, #hurd, 2014-01-21 + + teythoon: I don't get a scrollable output when using -curses in + kvm, to be able to see all startup messages. Any other ideas? + gnu_srs: are you sure ? i just tested this, and it works nicely + for me + gnu_srs: that's how i created all the "screenshots" for my blog + posts + teythoon: kvm -m 1024 -net nic,model=rtl8139 -net + user,hostfwd=tcp::5564-:22 -curses -hda debian-hurd-20140115.img + ah, my bad + gnu_srs: try -nographic + oh, and maybe you need to add console=com0 to the gnumach + command line + b/c with -nographic, the first serial port is connected to qemus + stdio + sorry, i mixed this up + and how to add console=com0 to the qemu start oprtions? -kernel + and -append are Linux only + # grep console /etc/default/grub + GRUB_CMDLINE_GNUMACH="console=com0 --crash-debug" + and if you want grub on the serial port: + # grep serial /etc/default/grub + GRUB_TERMINAL=serial + GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8 + --parity=no --stop=1" + teythoon: with -nographic I don't get any output at all? + did you run update-grub ? + aha, will do + still no scrollbar with gnome-terminal, will try with xterm and + rxvt + it works: with rxvt, tks:-D + good :) + i found -nographic to be quite handy + in /etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT="quiet" and + GRUB_CMDLINE_LINUX="" #GRUB_DISABLE_LINUX_UUID=true + linux configuration parameters in a gnumach boot setup? + those won't be used + unless the grub scripts find a linux kernel in /boot + it's just the stock debian configuration file + nevertheless:-( + what ? + there could be OS-specific files: Linux, kFreeBSD, Hurd? + or, preferebly, one that works on every os ? like it is now ;) + OK, one that works on every OS, with a common part and + OS-specific parts? + that's how it is now + stuff with LINUX in it is used for linux + stuff with GNUMACH in it is used for gnumach + + +## IRC, freenode, #hurd, 2014-01-22 + + teythoon: A boot message segfault: (syv-rc specific?) + + exec /sbin/init -a + INIT: version 2.88 booting + Using makefile-style concurrent boot in runlevel S. + end_request: I/O error, dev 02:00, sector 0 + Segmentation fault + Activating swap...done. + Checking root file system...fsck from util-linux 2.20.1 + another: mount: cannot remount /proc: Invalid argument + ... + df: Warning: cannot read table of mounted file systems: No such + file or directory + openrc boots on Hurd, login (user,root) works, read-only mode so + far, have to tweak some scripts:) + not bad + gnu_srs: woah! + very cool! + + +## IRC, freenode, #hurd, 2014-01-22 + + I think with that you are doing the most useful thing to avoid + OpenRC: If it provides almost the same as systemd and runs on the Hurd, + then there is no technical reason for using systemd, but many against it. + s/avoid OpenRC/avoid systemd/ + (gah, brain is jumbled) + I hate systemd because it monopolizes cgroups + which is SUPPOSED to be a generic interface open to anyone + I do not want an unholy alliance in a kernel-user api + ArneBab: the openrc maintainer will take care it will get + communicated + ArneBab: also, not sure what you mean about systemd, the question + isn't so much between openrc vs. systemd, but upstart vs. systemd + at least for the Technical Committee decision, none of the + tech-ctte members seems to consider openrc as n realistic contender + s/as n/as a/ + azeem_: seem like it is so:-( + maybe in a future, if openrc gets some attention and developers, + it could become a one-for-all solution;-) + gnu_srs: nice :) + ignore the proc related message + gnu_srs: there is no way to associate the segfault with a + process for me, can you shed some light on which process dies ? + as for df complaining, you could fix this up like youpi did: + grep ln /etc/hurd/rc + ln -s /proc/mounts /var/run/mtab + the proper way is to fix our libc of course + teythoon: I was just coping the boot messages, I don't know + either which process segfaults + hm, maybe you can make openrc more verbose about what it starts + All I wrote earlier was from sysv-rc + ah + i've never seen that then + azeem_: actually I think OpenRC is the only sane choice: It is + the only choice which supports other kernels. + Shentino: I can’t stand systemd, because it establishes a tight + control over the init process by encouraging developers to add + dependencies to libraries which are so tightly coupled with others, that + they cannot be adapted without affecting the whole system. + Shentino: But I wrote about that in much more details: + http://draketo.de/light/english/top-5-systemd-troubles TL;DR: + distributions become completely dependent on a small group and they throw + away the skills their maintainers already have (shell scripting) + And systemd is Linux-only… + …with no intention of changing that. + why would debian strive to support other kernels ? + instead of other kernels adjusting ? + if posix introduces new apis, are we going to say no, or are we + going to try and support them ? + the issue of multi-kernel support is completely irrelevant + what you're saying about tight coupling is actually the only real + issue of systemd + braunr: I see a difference between providing a stable API which + others can easily replicate and a running target with no intention to + become cross-kernel usable (my experience with udev suggests that they + won’t really try to keep anything stable for long). + braunr: but the tight coupling is the main issue for me, too: + that creates a vulnerability for the free software community. + no, the free software community doesn't risk much here + it's a technical problem + ok, yes, posix as a point of convergence is clearly not the same + as linux as an implementation that diverges + agreed + if the systemd people decide to go a certain direction which + makes it impossible to provide a certain feature while using their new + tech, then there is a problem. + but it still implies we have to adapt + from my point of view, multi-kernel distributions are a technical + heresy + if you want something really efficient, you want it very well + integrated + i'm concerned by the linux kernel making up interfaces w/o + proper considerations + braunr: in Gentoo we had all the hassle with /usr on a separate + partition. There are usecases for that, and Gentoo wanted to provide + them, but udev (now systemd) made that impossible. + teythoon: yes i'm concerned about that too + we will never be able to implement the cgroup interface for + example b/c it is too badly designed + badly ? + it's system specific + braunr: also the systemd folks could essentially hold Linus at + ransom: “We couple userspace tightly to implementation details in the + kernel, so when you break the implementation in a way which we don’t + like, you’ll break userspace in the worst possible way” + it's very hard to design an interface without properly + understanding what it would internally imply in the implementation + ArneBab: that's already the case + system specific in a way that it will be impossible to implement + on non-monolithic kernels + teythoon: exactly + they didn't think of that because they don't care + and why would they ? + it doesn't make the interface bad per se + it is the case in systemd, but not in sysVinit + well it is too + but sysvint is less demanding + again, the coupling is the problem + yes + systemd comes from people with other goals and interests + I think everything I wrote comes down to that. + they're very technical, very business oriented + they want to get up to speed with competitors quickly + they're not wrong in doing that + it just helps understand why they get with such results + A distribution would be foolish to let other people take over a + crucial part of the system when those other people have a track record of + coupling more and more parts of the system with their product. + and i agree, i don't want it either + but please, stop with the nonsense + don't say openrc is the only sane one because it's the only + multikernel one + personally, i consider that very argument almost insane itself + considering distributions that are hardly used can really have any + weight in the decision is absurd + openrc is the only sane one, because it keeps already aquired + skills useful. + s/distributions/kernels/ + (that’s my opinion) + we have to make progress + the init system is clearly obsolete and lacking features + so "acquired" skills here are irrelevant too + if it takes acquiring new skills to operate a better init system, + i'm all for it + after all, it makes a lot more sense to me than all those fancy + languages/technologies like C# and ruby that have gained so much + popularity in so little time + If you can get a similarly good init system wiothut forcing + people to learn new skills, that’s a big win. + you probably can't + OpenRC is pretty close in features to systemd + err + not even close + teythoon is right + openrc is just sysvinit++ + no + openrc replaces the sysv rc, not sysvinit + ok + it complements it + i wasn"'t being pedantic here + nicely in my opinion + yes i like it too + but i'm afraid it's not a complete solution + I think I need to be more pedantic in what I say: A system-boot + with OpenRC is pretty close in features to a system-boot using systemd. + on the other hand, when i see discussions about event driven + systems and handling of dependencies, it sounds like something like + openrc could do the job, and something else, system-specific, would + handle the rest + ArneBab: i disagree + me too + ArneBab: have you actually used systemd? + I have read about what it provides. + My udev experience burned me pretty badly. + udev is only one part + but actually, coupling is both a problem and a great feature + yes + it's precisely the integration of many services previously + organized in a very messy way that makes it better + and cgroups, by accurately tracking resources, allow even better + control + heh, i watched lennarts recent talk about kdbus + but it does so by pulling in more and more parts instead of + providing a clean interface which separate projects can use. + again, the coupling is too tight + it's hard to hook in between + teythoon: I watched lennart troll a talk pretty badly… + braunr: yes + he cites mach and hurd for having an nice ipc mechanism, and + linux lacking such a system + haha + i was expecting such comparisons :) + that’s why he writes an init-system which does not run on the + Hurd… + ArneBab: that's trolling on your part ;) + :) + somehow yes… + what i personally get out of this is that, in the end, proper + messaging at the kernel level is something people do want + and if you make stuff like x use it, why not things like the + network stack and the file system + i wish the linux kernel would allow the kernel devs to write + nicer interfaces + yes + they're almost in the process of acknowledging the merits of + multiserver architectures :) + b/c they lack a proper ipc mechanism, they do stuff like ad-hoc + filesystem-based interfaces that are crappy to support on the hurd :-/ + * ArneBab has been out of the loop for too long… + teythoon: what file system do you consider "crappy to support on + the hurd" ? + braunr: cgroupfs in particular + not crappy, but impossible + well, that's probably because we need realy resource containers + first + real* + no, we'll never be able to implement the current interface + i didn't study it as you did so i trust you + braunr: + http://teythoon.cryptobitch.de/posts/cgroupfs-is-as-cgroupy-as-it-gets/ + ok this would require proper support at the client side + yes + i wouldn't say impossible but definitely not as clean as we would + want it + far from it + how would you ever implement it w/o fixing the client + (i.e. fixing the interface first) ? + the client would translate the request + magical write retries ? + probably + uh + clients are the only entities which know what their file + desctiptors refer to + descriptors* + yes + so writing such a request would make the client get a magic retry, + and use the proper rpc, passing the proper rights instead + yeah, i can see how that could work + but i'm not sure that we should go down this path ... + we probably really do'nt want to :) + i'd personally be fine if debian would allow two init systems + me too + with the powerful linux-specific one still allowing sysvinit + scripts + in particular b/c the sysvinit scripts are already there + from what i've read, they all provide some decent backward + compatibility with sysvinit + yes + and i think we can count on the linux community to riot if, + assuming systemd was chosen, it becomes too hard to use and tweak + again, these people want their software to be used + so they'll probably manage something decent in the long run, + whatever is chosen + i don't care much + :) + AFAIK Debian is planning to let users chose the init system, the + discussion is only on what should be the main/default one; but I might + have misunderstood it + that was one of the possibilities, yes + maybe we could help the debate by agreeing on whether or not we + consider supporting ports is that important, as port maintainers, + considering we'll probably keep the ability to use sysvinit scripts + anyway + and making that decision known + and stating that we consider openrc an worthwile incremental + improvement, whatever debian decides to do wrt to the default init system + for example, yes + we should discuss that with youpi and thomas + tschwinge: ^ + when they have some time later :) + + +## IRC, freenode, #hurd, 2014-01-24 + + Good news, a successful boot of Hurd with OpenRC: + http://paste.debian.net/78119/ :-) + ramains to fix the false negative for checkpath -W + remains* + not bad + + teythoon: btw, the segfault happens when starting the bootlogd + service: + end_request: I/O error, dev 02:00, sector 0 + Segmentation fault + gnu_srs: nice progress :) + i've never seen bootlogd crash like that, though i + i'm not sure it is installed + how can I check / ? it is mounted RW and even if cd to /run which + is on tmpfs, fsysopts --readonly fails: + :fsysopts: /: --readonly: Device or resource busy + I don't have bootlogd installed the segfault is at: + checkroot.sh: hwclock.sh mountdevsubfs.sh hostname.sh hdparm + keyboard-setup + called by /etc/rcS.d/S06checkroot.sh + you should probably create this directory that it fails to + create early in the boot process + + +## IRC, freenode, #hurd, 2014-01-25 + + braunr: being Linux-only is *part* of the "tight coupling" + strategy of the systemd cabal + of course you could implement all the Linux-specific interfaces on + other systems; as you could implement any other interfaces relied upon or + provided by systemd components... + (this is in fact Lennart's favourit cop-out argument whenever + someone raises concern about this) + the problem however is that such alternative implementations + usually have prohibitive costs + yes i know + (and Lennart knows that perfectly well... he doesn't exactly take + pains to conceal the fact that it's a cop-out) + their whole point is to create a tightly integrated stack of + monopolistic components, giving a shit about any possible alternatives + this does have an obvious appeal: it *significantly* reduces the + cost of innovation within their stack + at the same time however it kills the traditional innovation + driver in the free software eco-system, which is competition among + interchangable components + quite frankly, it makes little sense that other distributions are + embracing systemd in droves: the tight coupling pretty much turns them + all into Fedora look-alikes, questioning the point of their very + existence... + what is dmd? + as for Debian considering fringe kernels in their decision, I + think it makes *perfect* sense: the real value of Debian is precisely the + fact that it supports so many different things, making it a good base to + build upon + (it's just unfortunate that many Debian developers do not realise + this, and instead try to compete with user-oriented distributions...) + zacts: daemon managing daemon? yet another new init system... + yeah + didn't know if you have an opinion on it vs systemd + and whether or not hurd will use it.. + hm... not sure whether I do ;-) + antrik: one could argue an init system is hard to make + interchangeable without also making it quite poor in functionality + the GNU system uses it, right? when using the GNU system with the + Hurd (as it's really meant to be), that would obviously mean using DMD + with Hurd. though I'm not sure whether anyone has actually tried that + combination ;-) + just to make it clear, i'm totally not in favor of systemd + i'm just trying to measure the value of an interchangeable init + system here + value versus cost + why is it bad to try to compete with user oriented distros ? + braunr: I suspect most of the really good things about systemd + could be kept while making it somewhat more open at fairly little cost... + braunr: because that's not Debian's strength -- and never will be + trying to compete in this space too hard is bound to fail, at only + bears the risk of loosing the actual strengths + antrik: sounds true + hm... thinking about it, I'd say it actually makes more sense for + the init system to be distribution-specific than kernel-specific... + that makes sense + but systemd isn't just an init system + it's really the distribution's job to create a well-integrated + system. and basically, that's what the systemd cabal is doing for + Fedora... + it's just problematic that they have so much influence in + important upstream projects, that they are basically killing any chance + for others to integrate things in different ways + antrik: agreed + the tight coupling i refer to is about the init system and the + upstream projects you mention such as udev, acpid, console-kit, etc.. + yeah... and GNOME + is it really that coupled now ? + don't really know; but judging from remarks people make, it must + be pretty bad + this reminds me of the talk on gnome 3 last year at fosdem + it would have been hilarious if gnome wasn't such an important + project + (specifically, GNOME is now pretty much tied to logind AIUI, which + is not entirely inseparable from systemd -- but again, the cost is + prohibitive...) + i don't get what all the hate here is about ... + in fact, certain people used that as an argument why Debian must + switch to systemd as init, as they are already pretty much forced to use + various of the other coupled components anyways, and trying to decouple + them is too costly for Debian... + teythoon: hate ? here ? + i mean they don't do this for fun, they actually provide + something of value, right ? + some value + teythoon: they? + but they remove the kind of value that made free software evolve + the way it did, as antrik said + the evil cabal around systemd ;) + I didn't say "evil"... not explicitly at least ;-) + then again, if you are runnign linux/gnome3 and plug in a second + monitor, that one is automatically activated + yes, that's what they want to achieve + that's what they achieved + i mean, they targetted that, it's not a side effect + and anyone not happy with how they did that can surely provide a + nicer solution ;) + teythoon: as I said, there are clearly good aspects to what they + are doing -- but at the same time it's very dangerous to the free + software eco-system... + teythoon: not easily + antrik: i don't buy that + i do + braunr: yes, not easily. that is kind of the point, right ? + pulling projects such as gnome into a category of kernel specific + applications is dangerous + teythoon: well, considering who they are and the means they have, + they could have spent the time to do it right for everyone + maybe + err... activating a second monitor is not in any way tied to + systemd or related compontents... I think you are talking about a second + seat + that's another killer feature they achieved, yes + (which is nice, but quite frankly, a niche use case in my book...) + maybe you're not the typical user + I'm not. but the *typical* user definitely doesn't care about + multi-seat + if you say so + antrik: when you say it's dangerous what 'they' are doing, what + do you mean exactly ? + dangerous for whom ? + asides from schools in developing countries, who try everything to + save on IT costs, I really can't think of many users for multi-seat... + (maybe schools all around the world trying to cut down their + costs?) + or like everyone, here, a $30 dongle that gives you an extra + workstation, how awesome is that ? + teythoon: see above: they are killing the ability to combine + interchangable components, which has always been a core asset of the free + software ecosystem + antrik: so gnome is going for systemd, and gnome loses the + ability to be used w/o systemd + why do you care ? how does this affect the whole ecosystem ? + i really don't get why everyone is getting so upset about this + teythoon: who cares about a dongle giving an extra workstation? + the remaining users of workstations are either corporate -- who prefer + dedicated boxes for organisational reasons -- or gamers, who want all the + power to themselves... + teythoon: well gnome is kind of one of the major destkop software + in the free software world + s/one of// + antrik: you stated that you havent used gnome3, yet you have an + opinion how tightly it should be coupled with systemd or linux + people who haven't used systemd or upstart have an opinion about + which one should be preferred + teythoon: why do you think people shouldn't think about systems as + a whole ? + teythoon: actually, I am using it (for some value of "use") -- + though in legacy mode, as my hardware can't run the new bling... + in that case, people shouldn't be allowed to vote, because that + would require them to be politicians .. + it's okay to think about that + i don't think it is + teythoon: but seriously, whether *I* have used it is quite beside + the point. I have no illusions about being a niche user + people don't need to use something to actually understand it + but i cannot stand all the whining lately in the free software + world... + whining isn't fair + i mean, the word + y ? + it's a big problem and complaining to force a debate is important + yes, but "they" are solving problems, and everyone is + complaining for one reason or the other + they are also creating problems + and not everyone is complaining + as opposed to offering alternatives + that's a major issue, a lot of people are favorable to these + changes + and if you don't like what "they" are building, you are free not + to use it, no ? that's a freedom too ;) + no + you aren't + what ? + that's precisely the point + you'll be de facto forced to use it if you want to keep using the + rest + i'm free not to use gnome3 + you won't be free from using linux if you want gnome3 + what kind of argument is that ? + i'm abusing the word freedom + because it has no clear meaning in practice + as antrik said, it's about interchangeability and portability + and alternatives + accepting the way systemd is designed is a major shift towards + making linux its own standard, away from the rest + and the way it's done isn't thought to easily allow the + alternatives to keep up with the changes + we agreed the other day that they shouldn't create ad-hoc + interfaces like they do, yes + well that's the whole point + you just talked "about the way systemd is designed" + they could invest some more effort to make well designed + interfaces that allow changing both the dependencies and the services + provided + how is that related to bad interface design ? + for me, it's almost a synonym + and we discussed it + aren't tightness of coupling and quality of interfaces + completely orthogonal ? + it is designed with a narrow set of apparently company directed + interested towards a single system, a single distribution even, and + nothing else + no + absolutely not, when it's about something that should be + interchangeable + an interface that forces tight coupling is of low quality to me + braunr: they claim it's not actually company-directed... and I + tend to believe them on *that* point TBH + antrik: this would have been a valid reason at least + teythoon: it's just not right that some people can no longer use + major pieces of free software just because a tiny but highly vocal cabal + decides to disrupt the whole ecosystem + what are you talking about ? you are free to use older versions + of the software + i's not technically feasible + or it would require forking to maintain + again, it's the start of a rift + but, if the gnome people want to go into that direction, who are + you to say that they shouldn't ?? that's what i get the least about this + kind of argument... + i'm part of the free software community + more accurately, the free unix-like community + and you are actively developing gnome... ? + if they want to get out of this community, they'll hurt it, and + themselves + do you understand what a rift is ? + but that's their choice, no ? + a major division ? + so what ? + it doesn't mean it's a good one + you pick the desktop environment you like next best and be done + with it ? + it's almost public service at this point + what if they all do the same thing ? + err + they don't + you won't be free to do what you want because the technical + possibility will have disappeared + kde might + if only to compete with gnome + well, if you don't like hte direction a project is taking, you + fork it + that's what happened + exactly .. + why the long faces ? + forks increase complexity and reduce manpower + fork == division + forking in the free software community is normally a last resort + huh ? since when is this considered a bad thing ? + it's not a bad thing per se + it usually implies a bad situation + < braunr> fork == division + and division == rift + think of these situations that were caused by stupid drama and + lead to the duplication of a lot of effort + openbsd, eglibc, jenkins, to name a few + i don't + why would i ? i never created these forks + it affects the community as a whole + but the people who did thought it was necessary + the fact they could do it is good, the fact they had to do it + isn't + they were usually forced by the situation + and often by the stupidity of other people + someone forced someone else to fork a project ? with a gun or + something like this ? + i don't buy this ;) + of course not .. + eglibc was forced by the inability of drepper to accept a whole + class of patches + openbsd because theo de raadt has some huge ego + for jenkins, it was a licensing issue iirc + nothing technical at all + nothing in the interest of the community + err + it brings diversity + no + netbsd versus freebsd brings diversity + i thought that was a good thing + openbsd was just agotistic crap + ego* + if there is no diversity, why should stuff be interchangeable if + there are no alternatives? + and netbsd and freebsd aren't exactly forks, they're both bsd + based but had different goals from the start + that's not what i'm talking about + eglibc isn't exactly a new libc + it's glibc+the stuff that should have gone into it + teythoon: the stuff the systemd cabal does builds on the work of + thousands of projects and people; yet they act as if the don't own anyone + anything, and it's fine to boot out large parts of the community whos + work they are building on + iceweasel isn't a whole new firefox + most often, alternatives aren't forks of one another + if they are, they have diverged a lot + antrik: that is your interpretation, and i respectfully disagree + with it;) + and usually have different goals + that's diversity, and i'm very ok with it + (being a hurd guy and all) + but forking because of decisions that prevent alternatives is a + very bad reason to fork + again, who are you to tell a project (say gnome) what they + should do or not ? + that question makes no sense + we're trying to think objectively + forget who we are + think about what should be done + no such thing ;) + ok well, in that case, i'm a very smart person who knows a lot of + things, and people had better do what i tell them ;p + satisfied ? :) + yes + that's much better actually + not really .. + it's more honest + no it was sarcasm + what was honest are the arguments i explained + why care about who says them ? + i do + teythoon: there is not much interpretation in there really. some + of their own statements are quite explicit... + damn non scalable kernel .. + who is "their"? what statements ? + teythoon: when building glibc, there are so many nodes to fake + that ext2fs+fakeroot allocate enough ports to starve kernel memory ... + if i were mr. gnome3 and you would tell me that i should cuddle + with systemd b/c that's bad for one reason or another, the first thing + i'd like to know is who is telling me that + teythoon: why not solely consider the argument ? + braunr: yes, i can imagine fakeroot doing that + teythoon: Lennart and his friends. not sure how much of these + statements I have seen written down -- part of it I heard myself from + their own mouths + braunr: b/c maybe i like to develop my project in the direction + i want + that's unrelated + and if anyone disagrees, she may fork + this is a debate + why ? + so now we are debating what i may develop or not ? you lost me + ;) + a way to reach consensus + many people are discussing so that projects like debian and gnome3 + make the best decisions + a naive way to explain it is that the result is the sum of what + everyone likes and how louds he speaks for it + sure but you are not a gnome developer, no ? + no, but again, i'm a free software community member + and this affects the whole community + because gnome3 is a major software component used by a lot of + people + well, gnome at least + so the gnome project needs to seek consensus with everyone of + the free software community ? + no + that would be unanimity + but wrt to the systemd integration ? + siding with systemd is starting to get away from the free software + community + or, by bringing a lot of people along, dividing it + that's your interpretation + yes + always + you don't have to say it, we're not doing raw science here + it's implicit + i think it's important to point that out and make it explicit + you made it several times + we got the point + what matters in the current discussion is whether you agree or not + and why + and this will be your interpretation too + and we'll see if it's convincing + but, from experience, i expect noone will be convinced ;p + ^^ + the issue is too tied with the core goals we have in mind + but why does it matter whether i agree or not + that's my point actually + you seem to have a problem understanding the issue, i was trying + to convince you there is one + so, if i want to achieve that, it matters + what core goals ? + basic dialectic + well, for example, for me, i want people to think of the system as + a whole + i want something effective, technically very good, and that + respects user freedoms + i also want alternatives, i won't explain why, let's say it's + obvious + i agree + well, systemd people don't think of the system as a whole + here, what i call "system" is very large + it would almost equal society + i understand why they do that + they have the right to do that + but then i could say i understand why people make proprietary + software, and they also have the right to do it, i still won't approve it + it contradicts my personal goals, my personal view of how things + should be + i completely agree + but then again, what you said now and the way you said it was + very different + maybe, it's 3am, i'm sick and exhausted :) + more abstract + when i give an opinion + actually, when anyone gives an opinion + i consider it implicit that it's their point of view alone + they're not enforcing anything + merely speaking out + people tend to overestimate the importance of their own opinion + hm i wouldn't say so + and that's probably why the "who" doesn't matter a lot to me + it would matter if the person in question had real power + and his opinion could have a strong influence + in which case it wouldn't be overestimated + i could say what i think to systemd people + teythoon: quite frankly, I'm not sure what you are complaining + about. the systemd followers are trying to impose their opinions on + various projects. other people (including braunr and me, among many + others) are voicing counter-opinions. what's wrong with that? + but i'm pertty certain the weight they'll associate to what i tell + them will be very low :) + antrik: he called it "annoying whining" + i think it's the only problem + braunr: I don't think the systemd people associate much weight to + *anything* others say... ;-) + heh :) + to make an historic analogy + it seems to me they're repeating the same mistakes others did + during the unix wars + antrik: but when you say "the systemd followers are trying to + impose their opinion on various projects", don't you dismiss the + possibility that the gnome3 people just want to make external displays + hot-pluggable? + of course they do + don't you dismiss that proprietary software author just want to + make money ? + no + well, if that's the only thing you keep in mind to make your + opinion, you'll miss important points + that is an example of course + they're sacrificing interchangeability and starting a possibly + major rift in the community for hot pluggable displays + it may not be worth it + not supporting stuff like that might make the whole ecosystem + obsolete + i'm not saying it shouldn't be done + i'm saying it should be done while sacrificing other important + things + it would just take a little mort effort + and even if it wasn't done + that's what i meant by "whining" + no offense + what is the problem of it being "obsolete" ? + but talk is cheap, offering alternative solutions is hard + isn't unix obsolete ? isn't xorg obsolete ? + hum no + no one did, so they implemented their nice features + the point isn't to offer alternative solutions + it's to make them possible + or at least, not deny their technical feasibility because they + don't care + teythoon: see, "interchangeability and starting a possibly major + rift" don't look to conflict with your personal goals + that's the point where i think i can no longer do anything to + convince you + so i'll head to bed :) + heh, me too :) + honestly, i don't care a lot + i mean + it won't change much for me + but again, my brain is wired to think of things as a whole + on that note, good night :) + good night :) + teythoon: again, IT'S NOT ABOUT DISPLAYS + believe me, I do have some understanding how display hotplugging + works + also, the problem is not that gnome3 supports logind. the problem + is that gnome3 works *only* with logind now AIUI + there is yet another way to state the fundamental problem + there is a kind of social contract among free software projects: + every maintainer takes a reasonable amount of extra effort to support use + cases beyond his own. in return, his use cases are supported by other + maintainers + the systemd guys are breaking this contract, by explicitly + refusing, up front, to take *any* effort to accomodate other projects' + needs + + +## IRC, freenode, #hurd, 2014-01-28 + + teythoon: + https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/EgKwQV8te7s + azeem_: pffff :) + heh + which reminds me + if we want to state our position wrt the default init system + debate we should probably do it right now + yes + ml or collaborative editor ? + well, tech-ctte chair called the vote only for the default init + system for the Linux-ports + the vote got shot down on technicalities, but that might stand + I think that is a good thing, cause it implies that not one init + system has to be adopted across all ports + we talked the other day that it might make sense just to state + our view and our needs + sure. + I think what's needed is (i) an init-system agnostic system to set + the enable/disable state of services (ii) possibly mandating a .ini-style + config file along the style of whatever init system gets chosen as + default for Linux, to be used by non-Linux init systems as inut + input* + just my 0.02 EUR + uh + looks overkill + i was thinking more along the lines of 1) we have never used the + default debian init system and are cool with not using the default in the + future, 2) we intend to use sysvinit in the future, 3) to that end, we + ask the init script machinery to be left in place + but then, people managed to write stuff like libvirt + so who knows + 4) we will help maintaining it as part of our porter effort + i agree with teythoon + 5) we look forward to using openrc as incremental improvement, + complementing our sysvinit boot solution + yes that would be nice + i'll write a draft to debian-hurd, ok ? + openrc now has a dependency loop resolver, so parallel would + work:) + so is insserv, isn't it ? + there were complaints on openrc + https://bugs.gentoo.org/show_bug.cgi?id=391945 in the tech-ctte + discussions, now fixed + gnu_srs: please accept the fact that openrc will not be picked by + the tech-ctte for the Linux ports + azeem_: I do, I'm referring to arguments during the discussion + (history) + sure, just checking + teythoon: your post is being used to portray systemd cgroups + treatment as the right way… + ArneBab: so ? + it probably is the right way + that's not the problem + do you want to clear that up? (do I remember correctly that you + did not like that way?) + we don't like the cgroups interface + i will + not the feature + braunr: that’s what I meant + exactly + the feature amounts to resource containers in the hurd critique + ... + we do want that too :) + anatoly: you want them to rewrite cgroups ? + err + ArneBab: ^ + +[[dbus_in_linux_kernel]]. + + i've been thinking + maybe the magic write stuff isn't that bad after all + :) + i was thinking the same thing actually + i mean, it's not the nicest thing, but it shows how flexible our + solution is + the hurd is a lot about glue code already so why not + the problem is that there is no way to test cgroupfs + the main user is systemd, and it requires tons of other stuff + right + any other user of cgroups is also probably using other + linux-interfaces too + + +## IRC, freenode, #hurd, 2014-01-29 + + About openrc having a dependency loop resolver: : so is + insserv, isn't it ? + I found is_loop_detected() in insserv/listing.c but that one just + exits without telling where the loop is + + +## IRC, OFTC, #debian-hurd, 2014-01-29 + + * youpi trying the new sysvinit + hopefully we'll then be able to at last use the proper ifup/ifdown + debian way for networking :) + teythoon: why leaving hurd's runsystem by default rather than + sysvinit's? + ah, another issue, too, now that /dev/vcs appears in /proc/mounts, + umountfs would umount it + ideally umountfs would not umount passive translators + we could blacklist /dev/vcs in umountfs, but the same issue would + happen for user-defined translators in their own home, for instance + + +## IRC, freenode, #hurd, 2014-01-30 + + booting with the new sysvinit and openrc versions: works:), but + only in recovery mode:-( Hangs before INIT: version 2.88 booting + after start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] + exec init proc authtask c1120dc8 deallocating an invalid port 134517370, + most probably a bug. + related or an openrc problem? will test with sysv-rc + I don't have such issue with sysv-rc + k! + shouldn't recovery mode mean starting in runlevel 1, I get + runlevel 2? + it should + gnu_srs: recovery mode normally mean single user, which is between + rcS and rc2 + I get INIT: Entering runlevel: 2 + rcS.d should really have been named rcboot.d, as that is really what + it is. + ah, right, recovery is not single + (single as in init 1) + runlevel 1 is not single user either. it is more a gateway into + single user. see /etc/init.d/single to see what happen at the end of + runlevel 1. + init 1 and init 2 seems to work + well, the openrc dependency loop detector has found an init + script loop, maybe it has to be fixed? + disabling the hurd console solved the dependency loop problems, + thanks openrc;-) + (have to dig deeper to see where the loop is, and how to solve + it) + + +## IRC, freenode, #hurd, 2014-01-31 + + Hi, does the hurd console work with sysv-rc: In operc I get with + #console -d vga -d pc_mouse --repeat=mouse -d pc_kbd --repeat=kbd -d + generic_speaker -c /dev/vcs + console: Console library initialization failed: Not a directory + gnu_srs: yes, it works with sysvrc + gnu_srs: check that /dev/vcs has the appropriate translator + record + showtrans /dev/vcs: empty on another box: /hurd/console + yes, fix that and your console will be fine + settrans /dev/vcs /hurd/console? + or should it be active? + no, set an passive translator record so that this will be + persistent + something is wrong: when starting the hurd console screen is + blanked (and hangs) + can I get the hurd console when running with the serial console + (to see boot messages)? + gnu_srs: yes, yuo can + will try that image then, tks:) + teythoon: how to create all underlying directories? ls /dev/vcs: + 1 2 3 4 5 6 + don't, /hurd/console takes care of that + is settrans /dev/vcs /hurd/console correct? + yes + What are those underlying directories representing ? + the hurd console is a console multiplexer + bringing multiple virtual consoles to the hurd + # showtrans /dev/tty1 + /hurd/term /dev/tty1 hurdio /dev/vcs/1/console + aha: console -d vga -d pc_mouse --repeat=mouse -d pc_kbd + --repeat=kbd -d generic_speaker -c /dev/vcs + task c1120e70 deallocating an invalid port 1782, most probably a + bug. + teythoon: Is it that /dev/tty1 has multiple translators ? + no + exactly one translator is bound to any given node in the vfs + something is strange with the hurd console: booting with it + enabled still runs the mach console, halting: + http://paste.debian.net/79438/ + what is strange about taht ? + when starting the hurd console: task c1120e70 deallocating an + invalid port 1782, most probably a bug. + so ? + and the paste when halting: twice + that is a known issue + with the hurd console? + how do you know it's the hurd console ? + that message comes from the kernel + currently, it is not possible to tell which process is + responsible + b/c the task is given as a pointer to the kernel task structure + not as a pid + I don't ,it is triggered by it at least + currently there is no way to map the former to the latter + why do you think it's a problem ? is something not working as + expected ? + maybe a reproducible way to hunt that bug! + we have one already + it happens every time the hurd boots + yes, hurd console does not start, even when enabled:-( + then please say so ;) + I did: (11:23:30) srs: something is strange with the hurd + console: booting with it enabled still runs the mach console, halting: + http://paste.debian.net/79438/ + where do you say that the hurd console did not start ? + maybe it is easier to hunt the bug in an already booted system + you just said that the mach console is still active, wich it is + even if the hurd console starts + yes + please start the hurd console by hand + -d current_vcs -c /dev/vcs -d vga -d pc_kbd --keymap us + --repeat=kbd -d pc_mouse --protocol=ps/2 --repeat=mouse + err + /bin/console -d current_vcs -c /dev/vcs -d vga -d pc_kbd + --keymap us --repeat=kbd -d pc_mouse --protocol=ps/2 --repeat=mouse + when I log in I have the mach console not the hurd console + yes, log in as root, then run that command + I've done that: (11:10:27) srs: aha: console -d vga -d pc_mouse + --repeat=mouse -d pc_kbd --repeat=kbd -d generic_speaker -c /dev/vcs + please read? + and you discovered in that process that /dev/vcs lacked a + translator record + did you run it again after fixing that ? + the reply was: (11:10:27) srs: task c1120e70 deallocating an + invalid port 1782, most probably a bug. + well, if you are feeling that what i ask you to do is + unreasonable, i'm not sure how i can help you + yes, the translator was running! + you could hunt down the port deallocation bug, that'd be awesome + and most welcomed + but i don't believe it is causing your console malfunction + I did what you asked for?? + I'll do it again! + ok, now I don't get that error, but still no hurd console? the + process is running, logging out and then in, no hurd console. + not possible in serial console? + no, the hurd console is displayed using the graphic card + you asked for that with -d vga ;) + not sure if there are any other display drivers + when you asked whether you can use the serial line, i assumed + you used both qemus graphic terminal and a serial console + try kvm ... -serial telnet::1236,server,nowait, then use telnet + localhost 1236 to connect to the serial console + then, you can start the hurd console over the serial console and + see whether that worked + OK; that's what I asked before. I tried with the graphic one, + I'll try again + telnet output is empty + frozen + did you start a getty there ? + in hurd? + b/c if you dropped the console=com0 argument from you gnumach + command line, the mach console will be put on the vga screen, not on the + serial console + I dropped console=com0 from grub.cfg, yes + ok + so simply no one is talking to the serial port anymore + did you try to start the hurd console ? + I did before, can do it again + startin the HC blanks the screen, and freezes the vga output:-( + ssh still working + hm + try ps Ax | grep tty, are there any term servers running for + /dev/tty1..6 ? + lplenty of them: http://paste.debian.net/79442/ + good, even gettys are there + and the console translator runs + hm + root 1224 5 7 months /hurd/console + root 1227 1226 7 months /bin/console -d vga -d pc_mouse + pc_mouse -d pc_kb... + yes, everything looks good + just to be sure, you are currently using the qemus graphical + frontend, right ? + yes + hm :/ + gnu_srs: do you see loginpr processes ? + nope + hum + this strikes me as odd + on my system, i see no gettys but only loginpr processes + this is b/c the hurd getty does little other than to print some + text and run the login program + but on your system the getty sticks around + is /sbin/getty really the hurd getty? it's easily recognized by + its crappieness: + /sbin/getty --help || echo $? + 1 + 1 + hm + still funny though + you could try to run the hurd console, then run a getty manually + e.g. /sbin/getty 38400 tty1 + from the ssh login? + yes + then the graphic display is back showing the loin prompt:P + weird + well, so most things work + that's a good thing + funny that hurds getty should get stuck like this + and the terminal is hurd:-) + any chance you can produce a stack trace of one of your getty + processes ? + how? + gdb --pid=the_pid /sbin/getty + then, do bt like usual + so you mean tty2-6 are broken? + no + it's just for some reason your gettys do not behave nicely when + run from init + from running tty2: bt #0 0x01087b09 in ?? () + #1 0x00000000 in ?? () + not much + hm :/ + indeed + our getty logs to syslog, can you see anythign of interest here + ? + Jan 31 12:00:46 debian-openrc-20140123 rsyslogd-2066: could not + load module '/usr/lib/rsyslog/imklog.so', dlopen: + /usr/lib/rsyslog/imklog.so: undefined symbol: klogAfterRun + [try http://www.rsyslog.com/e/2066 ] + nothing tty releated + gnu_srs: oh, i just noticed, please look into auth.log, the + getty stuff ends up there + teythoon: http://paste.debian.net/79465/ + well, that is interesting :) + /dev/tty1 not a directory? + for instance, yes + it says bad syntax if it was invoked in the wrong way, i.e. not + with exactly two arguments + that might have been you yourself, right ? + with getty --help i mean + for the not a directory message, please verify that + # showtrans /dev//tty1 + /hurd/term /dev/tty1 hurdio /dev/vcs/1/console + and stat /dev/vcs/1/console says it's a character special file + I used exactly: /sbin/getty --help || echo $? + yes, that accounts for that bad syntax message + what so bad about that? + showtrans /dev//tty1 + /hurd/term /dev/tty1 hurdio /dev/vcs/1/console + getty is so simple minded that it doesn't really parse its + arguments + stat: http://paste.debian.net/79469/ + looks nice + everything looks nice, i'm at my wits end here + and everything works OK with sysv-rc? + yes + by the way, are you using the sysvinit init scripts or something + openrc related ? + openrc use all the scripts in /etc/init.d + actually, could you try to kill -HUP 1 ? + BTW: the dependency loop detector has found many loops in those + scripts + kill -HUP 1: nothing happens + ok, try to kill one of those gettys and see if the one that + respawns works + then again, the getty should try to reopen the device every + minute until it succeeds + getty tty1 and tty2 disappeared? kill -HUP tty3 respawns + immediately + now no getty processes are left? + /dev//tty4: Not a directory etc? + sorry, i should have expressed myself more clearly + kill -HUP 1 sends a SIGHUP to sysvinit, this makes it reload + it's configuration + when i said kill some getty, i meant just kill some_pid + when you said 'kill -HUP tty3 respawns immediately', did you + mean you killed the getty that was listening on /dev/tty3, and then a new + one appeared and you got a login prompt at tty3 ? + a new pid appeared, the login prompt is on tty1 + this one? /hurd/term /dev/tty1 hurdio /dev/vcs/1/console + i'd like to invite you to look at daemons/getty.c + not a big piece of code: anything specific? + no, just look what it roughly does + not a directory is not coming from that code + correct + it execl-s login + yes + inevitably + but you do not observe this + how come when they are running? + this is the question that you will have to answer in order to + make any progress + I killed only one of them: kill -HUP 1031 and they all + disappeared + i thought along these lines: the most obvious way to stall getty + is if it never exits that loop + so i guessed it might be failing to open the device + we already observed that getty works fine if invoked by you + manually + the question thus is, what is different when getty is invoked by + init ? + if a process started by init in this way is killed, init will + restart it + please note, that if anyone says kill that process, she means + send a signal that results in process termination + and while sighup causes processes to die if the signal is not + handled, it is not the ideal signal to kill processes + b/c some processes handle sighup + like sysvinit, which reloads its configuration + many daemons do this + see 'man 7 signal' for how signals affect processes + sorry, have to leave for now, bbl and thanks a LOT so far:) + ok :) + you are welcome :) + teythoon: I'm back but cannot spend to much time on this + tonight. Maybe you should try it yourself, do you want another image on + my box? + it'd be nice if you put your packages somewhere + there are no special packages sysvinit (-46) and openrc (-8) + surely openrc with some patches ? + from #openrc: (17:37:41) srs: start with sysvinit and make it + work first! + (17:28:43) srs: zigo: Then I copied that working image to + another, and changing hostname, and continued from there. + openrc with the hurd patches for /lib/rc/sh/init.sh (v8 should be + available from experimental by now) + sweet :) + gnu_srs: maybe it was just some weird issue with your system + i just switched to openrc and everything seems to just work + i'll redo what i just did more cleanly to get a clean test vm... + nice:) + teythoon: And you got the hurd console? + heh, i believe so >,< + i didn't see it b/c i was using --nographic + but ps Ax looked alright + hrm + gnu_srs: i can reproduce your trouble, umount still strips the + translator record from /dev/vcs + at system shutdown time + so that's the reason. Additionally I have to issue halt twice + from a ssh login, see http://paste.debian.net/79517/ + funny indeed + gnu_srs: i can reliably recover the hurd console by doing + settrans /dev/vcs /hurd/console && service hurd-console restart + && pkill getty ; sleep 5 ; pkill getty + humm, as you say, halt doesn't work + + +## IRC, OFTC, #debian-hurd, 2014-02-01 + + I've just uploaded a new new sysvinit package to experimental, with + all the latest hurd fixes. + + +## IRC, freenode, #hurd, 2014-02-01 + + 17:53:28< teythoon> settrans /dev/vcs /hurd/console && service + hurd-console restart && pkill getty ; sleep 5 ; pkill getty + teythoon: Any ideas on how to solve this? + gnu_srs: yes, i have that on my todo list + so it is not an openrc problem? + gnu_srs: no + + +## IRC, freenode, #hurd, 2014-02-01 + + start ext2fs: Hurd server bootstrap: ext2fs[gunzip:device:rd0] + exec init proc au + thtask with pid 6 deallocating an invalid port 134517370, most + probably a bug. + :) + pid 6 is exec o_O + teythoon: Nice to see that you added pid numbers for error + print-outs:) + so the boot error comes from the exec sever? + so it seems + server* + have you found where? + no + + +## IRC, OFTC, #debian-hurd, 2014-02-02 + + but when I install the new packages, and run update-alternatives + --config runsystem to select sysv, the boot fail with: start ext2fs: Hurd + server bootstrap: ext2fs[device:hd0s1] exec init proc authtask c1128dc8 + deallocationg and invalid port 134517370, most probably a bug. + was that the wrong approach? + is there some way to recover when hurd fail to boot with sysvinit? + I was able to boot in recovery mode. :) + and this time sysvinit booted. saw a segfault message just after + sysvinit started, no idea what caused it. + looks like it is startpar that segfaults. + looks like the invalid port message come every time, no matter if + the boot hang or not. + I was wrong. it isn't startpar segfaulting, it is something in + rcS.d/. + bootlogd is the process segfaulting at boot. + looks like the boot success rate is 30% or so. + reported bootlogd problem as . + I really miss valgrind. :) + pere: yes, the invalid port message is from the exec server + pere: i see the hurd boot process hang sometimes, no matter if i + use sysvinit or not + i believe it's a race condition in the ext2fs, not sure though + teythoon: but did the frequency of the hang go up with sysvinit or + not? to me it seem like that. + pere: yes, i believe it got worse + what hangs is fsysopts --update / + runsystem.sysv does that quite early + able to debug it? + I like the fact that runsystem.sysv set up ip at boot time, while + with .gnu, I have to run dhclient /dev/eth0 manually + it is quite confusing that hurd got two init processes with + sysvinit. one as pid 1, and another that seem to be the parent of all + internal stuff. perhaps the latter could be renamed to hurd-system or + something like that? + "sleep 0.2 # Work around a race condition (probably in the root + translator)." do not look too good... + (I increased from 0.1 to see if it help me. :) + did it ? + i plan to rename /hurd/init to /hurd/startup + +[[hurd_init]]. + + nope. :) + five boots in a row hung. :( + still no go... + are you using a vm or real hardware ? + vm + kvm, via virt-manager, to be exact. + me too + on the sixt boot, after waiting a long time between try 5 and 6 + (gave up a bit), it booted. + sleep 1 did not help either. + :( + well, it's not *that* bad for me + in fact recently it has been a lot better + you might try my packages + pere: here http://darnassus.sceen.net/~teythoon/hurd-ci/ + teythoon: tested it, and it seem to solve the problem. + is also rid of the strange error at the start. + teythoon: your packages even work without the sleep 0.1, at least + some of the time. :) + hm, but the success rate without sleep 0.1 is very low. I was able + to boot once, and never again. :( + pere: yes, i fixed the spurious port allocation today :) + pere: nice to hear that the sleep 0.1 i put in does increase + your chance to boot as well + + +## IRC, freenode, #hurd, 2014-02-02 + + gnu_srs: i found the spurious port deallocation :) + Cangrats:-D + trouble is, i introduced it >,< + Congrats* + Ah, you did? + gnu_srs: yes, in debian/patches/exec_filename_fix.patch + + http://darnassus.sceen.net/gitweb/teythoon/packaging/hurd.git/commitdiff/6da3e0be8fde0594bd84a13536d9d93048186790 + * teythoon . o O (diffs of diffs are trippy :) + + +### IRC, freenode, #hurd, 2014-02-03 + + teythoon: oh nice, you found that bug :) + braunr: yes, once i knew where to look it was easy to fix ;) + + +### IRC, freenode, #hurd, 2014-02-05 + + i wonder why the port deallocation bug made the system hang when + the libc was compiled with the newer gcc + teythoon: so it was indeed the problem ? + braunr: youpi said so, yes + oh right + +[[glibc/debian/experimental]], *glibc 2.18 vs. GCC 4.8*? + + +## IRC, OFTC, #debian-hurd, 2014-02-03 + + + http://people.skolelinux.org/pere/blog/Testing_sysvinit_from_experimental_in_Debian_Hurd.html + :) + pere: sounds like your hurd-console isn't running and there is + no getty on the mach console + pere: you could add sth like 8:2345:respawn:/sbin/getty 38400 + console to your inittab + I'd rather wait until the hurd porters get it right in the debs. :) + I suspect upgrading the downloadable image to use the latest + packages also would help a lot. + with upgraded packages, /proc is working and pstree, pkill, top, etc + is working out of the box. :) + + +## IRC, OFTC, #debian-hurd, 2014-02-04 + + I just uploaded sysvinit with hurd support to unstable. :) + + +## IRC, freenode, #hurd, 2014-02-04 + + teythoon: Hi, the segfault during boot is coming from bootlogd, + see bug #737375 + also the output on the console is from there: end_request: I/O + error, dev 02:00, sector 0 + gnu_srs: interesting :) + gnu_srs: i believe the end_request message comes from gnumach + yes, that's just a floppy disk access attempt + might be so yes + it's not a "might", it's sure :) + dev 02:00 is the flopy + k! + + +## [[glibc_IOCTLs]], `TIOCCONS` + + +## IRC, OFTC, #debian-hurd, 2014-02-04 + + Each time I upgrade my hurd box, I cannot login into it ... + No login prompt. + WTF is going on? + How to fix? + zigo: most likely your hurd console is not running and there is no getty started for the mach console + teythoon: How to fix? (note: I already have the partition mounted in a loopback) + Or maybe go in recovery mode? + depends + do you use sysvinit ? + do you use the hurd packages from hurd-ci ? + + +## IRC, OFTC, #debian-hurd, 2014-02-05 + + teythoon: Sorry, didn't see your reply. I just used the Hurd image, + untar it, and apt-get update / dist-upgrade. That's it, nothing more or + less. + teythoon: I obviously would like to install sysvinit, and later + OpenRC. That's the reason why I'm running Hurd: to make sure OpenRC works + with it without issues. + teythoon: It seems it "sometimes work" or what??? + I was able to repair it using the recovery mode, it seems. + grrr... + I got this issue again, again and again ... + Sometimes, got the tty1, sometimes, it doesn't appear. + That's REALLY frustrating. + zigo: and yes, the success rate for boot is not 100%. it increases + a bit by using the packages teythoon created at hurd-ci. + apparently some race condition somewhere. + pere: So, I should just try and reboot again and again ? + pere: Is it improving after switching to sysvinit? + once I had to boot six times before I got it running... + I was told that the race involves a call to fsysopts, and that the + success rate with sysvinit was smaller because fsysopts command was + called earlier. I can not confirm nor deny this. + with the latest packages from hurd-ci the success rate is almost + 100% again. + pere: Where do get that? + zigo: see + pere: What's the "update-alternatives --config runsystem" for? + to switch to sysvinit + Right, that's what I was missing then! :) + the new sysvinit version in unstable was built for hurd one and a + half hour ago. so soon hurd users can skip experimental for that. + pere: I've just succeeded in booting with OpenRC! :) + Though this console pb is REAAAALLLYYYY getting on my nerves! :) + Also, any idea why we don't get the nice colorfull output when + booting? + When booting with OpenRC, I've noticed that the dependency loop + detects some loops with the hurd-console thing. + zigo: good to hear that you got it working + the console problem is the following + when you shutdown using sysvinit, the system will run umount -a + it will then mistake some translators (like the one on /dev/vcs) + for file systems and remove their passive translator records + you can fix this by running '/usr/lib/hurd/setup-translators -k + -p' + you can avoid it for the time being by using reboot-hurd or + halt-hurd + teythoon: btw, how often is the hurd boot image available for + download updated? + not very often + teythoon: Can I run '/usr/lib/hurd/setup-translators -k -p' + mounting my hurd image in a chroot? + Hum... + Probably better to do that in the recovery mode, no? :) + dpkg-reconfigure hurd + would be easier to type :) + but we really need to fix that /dev/vcs unmounting + missing working getty and missing symlink from /run/mtab to + /proc/mount are the most serious problems I still see. + The recovery mode doesn't work with OpenRC ! :( + (it does in kFreeBSD and Linux, not with hurd ...) + What happens is that it continues to runlevel 2. + How can I fix then? + pere: missing working getty? + I don't see what issue you are referring to + about the missing symlink, I'm wondering what is supposed to add it + zigo: I don't know if anybody investigated it yet + youpi: yes, after boot there is no login prompt. + * pere have no idea, suspect a script in initscripts. + youpi: I'm reffering to the fact that I have no login prompt after + boot, and that I don't know how to fix, since I don't have a recovery + mode to my disposal anymore. + pere: but is the console started? + (I mean the hurd console) + pere: I suspect a wrong dependency, which OpenRC by the way, prints. + pere: otherwise, unless you have a /dev/console getty in + /etc/inittab, it's expected you don't have a prompt + zigo: add + c:23:respawn:/sbin/getty 38400 console + to your /etc/inittab + youpi: yes, we need to get that fixed + grrrr + * youpi wanted to change the image file on people.d.o + but I can't do that without downloading it on my laptop, to be able + to modify it + I would have been, if people was a hurd system :) + the proper way to fix this is to implement the get_source stuff + and get rid of the heuristic in mtab.c + youpi: nope, no console process running. + then that's why, /dev/vcs got unmounted + I already have a console getty in inittab. got it from the last + sysvinit package + * youpi should have brown-bag-fixed these bugs before this week-end + actually :) + pere: but you don't get a getty prompt on the mach console? I don't + understand why + it does work for me + brown-bag-fixed ? + youpi: Adding that in /etc/inittab didn't fix anything. + yes, ugly hacks uploaded to debian-ports + zigo: even with rebooting? + could you snapshot your screen so we can make sure what you are + actually getting? + youpi: I did it mounting my partition in a loopback... + Then booted up, and still couldn't see the console prompt. + ok, but please take a snapshot, so we are sure what is actually + happening + whether the console starts, etc. + that info passed out of the screen and is not shown after my boot, + at least. + which info? + again, please take a snapshot of the screen + otherwise we are just guessing, and that's never good for debugging + Maybe you'll find this interesting: http://paste.debian.net/80246/ + This is the output of OpenRC booting and detecting dependency loops + in the LSB header scripts. + youpi: the info about the console being started or not. I'll show + you, give me a minute. + zigo: well, that shouldn't be more problems than the dependency + loop already existing between rc.local and rmnologin + youpi: any loop is a fatal problem. + how come the rc.local vs rmnologin is not a problem ? + With sysv-rc in Debian, there's all sorts of loops that are just + silent. + I have not seen that loop on my linux system, so I am unsure what + you talk about. + (the actual issues is simply that all three use Required-start: + $all, and thus all depend on each other) + That's a huge pb IMO. + pere: well, + zigo: show me one? + rc.local:# Required-Start: $all + rmnologin:# Required-Start: $remote_fs $all + Yeah, the $all is just *bad*. + that is no loop. + I do believe we should implement a lintian warning about it. + sure, $all do not behave the way most people expect, and should be + avoided as much as possible. + any other loops? + no + (not that I know of) + youpi: sending you the screenshot via irc. + uh, long time no use dcc send, I don't even know where it sent it + to :o) + ok. aborting and trying another approach. + http://www.picpaste.com/booted-herd.png + ok, so boot didn't actually finish + that's why you don't get gettys or hurd-console (which is last) + there must be some init script hanging in the meanwhile + logging in via ssh show no running startpar process, so I doubt that + is the case. + syslog contain this: Feb 5 10:10:27 hurdtest console[808]: Console + library initialization failed: Not a directory + that is due to /dev/vcs not mounted + but that should have not prevented the boot from completing... + the boot is completed, as far as I can tell. + you can disable the hurd console in /etc/defaults/hurd-console + do you have gettys running? + no such file. + oops, -s + http://paste.debian.net/80251/ + pere: check your /etc/inittab, is there a getty for the mach + console ? + he said yes earlier + oh ok + i wonder why it doesn't show up then + same for me + if the getty cannot open the device, it will loop + ah, I was wrong. the inittab is not the one I thought. the current + one is after a reinstall, while I checked the content before that. + pere: check /var/log/auth.log + there is indeed no console entry in /etc/inittab. I thought it + would be copied into place during upgrades? + not if it exists + iirc + indeed + ah, great. "cp /usr/share/sysvinit/inittab /etc/inittab" and a + reboot fixed it. :) + phew :) + it really should try harder to update the inittab on hurd to a + working one. + didn't i do something like this to fix the getty path ? + yes. that was the code I expected to solve this. + it didn't work ? + well, I had the wrong inittab file... + btw, do hurd have the needed syscalls for bootlogd to work? + i haven't looked at bootlogd yet + would be nice to have a text dump of the boot when trying to figure + out what went wrong. + yes, that'd be nice + + pere: could you blacklist /dev/vcs in umountfs, just like already + done for /proc|/dev|/.dev etc. ? + so at least that case, which is really problematic, gets fixed now, + and not have to wait for another, more hurdish solution + youpi: just send patches to bts, and I'll pick it up from there. + nice. i'll work on the proper solution. bbl + teythoon: Can we add those translators to the exclusion lists in + umount[nfs]? + Sorry, I just noticed youpi's comment. I'm a bit behind. + rleigh: good to see you! are you back to the keyboard? fully + recovered? + Not quite fully, but on the mend, thanks! + :] + rleigh: yeah, good to see you again. I got a burst of energy and + brushed a bit on sysvinit in your absence. :) Even revitalized the + #pkg-sysvinit channel. :) + pere: Yes, I saw all the commit emails flying by! + I realistically won't be doing much for several weeks at least + though, I'm afraid. + no worries. spend your time getting well. :) it would be great to + have you on #pkg-sysvinit, though. :) + I'll join, no worries. I should add it to my irssi config so I + can't forget! + teythoon: serial console always works, right? no matter how + hurd-console behaves. + heroxbd: yes + but you need a getty on it + well, just like on linux :) + yes + almost + on mach, we have the mach console. by default that is put on the + vga screen, but you can make mach put it on a serial port using the + gnumach command line flag console=comX + well, just like on linux :) + understood, thanks! + oh, i didn't realize linux has this as well + teythoon: you'll use it a lot on a embedded system + an* + ok + + plus, seems it can't cleanly umount /, at boot it fsck's it, fixes it + and auto-reboot + it's odd that / doesn't get unmounted, don't you get a message at + "notifying ext2fs device:hd0s1 of shutown" ? + on console last 3 lines on halt are + Deactivating swap...swapoff: /dev/hd0s5: 4193208k swap space + done. + Unmounting local filesystems...done. + INIT: no more processes left in this runlevel + is this on reboot or on halt? + halt + then you should also be getting the "notifying" messages, as well + as "In tight loop: hit ctl-alt-del to reboot" message + it umounts uncleanly on reboot too + if you don't wait for these, there's little wonder it's not + properly unmounted + i waited many seconds, time to rewrite 3 lines above for you for + instance (not a fast typist) + on reboot it's harder but iirc they don't appear as well + * gg0 rebooting again + need to wait it finishes fsck'ing + (i should resoldering my serial cable to get back to lazily c&p) + -ing + many Give root password messages then + Give root password for maintenance + (or type Control-d to continue): + INIT: Id "z6" respawning too fast: disabled for 5 minutes + INIT: no more processes left in this runlevel + i'll wait 5 mins to see what happen + ok another dozen of Give root password and same couple of INIT above + no, just the first INIT + so z6 doesn't work + i.e. /sbin/sulogin (see /etc/inittab) + check out why that is + +[[hurd/translator/mtab/discussion]], *IRC, freenode, #hurd, 2013-06-25*, +*coreutils' `df`*. + + [...] depends on coreutils actually building + which depends on putting back a login package from the shadow + source package + are someone on that task? + no idea + IIRC I've mentioned the issue on the lists like months ago + but probably nobody took the tas + k + basically it means fixing any bug that login or su from the login + package would have + and then properly handle the migration from hurd-provided versions + to login-provided versions + and then we would be able to build coreutils + which BTS report is this? + I don't know if any report has been written about it + perhaps simplest would be to build the login package, but not its + bin/login + it seems hurd's getty uses special options of hurd'slogin + that's probably the easiest way to go + + sulogin seems to work fine but it shouldn't even called: + # Normally not reached, but fallthrough in case of emergency. + z6:6:respawn:/sbin/sulogin + +be + I suspect a good fix is to provide a new init.d script in the hurd + package adding the symlink for hurd. + + umountfs gets stuck at "Will now umount local filesystem:settrans + -apgf /lib/rc/init.d" + + +## IRC, freenode, #hurd, 2014-02-05 + + teythoon: Any ideas why I have to issue halt/reboot twice to make + the command succeed (from ssh login) + Is it the same issue with sysv-rc? + no + BTW: The segfault when booting came from bootlogd (wrong + parameters, Linux/~Linux), removing that one fixed it;-) + + +## IRC, freenode, #hurd, 2014-02-06 + + teythoon: we really need to find the boot issue for which you added + a sleep 0.1 in runsystem.sysv + apparently I had to move it above the mach-defpager startup, to get + a system that boots most of the time... + + did somebody look at + http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html + ? + azeem: interesting + braunr: was mentioned here: http://lwn.net/Articles/584428/ + " Systemd won't work for them, that's for sure, but nosh as a + systemd unit file compatible alternative could. " + "I'm also very interested in seeing a discussion where the Debian + Hurd and BSD porters weigh in for themselves" + + +## IRC, OFTC, #debian-hurd, 2014-02-06 + + on halt/reboot it can't remount readonly root because it's busy, what + makes it busy? + by keeping /lib/rc/init.d mounted (like /dev/vcs) it shuts down + properly + I don't know about such directory + so seems that failed readonly remount is not a real problem because + at the end it runs halt-hurd/reboot-hurd which umount root properly + yes + afaiu it's a tmpfs where openrc copies "itself", kind of work + directory + by removing it, it can't continue working + at boot some messages are about its creation/population + why do init.d/hurd-console depend on $all? In most cases, depending + on $all is not giving you want you expect. + because we prefer to start the console (and thus clear all the + screen) only after the boot has finished + otherwise the console output will be messed up by the end of the + boot messages + youpi: there has to be a better way + b/c the way it is now, if one spawns a getty on the mach + console, it will mess up the hurd console as well + well, we do want mach messages printed even with the hurd console, + at least + i once thought that instead of printing them the kernel could + send messages to a registered userspace daemon that could e.g. send them + to syslog + that requires syslog to be working at all + changing $all to $local_fs seem to work fine here. + when the kernel cries out, we'd better always be able to hear it :) + pere: but then you have the bootup messages in the middle of the + console, don't you? + not as far as I can tell. look just the same as before. + well, on my box it seems that it gets to start after other daemons, + by luck + ah, perhaps getty actually clears the tty? + then that would be ok + youpi: i don't think it does + well, somehow something clears the output at least + i thought he hurd console does this + it does on startup, yes + but if it starts before other daemons + the damons startup output gets over it + one sees the console clear the screen, then get daemon startup + messages, and then the screen gets cleared again before the login prompt + appears + interesting, i haven't seen this happening + it seems like it happens when emitting text on /dev/tty1, the + console will then clear the screen to make the way for the new output + and since that happens on getty startup, it happens to be after all + daemon startup + yes, that's what happens + so considering this, I'm fine with starting the console earlier + getting a display glitch seems to have been acceptable on Linux for + years :) + (during boot, I mean) + ok + + anyone else tried openrc? + 15:20 < pere> yes, it did not umount properly. + 15:36 < gg0> reboot or halt? it takes few seconds to actually + reboot/halt since the last message from openrc + 15:39 < gg0> any typo adding such path? + * gg0 likes cross-channel pasting + anyone else keeps getting unclean umounts even after applying + http://paste.debian.net/plain/80386/ ? + gg0: yes, me. worked fine, it didn't shut down properly though + here works like a charm + what do you mean by properly? + i see first it can't remount root readonly but at least by not umount + path in question it continues executing scripts till actually shut it + down with something like {halt,reboot}-hurd + *not umounting + *shutting + for me it did not shut down + you mean don't you get classic press ctrl+alt+canc to reboot message? + yes + from my perspective (and from /hurd/init's), that's not shutting + down + as in it did not call reboot(2) + what are configuration not to miss besides switching runsystem to + sysv one? + *configuration steps + no idea, i did nothing else but to switch to runsystem.sysv and + to install openrc thus replacing sysv-rc + can you paste shutdown messages somewhere? + sure + .o(world is failing, /me can't debug teythoon :)) + http://paste.debian.net/hidden/745071e6/ + in my case i just found out that /etc/init.d/umountfs tries to umount + /lib/rc/init.d where openrc scripts are + what if you set VERBOSE and print REG_MTPTS? something like + http://paste.debian.net/plain/80570/ + there i got "settrans -apfg /lib/rc/init.d" which vanished with first + patch + http://paste.debian.net/80573/ + ok and if you apply first patch http://paste.debian.net/plain/80386/ + i.e. adding |/lib/rc/init.d to mount point to ignore + didn't help + well output should change though + it does + but it still does not shut down + paste please then + http://paste.debian.net/80576/ + what did you expect ? + did you unapply VERBOSE & print REG_MTPTS? + yes + no + well + seems you do, if VERBOSE is set, it prints Will now unmount local + filesystems" + i restored a vm snapshot, and applied both patches + instead of "Unmounting local filesystems" + *seems you did + http://paste.debian.net/80577/ + shall i do it again ? + and what after "root@debian:/# halt" ? :p + 23:55 < teythoon> http://paste.debian.net/80576/ + and openrc shouting lots of stuff about breaking dependencies + please yes do it again + if VERBOSE is set, it prints "Will now unmount local filesystems" + instead of "Unmounting local filesystems" + yes, you are right + still, it does not work + http://paste.debian.net/80579/ + i'm curious about the new REG_MTPTS, supposing /lib/rc/init.d has + been suppressed + ok stop + 23:47 < gg0> ok and if you apply first patch + http://paste.debian.net/plain/80386/ + i did + well, i added that path + i don't believe so, it should ignore it if added + did it fix the issue for you ? + yes + any typo in addition? + obviously patch is against sysvinit source but you have to apply it + to /etc/init.d/umountfs + obviously + isn't it time to tell me you are kidding me yet? + pere: thanks for the upload. I happened to realized that since it + was in collab-maint, I could as well just commit changes, I hope it's ok? + gg0: root@debian:~# fgrep '/lib/rc/init.d' /etc/init.d/umountfs + /|/proc|/dev|/.dev|/dev/pts|/dev/shm|/dev/.static/dev|/proc/*|/sys|/sys/*|/run|/run/*|/lib/rc/init.d) + /dev/vcs is missing, not the latest sysvinit version + could this affect shutdown? + i know + possibly + what if you also add /dev/vcs to path list? + what then ? + i don't mind /dev/vcs being + err, 'umounted' + i can handle that just fine + i mean what happens if you add /dev/vcs to path list in + /etc/init.d/umountfs as you did with /lib/rc/init.d? + what happens = how it shutdown + why would it be any different ? + no idea, seems the only change you don't have + i just know it fixes hurd console + i know it fixes the hurd console b/c i was the one who broke the + hurd console in the first place ... + quite sure there's something wrong on your side + if it's actually among those path to ignore, it can't be added to + REG_MTPTS + my /proc/mounts http://paste.debian.net/plain/80583 + yours? + i hope i'm not forgetting one change i did around + teythoon: /proc/mounts ? + + +## IRC, OFTC, #debian-hurd, 2014-02-07 + + teythoon: sorry for pasting reversed patches + please apply http://paste.debian.net/plain/80587, halt and paste + output + /proc/mounts + youpi: just fine. but please join us on #pkg-sysvinit and make sure + to follow the mailing lists. + gg0: no, sorry, i was perfectly able to use -R on your patches, + as demonstrated by the paste i send + i think i'll rather just wait for the next sysvinit package and + try it again + teythoon: i don't doubt you are able, i'm sorry because i messed up + things + /lib/rc/init.d should not go in $REG_MTPTS + sysvinit 2.88dsf-48 just add /dev/vcs to not-to-umount paths and make + boot consider -s for single user, nothing about umounting filesystems on + halt/reboot + the /lib/rc/init.d/ change to umountfs seem to be the wrong one, as + it do not solve the problem for me. because of this, I have not applied + it to git. + pere: could you try to apply http://paste.debian.net/plain/80587, + halt and paste output? + well it applies to teythoon who doesn't have /dev/vcs + */dev/vcs change + pere: this one applies to -48 + installed. http://paste.debian.net/plain/80615/ + given /lib/rc/init.d is added to not-to-umount paths it can't go in + REG_MTPTS + http://picpaste.com/halt-hurd-DVEVoHnr.png + pere: you didn't apply it + no messages from umountfs + which is even more weird + well, patch claimed it did. + normally it says "Unmounting local filesystems..." + checked the file, patch is applied. + ok i think i got it + patch is good. it just requires booting twice _and_ removing + non-patched /etc/init.d/umountfs.* if any + patch = adding /lib/rc/init.d + so + which files do you need to remove? + /etc/init.d/umountfs.* and /lib/rc/init.d/started/umountfs.* + do you have any? + you should just have patched umountfs under both /etc/init.d/ and + /lib/rc/init.d/started/ + the latter is populate at boot, that's why i said twice to become + effective + *populated + but propably /lib/rc/init.d/started/umountfs can be fixed on the fly + from start: + why do you need to remove these files? + 1/ patch /etc/init.d/umountfs by adding /lib/rc/init.d to + not-to-umount path list + why are these files not ignored? + 2/ remove /etc/init.d/umountfs.* if any (eg. .orig .new .whatever) + pere: because it loads them at boot, you need it loads just the right + one + 3/ reboot twice + (3/ halt twice) + this sound very fishy to me. + or 3/ fix umountfs files under /lib/rc/init.d/started as well + that should make it shutdown properly right away + my halt still hang. + pere: you have /lib/rc/init.d in both /etc/init/umountfs and + /lib/rc/init.d/started/umountfs and there are no umountfs.* around? + problem seems to be it picks first it finds if there are more than + one + well i could have been more precise: /lib/rc/init.d/started/umountfs + is a link to /etc/init.d one + btw there must be just one and only one umountfs, patched + pere: clean /etc/init.d, reboot/halt with reboot-hurd or halt-hurd, + then next sysv reboot/halt will be good + you just need to leave patched umountfs under /etc/init.d alone + patch has always been good, it just needs 2 reboots to be appreciated + pere: do you have other /etc/init/umountfs* files besides patched + one? + my guess is it takes the first and only the first which Provides: + umountfs + 12:17 < pere> why are these files not ignored? + 12:35 < gg0> my guess is it takes the first and only the first which + Provides: umountfs + to confirm that, if you have umountfs and umountfs.orig, under + /started you'll find just umountfs.orig + pere: how goes? + teythoon: last ~40 lines + i'm assuming you have any else umountfs.* under /etc/init.d. if you + just add /lib/rc/init.d path to the only umountfs there should not be any + problem + gg0: removing the umountfs.* files did not help, as far as I can + tell. + are you telling me that openrc caches all init.d scripts in + /lib/rc/init.d/ at boot? + pere: yes, you can see them. which umountfs* do you have under + /lib/rc/init.d ? + the right one. :) + only the right one? + just scared me to know that changes on the disk do not take effect + immediately with openrc. + pere: only the right one? + yes + here i screwed it up by forcing initscripts removal and reinstall to + reproduce it, then fixed it once again + i should just improving the explaination :) + pere: "removing the umountfs.* files did not help," so did you find + any? + yes, both .orig, .rej and .dpkg-old + pere: ok you should find one of them linked under + /lib/rc/init.d/started then + /lib/rc/init.d/started/umountfs.* + I removed them three boots ago. still halt hangs. + pere: and current umountfs have /lib/rc/init.d in path list? + *has + yes. + pere: can you access via ssh to it before issuing halt? + that is how I access it normally. + ok + before halt df should list /lib/rc/init.d as well + after halt it should not, do you confirm that? + (ssh connection here is kept alive) + my ssh connection went down, but /lib/rc/init.d was mounted while it + was active. + to me it look like umountfs isn't executed at all during shutdown. + oh, well. got to work on other things now. :) + it's correct getting no messages if there no filesystem to umount + as it wouldn't be run at all + pere: Hey, thanks for uploading sysv-rc -48 ! :) + you are welcome. :) + i can't reproduce it on a VM :/ http://paste.debian.net/plain/80658/ + ehm no, same machive, successive halt + http://paste.debian.net/plain/80659/ + got stuck + are there any testet sysvinit patches for hurd lingering? I plan to + upload a new version tonight or tomorrow. + + +## IRC, OFTC, #debian-hurd, 2014-02-08 + + http://paste.debian.net/plain/80854/ + expected? + do tmpfs and procfs need to be shown as types /hurd/tmpfs and + /hurd/procfs? + or can they be "normalized"? + domount mount_noupdate tmpfs shmfs /run tmpfs + -onosuid,noexec,size=10%,mode=755 + another one is why on linux options are nosuid,noexec ^, whereas on + hurd no-suid,no-exec,... ? + gg0: If they need generalising, we can add $nosuid/$noexec + etc. variables to mount-functions.sh and set them appropriately for the + currently platform. + current platform rather + yeah, i ask just to understand what side people prefers modifying, in + this case hurd vs sysvinit + btw in the meanwhile i got tmpfs takes options without '-' though it + shows them with '-' in proc/mounts + rleigh: and thanks for pointing out what looking for, little hints + saves hours in my case :) + [IRC connection closed] + + +## IRC, freenode, #hurd, 2014-02-08 + + gnu_srs: the -49 version of sysvinit contains a fix for bootlogd + + +### IRC, freenode, #hurd, 2014-02-09 + + (16:31:17) : gnu_srs: the -49 version of sysvinit contains + a fix for bootlogd + Nice for kFreeBSD, for Hurd it doesn't matter if we get a + segfault or an error code saying it's not implemented :-( + segfault vs error code is really not the same + iirc bootlogd would ignore the error + Nevertheless, bootlogd is not usable on Hurd :( + then fix it + + +## IRC, OFTC, #debian-hurd, 2014-02-08 + + gg0: If the sames are set by hurd itself, then it makes sense to + adapt sysvinit to cope with that rather than altering hurd since that + would be a fairly major compatibility break. OTOH, adding support for the + Linux/FreeBSD names in addition to the hyphenated names would be good + from the point of view of better interoperability generally, not just for + sysvinit. + For now, getting sysvinit to support the Hurd names is easy + enough, and if you do add the Linux/FreeBSD names then the compatibility + stuff can be removed when that's available. + + +## IRC, freenode, #hurd, 2014-02-11 + + Hi, still problems with hurd console under openrc: console: + Console library initialization failed: Not a directory + and /dev/vcs is there + gnu_srs: but is it a directory? + the output of console -d vga -d pc_mouse --repeat=mouse -d pc_kbd + --repeat=kbd -d generic_speaker -c /dev/vcs gives the response above + looks like /dev/vcs is a file. How to recreate the directory + content? + I thought it should not be removed with the latest sysvinit + package (-49) + from -48 changelog: Tell init.d/umountfs to not umount /dev/vcs, + as it break the console on Hurd. Patch from Samuel Thibault. + gnu_srs: but did your reconfigure the hurd package to remount it ? + ? + /dev/vcs won't magically be remounted by just not being unmounted + by sysvinit + dpkg-reconfigure hurd? + sure + I can start the console manually, but ENABLE='true' in + /etc/default/hurd-console does not work (at least with openrc) + does /dev/vcs becomes a mere file again with openrc? + no it's a directory with 6 entries + does the /etc/init.d/hurd-console gets to starT? + I'm afraid I'm really asking obvious questions that you should have + already asked for yourself + so you mounted it and it's not a file anymore. does it work now? + it seem like the service is not started, trying to figure out + why:-D + I can restart it but it is not visible in rc-status? + + shutdown stuck at "Asking all remaining processes to + terminate...done." (even before distupgrade btw) + seems stuck at killall5 -18 + hm, that's bad + how do you know that ? + /etc/init.d/sendsigs and /etc/init.d/killprocs + (yes, switched to sysvinit and testing openrc) + but killall5 -18 is SIGSTOP right? + and if it says ...done. then killall5 has already been run + so, how do you know it hangs at killall5 ? + teythoon: "done" is "log_action_end_msg 0" just after killall5 -15, + then we should get "Killing all remaining processes" or "All processes + ended within $seq seconds." + Asking all remaining processes to terminate...killall5 -15 -o 956 # + SIGTERM...done. + All processes ended within 1 seconds...done. + shutdown properly this time + hm + fwiw, i've also encountered hangs, haven't investigated yet + with openrc? + yes + + Is it so that with teythoons mtab translator umount -a unmounts + all passive translators, removing the translator records?? + causing pflocal (and pfinet) to disappear? + +[[hurd/translator/mtab/discussion]]. + + gnu_srs: didn't he say that this is getting fixed in his latest + patchset? + yes, what about mine and gg0s currently hosed systems? + yes, but until the patch makes into the next release,** + gnu_srs: pflocal and pfinet don't appear in mtab + because they don't expose whole directories, just a trivial node + so no, they won't get umounted by umount -a + simply check the content of /proc/mounts + so how come I cannot recover my image? + and gg0 neither + no idea, I've never tried openrc + when daring new fields, you face new issues, that's no wonder + so this does not happen with sysv-rc? + I haven't seen any of this kind of issue + whether it's related to using openrc vs sysvrc, I have no idea + but at least that's a candidate for sure + well in my case hurd bootstrap is stuck after ext2fs exec and + before init + ant reinstalling hurd via linux does not help + you mean the hurd package? + you can also try to reinstall the libc0.3 package + normally it should be all that is needed for boot + perhaps also some /dev entries + yes, the hurd package. I will try with libc0.3 tomorrow. Which + /dev entries, and how to create them manually? + "perhaps" implies that I don't know + you can as well just boot with an install CD, mount your disk, + chroot into it, and run dpkg-reconfigure hurd there to recreate + everything in /dv + +e + + +## IRC, OFTC, #debian-hurd, 2014-02-13 + + pere, rleigh: which script is supposed to make /etc/mtab a symlink + to /proc/mounts already? I can't find it + youpi: see /lib/init/mount-functions.sh + + +## IRC, freenode, #hurd, 2014-02-13 + + teythoon: are the sysvinit debian packages in sid usable currently + ? + they are + nice + youpi and pere have been busy polishing it quite a bit + teythoon: and uhm, how does one enable sysvinit in debian ? :) + ah, found pere's blog + braunr: didn't you read the postinst instructions ? :p + update-alternatives --config runsystem + oh right + got lost in the noise + very nice + still a few glitches i see, but it does the job + although i'm not sure i like the lack of console prompt :/ + i'll keep darnassus on the old runsystem until this is fixed + braunr: cp -p /usr/share/sysvinit/inittab /etc/inittab + and kill -HUP 1 + oh + :) + teythoon: thanks + teythoon: do you know why there are three tmpfs instances after + startup (/run, and in addition, /run/shm and /run/lock) instead of one on + /run ? + sorry for being so annoying :) + braunr: dunno, but that is what Debian does + https://wiki.debian.org/ReleaseGoals/RunDirectory explains it a + bit + root@thinkbox ~src # uname -s; mount | grep /run + Linux + tmpfs on /run type tmpfs + (rw,nosuid,noexec,relatime,size=306952k,mode=755) + tmpfs on /run/lock type tmpfs + (rw,nosuid,nodev,noexec,relatime,size=5120k) + tmpfs on /run/shm type tmpfs + (rw,nosuid,nodev,noexec,relatime,size=613900k) + i like this /run directory + yep, it's nice + ah great, i can add ,sync=30 to fstab and it's added at boot time + :) + + +## IRC, freenode, #hurd, 2014-02-17 + + hi, I think we should make console server separate from + hurd-console + if DM want start, console server need be start first + congzhang: send patches + and hurd-console mark it start at the end of sysinit? + congzhang: i agree + teythoon: isn't hurd-console the console server ? + I want to check whether it is need first + braunr: yes, but congzhangs point is (as i understand it) that + the backend component should be started earlier + then again, i know little about the hurd console + no, if user enable one dispaly manager, then cycle dependence + happen + why ? + i believe that is a different problem, namely that our + hurd-console init script depends on $all + pere: ^ + hurd-console Required-Start： $all + ok + yes that's a separate issue, and easier to understand + teythoon: if wdm Required-Start hurd-console, then insserv + can't generate the script order, right ? + congzhang: possibly, i don't know for sure + It doesn't work , and I rename to S??wdm to later one like + S20wdm + but insserv will regenerate the script order in /etc/rc2.d/, I + can't depend on that + congzhang: $all means after all scripts not depending on $all, and + not what the intuitive interpretation would tell you. + the current implementation order all scripts as if $all were not + present, and then move all scripts depending on $all to the last order + number+1. + because $all is misunderstood by most users, I strongly recommend to + _not_ use $all in any init.d script. + pere: so to make wdm to be number+more? + congzhang: make it depend on $all and be lexically sorted after + hurd-console. :) + wdm need start after hurd-console, if console-driver will run + when hurd-console start + not quite sure how startpar handle that case, so it might not work + the way you want anyway. + adding a dependency on hurd-console should not hurt, though. :) + how make it lexically sorted after hurd-console? + w is already after h in the alphabet. :) + that's trick! + but startpar uses the info in /etc/init.d/.depend.* (makefile style) + to order scripts, so check what the result is there too. + congzhang: no it's not + that's just cache + congzhang: ? + and generated from script head? + the right way is Adding run-time dependencies in script + congzhang: yes. insserv called from update-rc.d generate the + .depend.* files, and startpar reads the files (and ignore the headers) + when starting scripts. + if the script have cycle dependence, no one can help + congzhang: if there is a cycle, update-rc.d will reject the script. + sure, because the system current have not runable one + Display Manager run before hurd-console, and never successful + for X stared failed! + what is this hurd-console stuff, btw? it sound like somthing that + should be started in rcboot.d (aka rcS.d on Debian). + if you install wdm, you will notice that wdm start failed + should it run before sulogin when booting into single user? + hurd-console mix too much thins + pere: it's the console multiplexes that provides /dev/tty? + just part of that function + pere: it's like screen or tmux a server-client architecture + the x server gets keyboard and mouse events from it iirc + right. so not needed by sulogin, I guess. because if it was, it + should start in rcS.d, not rc[2-5].d/. + and also start /bin/console to start keyboard and mouse driver + /bin/console is the frontend + and if it started in rcS.d/, it would always be started before + wdm. :) + i think it should be started in rcS.d + why not essential? + braunr: when I tried, it failed. + https://www.gnu.org/software/hurd/hurd/console.html + teythoon: i want to make one disk img with default DM, and face + these problem + pere: do you have a log of the failur e? + teythoon: I know you are working on the hurd init system, so I + ask you for help + braunr: only the boot message: Starting Hurd console multiplexer: + hurd-console failed! + braunr: how can I learn more? + i don't know any easy way + try to put the system in its early state manually + and maybe run rpctrace on the actual console command + if that is what really fails + and I found that pc_kbd may have some bug? I have high + frequence of start failed if I make it start + but I can't located the real source of these problem + pere: the console logs some messages to syslog + teythoon: looked, nothing there. :( + gah, look like I broke my hurd machine. Added rpctrace to the start + of hurd-console, and now the boot just hang there, and when I interrupt + it the kernel reboot the entire machine. :( + pere: use rpctrace manually, don't script it + oh yeah, seen this as well + braunr: well, no use to test it after boot when it hang during + boot... + it triggers an assertion in the proc server iirc + pere: that doesn't imply you need to script it + pere: qemu snapshot mode will be your friend:) + ideally, i'd run the init system automatically up to the point i + want to run my test, and make it spawn a shell, and use that shell then + congzhang: hah. real men do to take backups. but they weep a + lot. :) + teythoon: runsystem.sysv has work well on my machine, just some + error infomation + good + + +## IRC, freenode, #hurd, 2014-02-21 + + Hi, a general question: is ptrace available for GNU/Hurd? + yes + tks, the openrc developers are working on process supervision + using it: good/bad? (compared to cgroups) + uh + i prefer the cgroups approach + but upstart also uses ptrace to keep track of the 'main' process + of an daemon + they use ptrace to follow a daemon that double forks + teythoon: and regarding portability? + + +## IRC, freenode, #hurd, 2014-02-24 + + sysvinit doesn't seem to handle /etc/default/locale into + consideration + + +## IRC, OFTC, #debian-hurd, 2014-02-25 + + how about switching runsystem.sysv by default? + now that it seems to be running fine, we could do that, yes + + +# Required Interfaces + +In the thread starting +[here](http://lists.debian.org/debian-devel/2011/07/threads.html#00269), a +[message](http://lists.debian.org/debian-devel/2011/07/msg00281.html) has been +posted that contains the following list (no claim for completeness) of +interfaces that are used in (two source code files of) systemd: + + * cgroups + * namespaces + * selinux + * autofs4 + * capabilities + * udev + * oom score adjust + * RLIMIT_RTTIME + * RLIMIT_RTPRIO + * ionice + * SCHED_RESET_ON_FORK + * /proc/$PID/stat + * fanotify + * inotify + * TIOCVHANGUP + * IP_TRANSPORT + * audit + * F_SETPIPE_SZ + * CLONE_xxx + * BTRFS_IOC_DEFRAG + * PR_SET_NAME + * PR_CAPBSET_DROP + * PR_SET_PDEATHSIG + * PR_GET_SECUREBITS + * /proc/$PID/comm + * /proc/$PID/cmdline + * /proc/cmdline + * numerous GNU APIs like asprintf + * [[SOCK_CLOEXEC, O_CLOEXEC|secure_file_descriptor_handling]] + * /proc/$PID/fd + * /dev/tty0 + * TIOCLINUX + * VT_ACTIVATE + * TIOCNXCL + * KDSKBMODE + * /dev/random + * /dev/char/ + * openat() and friends + * /proc/$PID/root + * waitid() + * /dev/disk/by-label/ + * /dev/disk/by-uuid/ + * /sys/class/tty/console/active + * /sys/class/dmi/id + * /proc/$PID/cgroup + * \033[3J + * /dev/rtc + * settimeofday() and its semantics -- cgit v1.2.3