[[!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