[[!meta copyright="Copyright © 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_documentation open_issue_hurd]] [[!toc]] # IRC, freenode, #hurd, 2011-11-18 I'm learning about GNU Hurd and was speculating with a friend who is also a computer enthusiast. I would like to know if Hurds microkernel can recover services should they crash? and if it can, does that recovery code exist in multiple services or just one core kernel service? nocturnal: you should read about passive translators basically, there is no dedicated service to restore crashed servers Hi everyone! services can crash and be restarted, but persistence support is limited, and rather per serivce actually persistence is more a side effect than a designed thing etenil: hello braunr: translators can also be spawned on an ad-hoc basis, for instance when accessing a particular file, no? that's what being passive, for a translator, means ah yeah I thought so :) # Reincarnation Server ## IRC, freenode, #hurd, 2011-11-19 will hurd ever have the equivalent of a rs server?, is that even possible with hurd? chromaticwt: what is an rs server ? a reincarnation server ah, like minix. Well, the main ground issue is restoring existing information, such as pids of processes, etc. I don't know how minix manages it chromaticwt: I have a vision of a session manager that could also take care of reincarnation... but then, knowing myself, I'll probably never imlement it we do get proc crashes from times to times it'd be cool to see the system heal itself :) i need a better description of reincarnation i didn't think it would make core servers like proc able to get resurrected in a safe way depends on how it is implemented I don't know much about Minix, but I suspect they can recover most core servers essentially, the condition is to make all precious state be constantly serialised, and held by some third party, so the reincarnated server could restore it should it work across reboots ? I haven't thought about the details of implementing it for each core server; but proc should be doable I guess... it's not necessary for the system to operate, just for various UNIX mechanisms well, I'm not aware of the Minix implementation working across reboots. the one I have in mind based on a generic session management infrastructure should though :-) ## IRC, freenode, #hurd, 2012-12-06 out of curiosity, would it be possible to strap on a resurrection server to hurd? in the future, that is sure cool :) but this requires things like persistence like a reincarnation server? it's a lot of works, with non negligible overhead spiderweb: yes, exactly. I didn't remember tanenbaum's wording on that i'm pretty sure most people would be against that braunr: why so? it was actually the feature that convinced me that ukernels were a good idea spiderweb: because then you need a process that keeps track of all the other servers and they have to be replying to "useless" pings to see if they're still alive spiderweb: the hurd community isn't looking for a system reliable in critical environments just a general purpose system and persistence requires regular data saves it's expensive as well as that we already have performance problems because of the nature of the system, adding more without really looking for the benefits is useless so you can't theoretically have both? persistence and performance ? it's hard spiderweb: you need to modify the other translators to be persistent only the ones you care about actually but it's just better to make the critical servers very stable so it's not just turning on and off the reincarnation (there isn't that much code there) and the other servers restartable braunr: I think that if there will be aim to make something like resurrection server than it will be needed rewrite most servers to make them stateless, isn't it? that's a lot easier and already works with non essential passive translators mcsim: pretty much mcsim: only those you care about mcsim: the proc auth exec servers for example, perhaps the file system servers that can act as root fs, but the others would simply be restarted by the passive translator mechanism what about restarting device drivers, that would be simple right? that's perfectly doable, yes (being an OS newbie) - it does seem to me that the whole reincarnation server concept could quite possibly be a band aid. spiderweb: no it really works many systems do that actually let me give you a link http://ftp.sceen.net/curios_improving_reliability_through_operating_system_structure.pdf it's a bit old, but there is a review of systems aiming at resilience and how they achieve part of it neat, thanks actually it's not that old at all around 2007 ## IRC, freenode, #hurd, 2013-08-26 < teythoon> I came across some paper about process reincarnation and created a little prototype a while back: < teythoon> http://darnassus.sceen.net/cgit/teythoon/reincarnation.git/ < teythoon> and I looked into restarting the exec server in case it dies. the exec server is an easy target since it has no state of its own < teythoon> the only problem is that there is no exec server around to start a new one < youpi> teythoon: there could be another exec server only used to (re)start the exec server < youpi> that other exec server could even be restarted by the normal exec server < pinotree> what about a watchdog server? < teythoon> youpi: yes, I had the same idea, i actually patched /hurd/init to do that, it's just not yet working < pinotree> make it watch other servers (exec included), and make exec watch the watchdog only < teythoon> pinotree: look at my prototype, there is a watchdog server < braunr> teythoon: what's the point of reincarnation without persistence ? < teythoon> braunr: there is no point in reincarnation w/o persistence of course < teythoon> my prototype does a limited form of persistence < teythoon> the point was to see whether I can mitm a translator and restart it on demand and to gain more insight into the whole translator mechanism < braunr> teythoon: ok < teythoon> braunr: see the readme, it retains state across reincarnations < braunr> teythoon: how ? < teythoon> braunr: the server can store a checkpoint using the reincarnation_checkpoint procedure < teythoon> http://darnassus.sceen.net/cgit/teythoon/reincarnation.git/blame/HEAD:/reincarnation.defshttp://darnassus.sceen.net/cgit/teythoon/reincarnation.git/blame/HEAD:/reincarnation.defs < teythoon> uh >,< sorry, pasted twice < braunr> oh ok ## IRC, freenode, #hurd, 2014-02-01 btw, can hurd upgrade the kernel without reboot? no but since most functionality is not within the kernel, the more interesting question is, what parts of the hurd can be replaced at runtime ok. what is the answer to that question? no hurd server can be restarted transparently, i.e. w/o its clients noticing that however, if a server is not in use, it can be easily restarted transparently restarting servers would be nice and i believe it is even possible on mach teythoon: how ? one has to retain two things, client-related state and the port right doesn't that require persistence ? it does but i see no reason why it should not be possible to implement this on top of mach maybe the most crucial thing is to preserve the receive port, and to replace the server without race-conditions receive rights can be transfered using the notification mechanism braunr: restarting servers doesn't exactly require persistance. you only need to pass the state from the old server to the new one, rather than serialising it for on-disk storage. it's a slightly easier requirement... (most notably, you don't need any magic to keep the capabilities around -- just pass them over using normal IPC) antrik: i agree, but then again, once this is in place, adding persistence is only a little step teythoon: depends. if it's implemented with persistence in mind from the beginning, it might be a fairly small step indeed; but otherwise, it could be two entirely different things this also depends on the kind of persistence you want I must say that for the kind of persistence *I* would like, it is indeed quite related well, please elaborate a little :) what do you have in mind ? busy right now... remind me some other time if I forget :-) sure