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 --- open_issues/systemd.mdwn | 3694 ---------------------------------------------- 1 file changed, 3694 deletions(-) delete mode 100644 open_issues/systemd.mdwn (limited to 'open_issues/systemd.mdwn') diff --git a/open_issues/systemd.mdwn b/open_issues/systemd.mdwn deleted file mode 100644 index d2506046..00000000 --- a/open_issues/systemd.mdwn +++ /dev/null @@ -1,3694 +0,0 @@ -[[!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