diff options
Diffstat (limited to 'hurd/translator')
| -rw-r--r-- | hurd/translator/auth.mdwn | 231 | ||||
| -rw-r--r-- | hurd/translator/discussion.mdwn | 189 | ||||
| -rw-r--r-- | hurd/translator/examples.mdwn | 4 | ||||
| -rw-r--r-- | hurd/translator/ext2fs.mdwn | 364 | ||||
| -rw-r--r-- | hurd/translator/fifo.mdwn | 6 | ||||
| -rw-r--r-- | hurd/translator/magic.mdwn | 262 | ||||
| -rw-r--r-- | hurd/translator/mtab/discussion.mdwn | 958 | ||||
| -rw-r--r-- | hurd/translator/pfinet/implementation.mdwn | 180 | ||||
| -rw-r--r-- | hurd/translator/pflocal.mdwn | 41 | ||||
| -rw-r--r-- | hurd/translator/proc.mdwn | 73 | ||||
| -rw-r--r-- | hurd/translator/procfs/jkoenig/discussion.mdwn | 169 | ||||
| -rw-r--r-- | hurd/translator/term.mdwn | 220 | ||||
| -rw-r--r-- | hurd/translator/tmpfs/discussion.mdwn | 73 | ||||
| -rw-r--r-- | hurd/translator/unionfs.mdwn | 8 | ||||
| -rw-r--r-- | hurd/translator/wishlist.mdwn | 11 |
15 files changed, 2710 insertions, 79 deletions
diff --git a/hurd/translator/auth.mdwn b/hurd/translator/auth.mdwn index 7fd4832c..68bbce44 100644 --- a/hurd/translator/auth.mdwn +++ b/hurd/translator/auth.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 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 @@ -8,7 +9,8 @@ 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]]."]]"""]] -The *auth server* (or, *authentification server*). +The *auth server* (or, *authentification server*) is a key component managing +[[authentication]] in a Hurd system. It is stated by `/hurd/init`. @@ -18,3 +20,228 @@ It is stated by `/hurd/init`. [[*The_Authentication_Server*|documentation/auth]], the transcript of a talk about the details of the authentication mechanisms in the Hurd by Wolfgang Jährling. + + +## IRC, freenode, #hurd, 2013-10-31 + +[[!tag open_issue_documentation]] + + <braunr> is there an in-depth documentation somewhere about the auth server + that explains why there are "reauthenticate" operations everywhere ? + <braunr> nice, hammar's thesis does it :) + +[[hurd/documentation]], *Generalizing mobility for the Hurd*, Carl Fredrik +Hammar. + + +## IRC, freenode, #hurd, 2013-11-01 + + <gnu_srs> neal: Thanks, I'm trying to to call auth_server_authenticate + from a libc function, but that fails. That function returns MIG_NO_REPLY. + <gnu_srs> auth_user_authenticate works OK, but I need the IDs from the + auth_server_authenticate. What to do, implement a new RPC, + <gnu_srs> modify auth_user_authenticate (probably not) ? + <gnu_srs> or modify auth_server_authenticate (probably not) + <youpi> gnu_srs: show the source code you have written. MIG_NO_REPLY is not + expected, unless you called server_authenticate on the wrong port + <gnu_srs> S_auth_server_authenticate does not have any other exits than + MIG_NO_REPLY (and errors) + <gnu_srs> auth/auth.c + <youpi> yes, but it does do auth_server_authenticate_reply, which is what + matters + <youpi> i.e. what provides the answer + <youpi> (and the uids etc.) + <gnu_srs> I don't seem to be able to call that function directly from libc? + <youpi> eh? You're not supposed to call auth_server_authenticate_reply + yourself, it's auth which is supposed to + <youpi> precisely to provide the reply to the auth_server_authenticate RPC + <youpi> again, please show your source code + <youpi> there must be some mistake + <gnu_srs> Please show me how to call auth_server_authenticate and that + function returning 0 + <youpi> there are plenty of examples in the hurd source code + <youpi> e.g. ext2fs + <youpi> or libdiskfs, I can't remember where it is exactly inside ext2fs + <gnu_srs> I've tried all, on avail:( + <gnu_srs> no* + <youpi> € git grep auth_server_auth + <youpi> libiohelp/iouser-reauth.c: err = auth_server_authenticate + (authserver, + <youpi> was it so hard? + <gnu_srs> I did, and tried every combination, nothing works! + <youpi> something has to work, otherwise we'd have no uid authentication + against ext2fs + <youpi> so there must be a combination you missed + <youpi> did you understand how the authentication protocol works, for a + start? + <youpi> otherwise, random code will most probably never work, for sure :) + <gnu_srs> called from libc? + <gnu_srs> a libc function? + <youpi> being from a libc function or from an io_reauthenticate callback + does not really matter + <gnu_srs> well, random or not, please show me then + <youpi> it's already there in ext2fs + <youpi> again, if you don't understand *that* code, no need to try to write + other code, take time to understand what exactly happens in the ext2fs + case + <gnu_srs> ok, can you tell me how a function only returning MIG_NO_REPLY + can return 0 when called? + <gnu_srs> by a server or client + <youpi> maybe one thing you are missing: in the ext2fs case, we have the + sender use io_reauthenticate to provide the receiver (ext2fs) with the + reference port, in the sendmsg/recvmsg, it'll be the message which will + hold the ref port + <youpi> but otherwise it's all the same + <youpi> gnu_srs: as I said, by being called on the proper port, + <youpi> i.e. the auth port, with the ref port provided by the sender + <youpi> but again, without seeing your code, I can't divine what mistake + you may have done + <youpi> all I can do is that your code is supposed to really look very much + like the ext2fs case + <gnu_srs> there is a difference between io_reauthenticarte and + proc_reauthenticate, a subsequent call to auth_user_authenticate returns + 0 in the second case. + <youpi> i.e. _hurd_setauth in hurd/setauth.c and iohelp_reauth in + libiohelp/iouser-reauth.c + <youpi> why are you talking about io_reauthenticate an proc_reauthenticate? + <youpi> again, without seeing your source code, I can't understand what you + are talking about + <gnu_srs> first: (17:06:23) srs: ok, can you tell me how a function only + returning MIG_NO_REPLY can return 0 when called? + <youpi> and I can't afford the time to divine + <youpi> yes, that's iohelp_reauth in libiohelp/iouser-reauth.c + <youpi> for an example that works + <youpi> by using the proper ports + <youpi> if you don't get a reply, it's most probably simply because the + reply goes to the wrong port + <gnu_srs> again, where/how is the return value communicated by + auth_server_authenticate to the client/caller? + <youpi> again, it's the auth/auth.c code + <youpi> which calls auth_server_authenticate_reply + <gnu_srs> but that function ends with return MIG_NO_REPLY? + <youpi> yes, because auth_server_authenticate_reply() already did provide + the reply + <youpi> so the RPC function does not return a reply + <youpi> since it already explicitly sent one + <youpi> through auth_server_authenticate_reply + <gnu_srs> and exits earlier? + <youpi> it doesn't exit earlier + <youpi> it first calls auth_serveru_authenticate_reply + <youpi> and then returns with MIG_NO_REPLY + <gnu_srs> how the fck should i know that? + <youpi> by reading MIG documentation? + <youpi> I believe that _request/_reply mechanism is documented there + <gnu_srs> MIG magic again:( It strikes back, whatever you do to avoid it + <youpi> at least I don't think I have divined how it was working, so I must + have read that in some documentation + <youpi> it's not magic + <youpi> you just have to read the doc to understand how it works + <gnu_srs> I've not found any good doc on MIG yet. + <youpi> depends what you call "good" + <youpi> MIG is a complex thing, so documentation is complex, yes + <youpi> that can't really be avoided + <gnu_srs> mig.pdf + <gnu_srs> again: how can a function returning MIG_NO_REPLY return 0 when + called (as current implementations show)? + <youpi> again, by using the proper ports + <youpi> if not using the proper ports, the reply goes to another port + <youpi> and thus no reply + <youpi> and again, without showing the source code, we can't divine how you + didn't use the proper ports + <gnu_srs> so you mean a reply to a port is the same as the error code + returned? + <youpi> not always exactly, but basically yes + <youpi> gnu_srs: *again* , *really*, showing us what you've come up with + would very *most* probably allow us to help you + <youpi> otherwise it's just guess work and misunderstandings + <gnu_srs> FYI: there is no libc function calling auth_server_authenticate + directly + <youpi> sure + <youpi> that doesn't mean it can't + <gnu_srs> and here is one code example, not even trying to send+receive, it + is only in recvmsg.c: http://paste.debian.net/63374/ + <youpi> why is that code doing both auht_user_auth and auth_server_auth ? + <youpi> it's the sender side which is supposed to call auth_user_auth + <youpi> and why are you calling proc_reauthenticate, that has nothing to do + with the matter at stake + <gnu_srs> sorry, you can remove that part, same result + <youpi> ok but auth_user_authenticate should really go to the sender side + <youpi> s/should/must + <youpi> it is supposed to hang until auth_server_authenticate gets called + by the receiver + <youpi> so putting both on the receiver can not work + <youpi> at best auth_user_authenticate would hang, waiting for the + auth_server_authenticate which is called just after that... + <youpi> don't try random code, that can't work + <youpi> follow what I said + <youpi> in my mail + <gnu_srs> I did issue auth_user_authenticate on the send side, and + auth_server_authenticate on the receive side. + <gnu_srs> that was the path I followed, then when nothing worked,. I tried + the receive side only. + <youpi> that's why I said don't try random code + <youpi> it can't work with receive side only + <youpi> really, go as I said + <youpi> send / receive + <youpi> there must be something you made wrong + <gnu_srs> in the beginning it was not random code;) + <youpi> but it's not a reason for stabbing in the dark with random code, + that just can't work + <youpi> then stay with the code at the beginning + <youpi> and don't start writing random code + <youpi> that approach can *not* work + <gnu_srs> still when issuing __proc_reauthenticate followed by + auth_user_authenticate on the send side the port delivered is 0, + i.e. unusable + <youpi> why calling proc_reauthenticate?? + <youpi> it has nothing to do with the auth_*_authenticate protocol + <youpi> really + <youpi> what made you believe it was part of it? + <gnu_srs> dunno, if you say so;) + <youpi> it's not even mentioned in the documentation I referred to in my + mail + <youpi> again, make sure you actually *understand* the auth_*_authenticate + protocol + <gnu_srs> I found it in the already implemented code. + <gnu_srs> and process.defs + <youpi> for the proc_authenticate protocol, sure + <youpi> but that has nothing to do with the auth_*_authenticate protocol + <gnu_srs> well, the hurd documentation does not cover the proc case only + the io case, unfortunately:( Marcus, please write more documentation:-D + <youpi> it's just the same + <youpi> exactly the same + <youpi> ok, now I understand what happend: you followed some code which was + doing the auth protocol with the proc translator, not with the ext2fs + translator + <youpi> and you had *not* understood what proc_reauthenticate was doing + there + <youpi> you should have followed some code which was doing the auth + protocol with the ext2fs translator, i.e. through io_reauthenticate, of + course + <youpi> if you read random code, there's no way you can understand it of + coruse + <youpi> again, read hurd/setauth.c + <youpi> it does the reauthentication with ext2fs, through io_reauth to give + the ref prot + <youpi> s/prot/port + <youpi> io_reauth has to be replace with a port send over the socket of + course + <youpi> if that's obvious, don't write code, and ask yourself whether you + have really understood the auth protocol at all + <youpi> s/that's obvious/that's not obvious/ + <youpi> understand means being able to match the source code of setauth.c + with the explanation from marcus + <gnu_srs> I'm learning all the time, in a few years I will be able to + contribute seriously;-) but the MIG stuff, I dunno:( + <youpi> well, the problem is that it takes us a hell lot of time to explain + you things + <youpi> just because you don't seem to manage to learn without going + randomly + <gnu_srs> just reading source code is a random process, unfortunately. + <youpi> ?! + <youpi> sure not + <youpi> if you do it randomly, then it's not wonder you're getting random + <youpi> don't read it randomly + <youpi> follow paths + <youpi> I've never read code randomly, it's a loss of time and a way to + just mix everything together without understanding anything diff --git a/hurd/translator/discussion.mdwn b/hurd/translator/discussion.mdwn index e038ba84..70a6efee 100644 --- a/hurd/translator/discussion.mdwn +++ b/hurd/translator/discussion.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!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 @@ -10,7 +11,10 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation open_issue_hurd]] -IRC, freenode, #hurd, 2011-08-25: +[[!toc]] + + +# IRC, freenode, #hurd, 2011-08-25 < frhodes> how can I replace an existing running server with a new one without rebooting? @@ -23,3 +27,184 @@ IRC, freenode, #hurd, 2011-08-25: nature < antrik> in some cases, you might even be able simply to remove the old translator... but obviously only for non-critical stuff :-) + + +# IRC, freenode, #hurd, 2013-10-21 + + <braunr> mhmm, there is a problem with thread destruction + +[[open_issues/libpthread/t/fix_have_kernel_resources]]. + + <braunr> actually, translator self destruction + <braunr> if a request arrives after the last thread servicing a port set + returns from mach_msg because of a timeout, but before the translator is + detached from its parent, the client will get an error + <braunr> it should very rarely happen, but if it does, we could face the + same kind of issues we have when a server crashes + <braunr> e.g. sshd looping over select() returning EBADF, consuming all cpu + <braunr> not sure we want to introduce such new issues + + <braunr> i don't think i'll be able to make translators disappear reliably + .. + <braunr> but at least, thread consumption will correctly decrease with + inactivity + + +# IRC, freenode, #hurd, 2014-01-30 + + <sjbalaji> can any one exmplain me hello translator ? I am new to hurd + <teythoon> sjbalaji: sure, what do you want to know ? + <teythoon> how to use it ? + <sjbalaji> No I mean what is the main reason of that translator. I am + familiar with Linux. + <gnu_srs> sjbalaji: start with: + https://www.gnu.org/software/hurd/hurd/documentation/translator_primer.html + <sjbalaji> I ran that example but I am still clueless about the actual + reason behind the translators and this simple hello world translator + example. + <teythoon> sjbalaji: the Hurd is a multiserver os, almost all functionality + lives in userspace servers called 'translators' + <teythoon> sjbalaji: the Hurd uses the file system as namespace to lookup + these servers + <teythoon> e.g. /servers/socket/1 is /hurd/pflocal and handles pipes and + unix socket communication + <sjbalaji> I can see from the example that a hello file is associated with + a /hurd/hello translator + <teythoon> yes + <teythoon> think of translators like FUSE-based filesystems, only more + general + <teythoon> b/c translators are not restricted to provide filesystem-like + services + <sjbalaji> So this example hello translator just adds hello world in the + associated file, am I correct ? + <teythoon> it's not adding stuff to a file + <teythoon> say you did settrans -ac /tmp/hi /hurd/hello, if you do cat + /tmp/hi, cat does some rpc calls to the started /hurd/hello program that + returns 'hello world' as the file contents + <teythoon> in a sense /hurd/hello is a 'filesystem' that provides a single + file + <sjbalaji> So is it like hello is the mount moint for that hello server ? + <teythoon> sjbalaji: yes, kind of that, but in a more general sense + <sjbalaji> teythoon: How can I see the different servers that are running + in the system ? I tried top in the terminal but it returned cannot find + /proc/version + <teythoon> sjbalaji: so it seems your procfs is not running, try as root: + settrans /proc /hurd/procfs -c + <sjbalaji> teythoon: But how does one differentiate between a server and a + normal process ? + <teythoon> one does not + <teythoon> for a rule of thumb: anything from /hurd is a translator + <teythoon> you can view a nodes passive translator record using showtrans, + e.g. showtrans /dev/hd0 + <sjbalaji> Is there something like a man page for translators ? Like how to + work with them or to figure out what services are offered by them ? + <teythoon> well, there is --help + <teythoon> also, go to /dev and /servers and look around using showtrans or + fsysopts + <sjbalaji> teythoon: What is the difference between a nodes active and + passive translator ? + <teythoon> a passive translator record is stored in the file system for the + node + <teythoon> if the node is accessed, and no translator is currently running, + it is started on demand + <teythoon> we call a running translator an active one + <sjbalaji> So the hello translator in the example is a passive one ? + <teythoon> if you used settrans foo /hurd/hello, a node foo is created with + an passive translator record + <teythoon> if you used settrans -a foo /hurd/hello, the translator is + started immediately + <sjbalaji> teythoon: What do you mean by a passive translator record ? + <teythoon> sjbalaji: it's an argv-vector encoded in the filesystem + (currently, only ext2 supports this) + <teythoon> in ext2, it is stored in a block and a os-specific field in the + inode points to that block + <sjbalaji> teythoon: I can't understand the logic behind that :( + <teythoon> this way, the servers are started on demand + <sjbalaji> But once they are invoked they are always online after that. + <teythoon> yes + <sjbalaji> I thought that the server goes down once its used + <gnu_srs> teythoon: shouldn't the passive ones time out if unused? + <teythoon> yes, that's how it was intented to be, but that has been + patched-out in debian/hurd + <gnu_srs> reason? + <teythoon> i don't know the details, but there is a race condition + +(`libports_stability.patch`.) + + +# IRC, freenode, #hurd, 2014-01-31 + + <sjbalaji> How can I see the complete control flow when I run the hello + translator example ? + + +# IRC, freenode, #archhurd, 2014-02-05 + + <CalimeroTeknik> plus I discussed quickly that idea with Richard Stallman + and he told me translators had a conception flaw that would forbid such a + system to be usable + + +## IRC, freenode, #archhurd, 2014-02-06 + + <antrik_> CalimeroTeknik: the "conceptal problem" rms told you about was + probably the simple issue that translators are always followed, even if + they are run by another user + <antrik> CalimeroTeknik: the conceptal problem is only in that the original + designers believed that would be safe, which it isn't. changing that + default policy (to be more like FUSE) wouldn't do much harm to the Hurd's + features, and it should be easy to do + <antrik> it's just nobody bothered so far, because it's not a big deal for + typical use cases + <antrik> rms isn't really in touch with Hurd development. he was made to + believe it was a fundamental issue by a former Hurd developer who got + carried away; and he didn't know enough to realise that it's really not a + big deal at all + + +# Candidates for Google Summer of Code [[community/gsoc/Project_Ideas]] + +## Extend `ls` et al. for Translators + +### IRC, freenode, #hurd, 2014-02-08 + + <youpi> heh + <youpi> I was wondering what that incoming/ directory was in my home + <youpi> ls gave me hundreds of packages + <youpi> then I remembered I had /hurd/httpfs http://incoming.debian.org/ on + it :) + <cluck> if only there were an easy and automated way to make ls and file + managers (like dired!) aware of links, mounts and translators :) + <youpi> cluck: what do you mean by "awaree"? + <cluck> someting like: lrwxrwxrwx 1 foo foo 31 Aug 21 18:01 + my_translator-23.0 -> ../some/fakefs /some_parameters* + <cluck> (yes, i realize it goes against some security practices but maybe + there could be a distinction like with soft/hard links that made it + opaque for some use cases) + + +## Passive Translators + +### IRC, freenode, #hurd, 2014-02-12 + + <braunr> well don't expect rsync to save passive translator records .. + <braunr> i recommend you save either the entire disk image or the partition + <gg0> should i expect it from tar/cp ? + <braunr> no + <braunr> i'm not even sure dumpe2fs does it + <braunr> the only reliable way is to save the block device + <azeem> might be a worthwhile GSOC + <azeem> "implement Hurd specific features in GNU utilities" + <azeem> there were some patches floating around for some things in the past + IIRC + <antrik> azeem: the plan for supporting Hurd features in FS utilities was + exposing them as xattrs, like Roland's Linux patch did... cascardos once + did some work on this, but don't remember how far he got + +[[community/gsoc/project_ideas/xattr]]. + + <antrik> you are right though that it would make for a good GSoC project... + <antrik> of course, *some* utilities would still benefit from explicit Hurd + support -- most notably ls + <azeem> IIRC there were also ls patches at one point + <antrik> can't recall that... but maybe it was befor my time ;-) diff --git a/hurd/translator/examples.mdwn b/hurd/translator/examples.mdwn index 4947808e..69f15c02 100644 --- a/hurd/translator/examples.mdwn +++ b/hurd/translator/examples.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -92,4 +92,4 @@ To join "foo/" "bar/" and "baz/" in the directory "quux/", just do: $ settrans -capfg quux/ /hurd/unionfs foo/ bar/ baz/ If you want to join even quux/ contents in the union itself, add `-u` as a translator argument. -You can add filesystems at run-time with the `fsysopts` command. +You can add filesystems at run-time with the [[fsysopts]] command. diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index e2f6b044..ba849cca 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 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 @@ -163,6 +163,11 @@ small backend stores, like floppy devices. <youpi> ok +#### IRC, freenode, #hurd, 2013-10-08 + + <braunr> ogi: your ext2fs patches were finally merged upstream :) + + ## Sync Interval [[!tag open_issue_hurd]] @@ -209,37 +214,332 @@ That would be a nice improvement, but only after writeback throttling is impleme <teythoon> tschwinge: well, thanks anyway ;) -## Increased Memory Consumption - -### IRC, freenode, #hurd, 2013-09-18 - - <braunr> ext2fs is using a ginormous amount of memory on darnassus since i - last updated the hurd package :/ - <braunr> i wonder if my ext2fs large store patches rework have introduced a - regression - <braunr> the order of magnitude here is around 1.5G virtual space :/ - <braunr> it used to take up to 3 times less before that - <braunr> looks like my patches didn't make it into the latest hurd package - <braunr> teythoon: looks like there definitely is a new leak in ext2fs - <teythoon> :/ - <braunr> memory only - <braunr> the number of ports looks stable relative to file system usage - <teythoon> braunr: I tested my patches on my development machine, it's up - for 14 days (yay libvirt :) and never encountered problems like this - <braunr> i've been building glibc to reach that state - <teythoon> hm, that's a heavy load indeed - <teythoon> could be the file name tracking stuff, I tried to make sure that - everything is freed, but I might have missed something - <braunr> teythoon: simply running htop run shows a slight, regular increase - in physical memory usage in ext2fs - <pinotree> old procfs stikes again? :) - <teythoon> braunr: I see that as well... curious... - <braunr> 16:46 < teythoon> could be the file name tracking stuff, I tried - to make sure that everything is freed, but I might have missed something - <braunr> how knows, maybe completely unrelated - <teythoon> the tracking patch isn't that big, I've gone over it twice today - and it still seems reasonable to me +## IRC, freenode, #hurd, 2014-02-11 + + <gg0> task with pid 5 deallocating an invalid port 4622, most probably a + bug. + <gg0> ext2fs + <teythoon> yes, i've seen this + <teythoon> e.g. when a passive translator starts + <teythoon> i guess it is in libfshelp/translator-list.c + + +## Inode Sizes, Fragment and Block Sizes + +### IRC, freenode, #hurd, 2014-02-12 + + <gg0> this might be interesting and could make people not to fsck hurd + filesystem on linux: + <gg0> start ext2fs: ext2fs: device:hd0s1 + <braunr> ? + <gg0> : panic: get_hypermetadata: inode size 256 isn't supported + <gg0> (wait, also a bad typist) + <braunr> well, if the file system was created from the hurd, or with -o + hurd, as it ought to be, you wouldn't have this problem + <gg0> oh, good to know, especially before restoring :p + <braunr> i suspect your mkfs command to have created an ext4 fs + <gg0> nope mkfs.ext2 + <braunr> hm ok, so it seems to create 256 size inodes by default there + <gg0> i guess -o hurd would set some os-specific properties + <braunr> it merely enforces a few restrictions + <gg0> some predefined defaults + <braunr> fragments and blocks are 4k + <braunr> and apparently inodes are 128 bytes + <gg0> because it can't support bigger values? is it worth working on remove + such restrictions? + <braunr> probably not so far + <braunr> certainly not the fragment/block size restriction + <braunr> it matches the page size + <braunr> larger inode sizes could be supported if they're dependencies for + other worthwhile features such as those someone would add in an ext4 + translator + + +## Linux' `CONFIG_EXT4_USE_FOR_EXT23` + +### IRC, freenode, #hurd, 2014-02-12 + + <gg0> why the hell i have thousands of Inode 839, i_blocks is 248, should + be 256. Fix<y>? yes + <gg0> in all cases i_blocks should be +8 + <gg0> and /dev/sda1: (There are 245635 inodes containing multiply-claimed + blocks.) + <gnu_srs1> 10:50:08< gg0> start ext2fs: Hurd server bootstrap: + ext2fs[device:hd0s1] exec + <gnu_srs1> That's exactly where my image boot hangs! + <gg0> start ext2fs: Hurd server bootstrap: ext2fs[gunzip:device:rd0] exec + <AliciaC> gnu_srs1: you might want to check that linux isn't using the ext4 + module to handle ext2 and ext3 filesystems + <AliciaC> gnu_srs1: as I understand it the idea is that the ext4 module + treats them as ext2/ext3 filesystems, just avoiding code duplication from + having three separate modules for related filesystems, so it shouldn't + change it from ext2 at all, but it does do something strange with it + <AliciaC> but I'm not sure if that's the case or if it's converting it to + ext4. last I heard Hurd doesn't support anything beyond ext2 + <gnu_srs1> AliciaC: I did use ext2 when mounting from Linux: mount -t ext2 + /dev/loop0 /mnt + <gnu_srs1> and when not mounted: e2fsck /dev/loop0 + <AliciaC> gnu_srs1: I'd check the kernel config to be sure, + CONFIG_EXT4_USE_FOR_EXT23 must be disabled + <braunr> you can use the ext4 driver for ext2 + <braunr> that's not a problem here + <braunr> the problem happens long before, when the file system gets + corrupted + <braunr> you must understand why + <AliciaC> I have done some testing on this, mounting a Hurd ext2 filesystem + with the ext4 module broke it for me, an easily repeated issue + <AliciaC> mounting Debian's ext2 image and unmounting it with ext4 broke + it, resulting precisely in the kind of hang ups mentioned by gnu_srs1 and + gg0 + <braunr> interesting + <AliciaC> that's with a clean image with nothing corrupting it before hand, + tested to be working as well + <braunr> ok so the ext4 driver must ignore hurd specific stuff + <braunr> that's strange because i recall using it to perform small repairs + on darnassus and never had any issue + <braunr> even on the root file syste + <braunr> but my repairs were very quick and targetted + <AliciaC> different linux versions maybe + <AliciaC> when I was testing it I didn't even need to do anything in the + filesystem to trigger the issue, just mount and unmount + <gnu_srs1> I repaired filesystems before like this, has something happened + with later versions of Linux? + <gnu_srs1> One of my boxes is ext3 (probably worked before) another ext4 + (the one breaking things, but worked before) + <gnu_srs1> ext3 and ext4 box: CONFIG_EXT4_USE_FOR_EXT23=y same kernel + 3.12-1.amd64 + <gnu_srs1> what about mounting with bs=4096 (used by hurd) + <braunr> -t ext2 should work fine + <braunr> just don't use the ext4 driver if in doubt + <gg0> no difference between specifying -t or not, in both cases EXT4-fs + (sda1): mounting ext2 file system using the ext4 subsystem + <braunr> hmm + <braunr> you're screwed then ; + <braunr> ;p + <braunr> or maybe -t ext3 .. :) + <braunr> although i suspect ext4 would be used then too + <gg0> linux-image-3.2.0-4-amd64: + /lib/modules/3.2.0-4-amd64/kernel/fs/ext2/ext2.ko + <gg0> wheezy still has it. then something between 3.2.0 and 3.13(?) removed + it + <braunr> check the config file + <gg0> i mean ext2 module + <braunr> check if the config file enables it + <gnu_srs1> It's not: # CONFIG_EXT2_FS is not set + <gg0> 14:42 < gg0> wheezy still has it. then something between 3.2.0 and + 3.13(?) removed it + <braunr> how about retrying what you did without ever mounting from linux ? + <braunr> gg0: it wasn't clear enough that you meant removed from + configuration + <braunr> (for example, it could have been blacklisted) + <gg0> or present not as a module + <braunr> maybe yes, although it's unusual to see generic kernels embedding + file systems these days + <AliciaC> the CONFIG_EXT4_USE_FOR_EXT23 option isn't available if either + ext2 or ext3 are enabled though, even just as loadable modules + <gnu_srs1> The ext2 and ext3 modules were there in 3.10-3, not in 3.12-1 + <gnu_srs1> (14:48:59) <srs>: It's not: # CONFIG_EXT2_FS is not set -- + 3.12-1 + <gg0> https://bugs.debian.org/731072 + * gg0 rsync'ing back to new fs with 3.10 kernel + <gnu_srs1> seems like this bug was archived without being closed?? + <gg0> someone should produce a testcase and file another one btw + <gnu_srs1> but that bug was for files systems up to 4MB, not 4GB? + <gg0> i pasted it just because submitter talks about config option in + question and when was enabled + <gg0> don't we want to thank AliciaC who pointed it out and who could + precisely file a bug? :) + <gg0> filed http://bugs.debian.org/738758 + <braunr> gg0: thanks + <braunr> AliciaC: and thanks too + + +### IRC, freenode, #hurd, 2014-02-13 + + <gnu_srs> gg0: Did you create and test with an ext2 Linux image too on + 3.10/3.12? + <gnu_srs> here is a diff: http://paste.debian.net/81837/ + <gnu_srs> visible differences: Filesystem features:filetype (linux only) + and Free inodes:1268(hurd) / 1269(linux) + <AliciaC> between one created with -o Hurd and one created with -o Linux + (or no -o)? + <gnu_srs> AliciaC: -o Hurd and -b 4096 (no -o) + <AliciaC> I wonder if that would show any interesting difference between an + untouched -o Hurd ext2 image and a copy of it that has been mounted with + the ext4 module + <gnu_srs> AliciaC: here: http://paste.debian.net/81857/ + <gnu_srs> there is a difference of one in the number of free inodes! + <gnu_srs> cf the number of free inodes for linux + <AliciaC> gnu_srs: thanks :) though I don't know what to make of that, I + guess just adding an inode shouldn't break anything + <AliciaC> wait, no, removing an inode? + <AliciaC> bleh, too tired, read it wrong + <gnu_srs> this line should read:(11:37:48) srs: visible differences: + Filesystem features:filetype (linux only) and Free inodes:1268(linux) / + 1269(hurd) + <gnu_srs> There are differences in ext2.h and ext4.h in the Linux source + code wrt hurd1, hurd2 structs. + <gnu_srs> one change might be interesting: http://paste.debian.net/81864/ + <braunr> gnu_srs: probably not + <gnu_srs> If not, where to look? + <braunr> well, the first thing would be to create a (small) ext2 file + system, usable on the hurd, with a few files and directories + <braunr> save it + <braunr> mount it with the ext4 driver + <braunr> and make a binary comparison + <braunr> you could use a modified ext2fs translator to tell you exactly + what's wrong when loading the file system + <braunr> and then look at the corresponding code in the ext4 driver + <gnu_srs1> braunr: here is a binary diff of the unmounted and mounted e2fs + files: http://paste.debian.net/81896/ + <braunr> gnu_srs1: i'm not going to analyze it + <braunr> you are + <braunr> :p + <gnu_srs1> many of them can be removed: e.g. /mnt and bug000 + <braunr> ? + <gnu_srs1> many diff entries* + <braunr> but why ? + <braunr> you shouldn't have changed the content at all + <gnu_srs1> If I don't add a file, the fs is not corrupted + <gnu_srs1> this is with two vers small files created as in gg0s bug report + <gnu_srs1> very* + <braunr> ok + <braunr> i guess checking the source code first and the binary diffs next + is easier + <gnu_srs1> OK, I have to find out how the ext2fs files are organized. + <gnu_srs1> I.e. reading mke2fs source code + <braunr> no + <braunr> read the ext4 driver + <braunr> how a directory entry is created + <braunr> how a directory is saved back on the block device + <braunr> how any potential conversion could be triggered + <gnu_srs1> k, will do + <braunr> read about the ext2fs format if doing that first doesn't help + <braunr> learning a file system is complicated and long + <gnu_srs1> What is the inode size for Hurd/Linux? + <braunr> probably 128 + <gnu_srs1> same for both? + <braunr> what is "Hurd/Linux" ? + <gnu_srs1> on Hurd / on Linux + <braunr> 128 on hurd, variable on linux + <braunr> 128-512 i'd say + <gnu_srs1> ext2 on linux + <gnu_srs1> found it from dumpe2fs: 128 for both + <braunr> no, it can vary on linux + <braunr> although once a file system is built, the inode size cannot be + changed + <gnu_srs1> k, the file created with mke2fs has 128 + + +## `ext2fs: ../../ext2fs/pager.c:401: file_pager_write_page: Assertion 'block' failed.` + +### IRC, freenode, #hurd, 2014-02-19 + + <pere> "ext2fs: ../../ext2fs/pager.c:401: file_pager_write_page: Assertion + 'block' failed." in the console. + +[[user/Maksym_Planeta]] also has hit that one. + + <braunr> wow oO + <braunr> using debian hurd right ? + <pere> power cycling. + <pere> yes. + <braunr> with hurd 1:0.5.git20140203-1 and glibc 2.17-98~1 ? + <pere> braunr: not sure how to check. + <braunr> pere: dpkg -l | grep .. i suppose + <pere> gah, autofsck do not work.. :( + <braunr> it does :( + <braunr> unstable is easy to mess it seems + <pere> had to run fsck -y / manually... + <braunr> i suspect you were using a corrupted file system at mount time + <braunr> ah that + <braunr> yes it is sometimes needed + <braunr> but ext2 is reliable enough that only temporary files get their + way into lost+found + <braunr> temporary/recently created + <braunr> the crash you had, on the other hand, looks more serious + <braunr> it seems like you mounted a corrupted file system + <pere> could be. + <pere> hurd v1:0.5.git20140203-1 and libc0.3 v2.17-98~1, it seem. + <braunr> good + <braunr> you shouldn't have such problems then, i suspect a mess up on your + part + <braunr> but you're not the only one to have had weird file systems + problems lately + <pere> hah. I blame the hurd. :P + <braunr> heh :) + <pere> gah, another crash. :( + <braunr> Oo + <braunr> same assertion ? + <pere> same place, or almost the same place. + <pere> yes. <braunr> hm + <pere> same crash. :( + <braunr> what kind of machine do you run the hurd on ? + <pere> kvm + <braunr> how much memory ? + <pere> 1G + <braunr> did you see if the system was swapping ? + <pere> no idea. + <braunr> i suggest always running top/htop on the hurd ;p + <braunr> and monitor memory usage closely + <gg0> unless pere lately mounted/fsck'ed fs in question with a recent linux + kernel, there should not be particular problems + <braunr> it definitely doesn't look like it was mounted by an ext4 driver, + no + <braunr> which means it's something else entirely and this is scary + <pere> I didn't. I fetched the prebuild image, upgraded it, switched it to + sysvinit and started working. + <braunr> sorry i can't be of more help about that + <braunr> ext2fs has been quite solid on my machines for a long time :( + <braunr> there are known assertions that trigger under some special + pressure, but that's not what you're having here + <braunr> pere: anything particular in fstab ? + <pere> nope, have not touched /etc/fstab. + <braunr> hm stupid question + <braunr> are you sure it's not full ? + <pere> nothing look full to me. + <pere> neither the disk nor the host file system. + + +### IRC, freenode, #hurd, 2014-02-20 + + <pere> braunr: do you remember my ext2fs crash from yesterday? I could + avoid it by interrupting the triggering build and running sync once in a + while. and it show up again if I do not sync in between. :) + <braunr> ? + <braunr> are you sure you're not swapping ? + <pere> I have no idea. still. :) + <braunr> again, i recommend you run top/htop and monitor that + <braunr> pere: is your patch needed to trigger the assertion ? + +[[open_issues/ti-rpc_then_nfs]]. + + <pere> braunr: well, without it, the package do not build, so yeah. :) + <braunr> ok + <pere> tested again, and is not swapping. 850MB free memory. + <braunr> ok + <braunr> so this might be a real file system bug + <braunr> let me see + <braunr> pere: libtirpc built fine here .. + <braunr> pere: do you have a separate /home partition ? + <braunr> or any separate file system for builds + <pere> braunr: nope, everything on / + <braunr> pere: i wouldn't recommend that + <braunr> there very probably are bugs in the file system code and using + separate partitions is a way to alleviate them + + +## `ext2fs: ../../libdiskfs/rdwr-internal.c:42: _diskfs_rdwr_internal: Assertion `!diskfs_readonly' failed.` + +### IRC, freenode, #hurd, 2014-02-22 + + <gg0> login: init: notifying pfinet of shutdown...init: notifying tmpfs + none of shutdown...init: notifying tmpfs none of shutdown...init: + notifyi. + <gg0> ext2fs: ../../libdiskfs/rdwr-internal.c:42: _diskfs_rdwr_internal: + Assertion `!diskfs_readonly' failed. + <gg0> In tight loop: hit ctl-alt-del to reboot # Documentation diff --git a/hurd/translator/fifo.mdwn b/hurd/translator/fifo.mdwn index 857922fc..4132e94a 100644 --- a/hurd/translator/fifo.mdwn +++ b/hurd/translator/fifo.mdwn @@ -46,3 +46,9 @@ The *fifo* translator implements named pipes (FIFOs). <pochu> gg0: got an example? <gg0> http://bugs.debian.org/629184 <gg0> i didn't close it myself + + +## IRC, OFTC, #debian-hurd, 2013-10-04 + + <braunr> there is new-fifo, which you can try + <braunr> i guess none of us know what it was really meant for diff --git a/hurd/translator/magic.mdwn b/hurd/translator/magic.mdwn index 84bacdfb..2b0d1bf7 100644 --- a/hurd/translator/magic.mdwn +++ b/hurd/translator/magic.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2010 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2006, 2007, 2008, 2010, 2013 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 @@ -9,7 +9,13 @@ 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]]."]]"""]] -The magic translator provides `/dev/fd`. +The `magic` translator returns magic retry results, which are then resolved by +[[glibc]]'s *name lookup* routines. + +[[!toc]] + + +# `/dev/fd`. $ showtrans /dev/fd /hurd/magic --directory fd @@ -20,3 +26,253 @@ individually like this: $ ls -l /dev/fd/0 crw--w---- 1 bing tty 0, 0 Nov 19 18:00 /dev/fd/0 + + +# `/dev/tty` + + $ showtrans /dev/tty + /hurd/magic tty + + +## Open Issues + +### IRC, OFTC, #debian-hurd, 2013-06-18 + + <XTaran> http://www.zsh.org/mla/workers/2013/msg00547.html + + +#### IRC, OFTC, #debian-hurd, 2013-06-19 + + <XTaran> youpi: http://www.zsh.org/mla/workers/2013/msg00548.html -- Is + that realistic? If yes, can someone of you test it? I though would expect + that if /dev/tty exists everywhere, it's a chardev everywhere, too. + <youpi> that's not impossible indeed + <youpi> I've noted it on my TODO list + + +#### IRC, OFTC, #debian-hurd, 2013-06-20 + + <pinotree> youpi: wrt the /dev/tty existance, + https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=hurd-i386&ver=46-2&stamp=1371553966 + <pinotree> For the build logs, demonstrate that /dev/null and /dev/tty + exist: + <pinotree> ls: cannot access /dev/tty: No such device or address + <youpi> uh?! + <youpi> ah, ENODEV + <youpi> so that's what we was thinking, no tty -> no /dev/tty + + +#### IRC, OFTC, #debian-hurd, 2013-09-20 + + <XTaran> Hi. zsh still FTBFS on Hurd due to some test failure: + https://buildd.debian.org/status/package.php?p=zsh -- IIRC I checked last + time on some porterbox and couldn't reproduce the failure there. Any + insight if /dev/tty is not accessible on the buildds inside the chroot? + Or is it no character device there? I checked on strauss and there it is + a character device. + <XTaran> My only other option to debug this (didn't think of that yesterday + before the upload unfortunately) would be to override dh_auto_test with + "ls -l /dev/tty; dh_auto_test". Do you think that would be helpful? + <pinotree> i see /dev/tty on exodar, in the root system and in the chroot + <XTaran> pinotree: And it is a character device? + <XTaran> ... in both cases? + <pinotree> crw--w---- 1 pino tty 0, 0 Sep 20 10:20 /dev/tty + <pinotree> yes + <XTaran> pinotree: Hrm. + <pinotree> (/dev in the chroot is a firmlink to the system /dev, iirc) + <XTaran> pinotree: What is a firmlink? :) + <XTaran> pinotree: /dev/tty belongs to your user in the example above. + <pinotree> something between a (sym)link and an union mount + <XTaran> pinotree: Is it possible that /dev/tty is not visible if the + buildd runs without a connected terminal? + <pinotree> that i'm not sure + <XTaran> I see. + <pinotree> wouldn't it be possible to skip only that check, instead of the + whole test suite? + <pinotree> maybe something like + <pinotree> tty=$(find /dev/ -name 'tty*' -type c -print) + <pinotree> if [[ -n $tty ]]; then / [[ -c $tty[(f)1] && ! -c $zerolength ]] + / else / print -u$ZTST_fd 'Warning: Not testing [[ -c tty ]] (no tty + found)' / [[ ! -c $zerolength ]] / fi + <pinotree> (never used zsh, so please excuse me if i wrote something silly + above) + <XTaran> re + <XTaran> pinotree: Yeah, sure. That would be one way to get the thing + building again, if that's really the cause. + <pinotree> i guess it would find any of the available tty* devices + <pinotree> it does that for block devices, why not with tty devices, after + all? :) + <XTaran> pinotree: I just wonder if the failing test is because the test + doesn't work properly on that architecture or because it indicates that + there is a bug in zsh which only is present on hurd. + <pinotree> wouldn't the change proposed above help in determining it? + <XTaran> If I'm sure that it's a broken test, I'll try to disable that + one. If not I'd report (more details) to upstream. :) + <XTaran> pinotree: Oh, indeed. + <pinotree> if you get no warning, then a tty device was found with find + (using its -type c option), so the failing condition would be a zsh (or + maybe something in the stack below) bug + <pinotree> with the warning, somehow there were no tty devices available, + hence nothing to test -c with + <XTaran> So basically doing a check with dash to see if we should run the + zsh test. + <pinotree> dash? + <XTaran> Well, whatever /bin/sh points to. :) + <pinotree> ah, do you mean because of $(find ...)? + <XTaran> Ah, right, -type c is from find not /bin/sh + <XTaran> pinotree: That's my try: + http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=commitdiff;h=ba5c7320d4876deb14dba60584fcdf5d5774e13b + <pinotree> o_O + <pinotree> isn't that a bit... overcomplicated? + <XTaran> pinotree: Yeah, it's a little bit more complicated as the tests + itself are not pure shell code but some format on their own. + <pinotree> why not the "thing" i wrote earlier? + <XTaran> pinotree: Actually it is what I understand you wanted to do, just + with more debug output. Or I dunderstood + <XTaran> pinotree: Actually it is what I understand you wanted to do, just + with more debug output. Or I understood your thing wrongly. + <pinotree> <pinotree> tty=$(find /dev/ -name 'tty*' -type c -print) + <pinotree> <pinotree> if [[ -n $tty ]]; then / [[ -c $tty[(f)1] && ! -c + $zerolength ]] / else / print -u$ZTST_fd 'Warning: Not testing [[ -c tty + ]] (no tty found)' / [[ ! -c $zerolength ]] / fi + <XTaran> pinotree: Yeah, I know. + <pinotree> that is, putting these lines instead of the current two + tty=/dev/tty + following + <pinotree> imho that should be fit for upstream + <XTaran> pinotree: You mean inside C02cond.ztst? + <pinotree> yep + <XTaran> pinotree: No, IMHO that's a bad idea. + <pinotree> why? + <XTaran> pinotree: That file is to test the freshly compiled zsh. I can't + rely on their code if I'm testing it. + <pinotree> uh? + <pinotree> the test above for -b is basically doing the same + <XTaran> pinotree: Indeed. Hrm. + <pinotree> that's where i did c&p most of it :) + <XTaran> So upstream relies on -n in the testsuite before it has tested it? + Ugly. + <pinotree> if upstream does it, why cannot i too? :D + <XTaran> pinotree: You've got a point there. + <XTaran> Ok, rethinking. :) + <pinotree> otoh you could just move the testcase for -n up to that file, so + after that you know it works already + <XTaran> pinotree: Well, if so, upstream should do that, not me. :) + <pinotree> you could suggest them to, given the -n usage in the -b testcase + <XTaran> pinotree: Looks alphabetically sorted, so I guess that's at least + not accidentially. + <XTaran> pinotree: Ok, you've convinced me. :) + <pinotree> :D + <XTaran> Especially because this is upstream-suitable once it proved to fix + the Hurd FTBFS. :) + <XTaran> pinotree: The previous upstream code (laast change 2001) instead + of the hardcoded /dev/tty was btw "char=(/dev/tty*([1]))", so I suspect + that the find may work on Cygwin, too. + <XTaran> s/aa/a/ + <pinotree> ah, so that's that comment about globbing on cygwin was + referring to + <XTaran> Yep + <pinotree> cool, so incidentally i've solved also that small issue :9 + <pinotree> :) + <XTaran> pinotree: I hope so. :) + <XTaran> Then again, I hope, external commands like find are fine for + upstream. + <pinotree> then they should rework the already existing testcases ;) + <XTaran> pinotree: Ah, I fall again for the same assumptions. :) + <XTaran> Seems as I would really build test suites with a different + approach. :) + <pinotree> nothing bad in that, i'd say + <XTaran> I'd try to make the tests as far as possible independent from + other tools or features to be sure to test only the stuff I want to test. + <XTaran> Warning: Not testing [[ -c tty ]] (no tty found) + <XTaran> Interesting. I didn't expect that outside a chroot. :) + <pinotree> where's that? + <XTaran> pinotree: A plain "debuild on my Sid VM. + <pinotree> ah + <XTaran> Linux, amd64 + <XTaran> (and Debian of course ;-) + <XTaran> pinotree: Ah, my fault, I kept upstreams char= but didn't change + it in your code. :) + <pinotree> hehe + <XTaran> pinotree: Will be included in the next zsh upload. But I don't + want to upload a new package before the current one moved to testing (or + got an RC bug report to fix :-) + <pinotree> oh sure, that's fine + <XTaran> pinotree: + http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=commitdiff;h=22bc9278997a8172766538a2ec6613524df03742 + <XTaran> (I've reverted my previous commit) + <pinotree> \o/ + + +#### IRC, OFTC, #debian-hurd, 2013-09-30 + + <XTaran> Anyone knows why the building of zsh on ironforge restarted? It + was at something like "building 4h20m" when I looked last and it now is + at "building 1h17m" but there's no old or last log, so it does still look + like the first build. + <pinotree> most probably got stuck + <XTaran> Oh, ok. + <XTaran> pinotree: So there are cases where the log is not kept? + <pinotree> looks so + <youpi> when the machine crashes, yes :) + <XTaran> youpi: Ooops. Was that me? + <youpi> no, I just rebooted the box + <youpi> I didn't easily find which process to kill + <XTaran> Ok. Then I'll check back tomorrow morning if pinotree's fix for + zsh's test suite on hurd worked. :) + <youpi> it seems to be hung on + /build/buildd-zsh_5.0.2-5-hurd-i386-vO9pnz/zsh-5.0.2/obj/Test/../Src/zsh + <youpi> ../Src/zsh ../../Test/ztst.zsh ../../Test/Y02compmatch.ztst + <XTaran> :( + <XTaran> At least pinotree's patch worked as it then likely passed + C02cond.ztst. :) + <XTaran> youpi: For how long? There are multiple tests which take at least + 3 seconds per subtest. + <youpi> one hour already + <XTaran> Ok. + <XTaran> That's far too long + + +#### IRC, OFTC, #debian-hurd, 2013-10-01 + + <XTaran> pinotree: I've just checked + https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=hurd-i386&ver=5.0.2-5&stamp=1380608100 + manually: Your fix unfortunately seemed not to help, but another test + failed, too, and that one came later and was hence suspected as primary + failing issue. + <XTaran> pinotree: But "+ find: `/dev/tty': No such device or address" + gives some hint. I just have no idea, why find issues that message. + * XTaran really wonders how that message can be caused. + <XTaran> So find sees /dev/tty, but gets an error if it tries to access + (maybe only stat) it while not being connected to a terminal. + <XTaran> Bingo: This reproduces the issue (note the missing -t option to + ssh): ssh exodar.debian.net "find /dev/ -nowarn -maxdepth 1 -name 'tty*' + -type c -ls" + <XTaran> Even clearer: $ ssh exodar.debian.net "ls -l /dev/" | grep 'tty$' + <XTaran> ls: cannot access /dev/tty: No such device or address + <XTaran> ?????????? ? ? ? ? ? tty + <XTaran> I'd say this is a bug somewhere deep down, either in libc or the + kernel. + <pinotree> or in the console translator + <XTaran> pinotree: Never heard of that so far. :) + <XTaran> pinotree: Someone from zsh upstream suggests to use /dev/null or + /dev/zero instead of /dev/tty* -- will try that for the next upload. + <pinotree> ah right, /dev/null should be standard POSIX + <XTaran> I hope so. :) + <pinotree> http://pubs.opengroup.org/onlinepubs/9699919799/ check in POSIX + <pinotree> in any case, sorry for the troubles it is giving you... + <XTaran> pinotree: I'm more concerned about the hanging second test. I + think I can get that test working with using /dev/null. + <XTaran> Now that I've understood why the original test is failing. + <XTaran> pinotree: Shall I write a bug report for that issue? If so, + against which package? + <pinotree> XTaran: not sure it is worth at this stage, having a clearer + situation on what happens could be useful + <pinotree> it is something that can happen sporadically, though + <XTaran> pinotree: Well, it seems a definitely unwanted inconsistency + between what the directory listing shows and which (pseudo) files are + accessible. Independently of where the bug resides, this needs to be + fixed IMHO. + <pinotree> sure, nobody denies that + <XTaran> pinotree: I'd call it easily reproducible. :) + <pinotree> not really + <XTaran> ... once you know where to look for. diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn index 0734e1e6..d663d4c5 100644 --- a/hurd/translator/mtab/discussion.mdwn +++ b/hurd/translator/mtab/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008, 2009, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2008, 2009, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -18,7 +18,7 @@ mounted file systems. This also means that commands like `df` can only work on explicitly specified mountpoints, instead of displaying the usual listing. One possible solution to this would be for the translator startup mechanism to -update the `mtab` on any `mount`/`unmount`, like in traditional systems. +update the `mtab` on any `mount`/`umount`, like in traditional systems. However, there are some problems with this approach. Most notably: what to do with passive translators, i.e., translators that are not presently running, but set up to be started automatically whenever the node is accessed? Probably @@ -1110,6 +1110,12 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. e.g. http://darnassus.sceen.net/gitweb/?p=teythoon/hurd.git;a=shortlog;h=refs/heads/feature-mtab-translator-v3-wip +### IRC, freenode, #hurd, 2013-11-20 + + <braunr> teythoon: ah thanks for making mtab multithreaded :) + <braunr> i forgot about that + + ## [[open_issues/libnetfs_passive_translators]] @@ -1864,21 +1870,6 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <teythoon> and I saw that this also aplies to remap.sh <teythoon> *while <youpi> yep, they're basically the same - <teythoon> btw, I somehow feel settrans is being abused for chroot and - friends, there is no translator setting involved - <youpi> chroot, the command? or the settrans option? - <youpi> I don't understand what you are pointing at - <teythoon> the settrans option being used by fakeroot, remap and (most - likely) our chroot - <youpi> our chroot is just a file_reparent call - <youpi> fakeroot and remap do start a translator - <teythoon> yes, but it is not being bound to a node, which is (how I - understand it) what settrans does - <teythoon> the point being that if settrans is being invoked with --chroot, - it does something completely different (see the big if (chroot) {...} - blocks) - <teythoon> to a point that it might be better of in a separate command - <youpi> Mmm, indeed, a lot of the options don't make sense for chroot ## IRC, freenode, #hurd, 2013-09-06 @@ -2103,7 +2094,173 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <youpi> anyway, got to run -## IRC, freenode, #hurd, 2013-09-20 +## Memory Leak + +Fixed in 2013-09-28 Hurd commit a81c0c28ea606b0d0a2ad5eeb74071c746b7cdeb +(libdiskfs), and 2013-10-04 Hurd commit +98b6f846b628e858acbae9258bac78cf54126d27 (libnetfs). + +### IRC, freenode, #hurd, 2013-09-18 + + <braunr> ext2fs is using a ginormous amount of memory on darnassus since i + last updated the hurd package :/ + <braunr> i wonder if my ext2fs large store patches rework have introduced a + regression + <braunr> the order of magnitude here is around 1.5G virtual space :/ + <braunr> it used to take up to 3 times less before that + <braunr> looks like my patches didn't make it into the latest hurd package + <braunr> teythoon: looks like there definitely is a new leak in ext2fs + <teythoon> :/ + <braunr> memory only + <braunr> the number of ports looks stable relative to file system usage + <teythoon> braunr: I tested my patches on my development machine, it's up + for 14 days (yay libvirt :) and never encountered problems like this + <braunr> i've been building glibc to reach that state + <teythoon> hm, that's a heavy load indeed + <teythoon> could be the file name tracking stuff, I tried to make sure that + everything is freed, but I might have missed something + <braunr> teythoon: simply running htop run shows a slight, regular increase + in physical memory usage in ext2fs + <pinotree> old procfs stikes again? :) + <teythoon> braunr: I see that as well... curious... + <braunr> 16:46 < teythoon> could be the file name tracking stuff, I tried + to make sure that everything is freed, but I might have missed something + <braunr> how knows, maybe completely unrelated + <teythoon> the tracking patch isn't that big, I've gone over it twice today + and it still seems reasonable to me + <braunr> hm + + +### IRC, freenode, #hurd, 2013-09-25 + + <braunr> seems like a small leak per file access + <braunr> but htop makes it obvious because it makes lots of them + <braunr> shouldn't be too hard to find + <braunr> since it might also come from the large store patch, i'll take a + look at it + + +### IRC, freenode, #hurd, 2013-09-27 + + <braunr> teythoon: found the leak :) + <braunr> although its origin is weird + <teythoon> braunr: where is it? + <braunr> i'm still building packages to make sure that's it + <braunr> see + http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/blob/HEAD:/libdiskfs/dir-lookup.c + <braunr> which you changed in + http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/commit/06d49cdadd9e96361f3fe49b9c940b88bb869284 + <braunr> line 306 is "return error" instead of "goto out" + <braunr> has been so since 1994 + <braunr> what is unclear is why this code path is now run + <braunr> patch is here: + http://darnassus.sceen.net/~rbraun/0001-Fix-memory-leak-in-libdiskfs.patch + <teythoon> I see, weird indeed + <braunr> teythoon: the system also feels slower somehow + <braunr> such errors might have introduced unexpected retries + <teythoon> i think it's possible to write a coccinelle patch to find such + errors + + +### IRC, freenode, #hurd, 2013-09-28 + + <youpi> braunr: bah, I havent noticed the leak on my box, even after + building eglibc & hurd several times + <braunr> that's weird + <braunr> are you sure it's up to date ? + <braunr> also, is procfs correctly attached to /proc ? + <braunr> that's what seems to trigger it + <youpi> yes, 20130924-2, with procfs on /proc + + <teythoon> braunr: that turned out to be the leak indeed? and somehow my + changes triggered it? did you discover why? + <braunr> teythoon: yes, yes, no + <braunr> but youpi didn't see the leak on his system + <teythoon> ^^ cool that you found it + <teythoon> I did + <braunr> oh yes you mean you saw the leak + <teythoon> yes + + +### IRC, freenode, #hurd, 2013-10-01 + + <braunr> the fix i did in libdiskfs might have fixed other issues + <braunr> apparently, it's the code path taken when error isn't ENOENT, + including no error (translator started) + <pinotree> the memory leak fix, you mean? + <braunr> yes + <braunr> it might haved fixed reference counting too + <braunr> although i'm not sure if we actually ever run into that issue in + the past + <braunr> the weird thing is, that path is taken when starting a passive + translator + <braunr> (i think) + <braunr> (it might be any kind of translator, and just doing nothing if + alcready active) + <braunr> already* + <braunr> anyway, the fact that the leak was so visible means this code was + run very often + <braunr> which doesn't make sense + <braunr> hm ok, it seems that code was run every time actually + <braunr> but the leak became visible when it concerned memory + <pinotree> which side-effects did the old code produce? + <braunr> teythoon added a dynamically allocated path that wasn't freed + <braunr> reference leaks + <braunr> which might explain the assertion on reference we sometimes see + with ext2fs + <braunr> when a counter overflows and becomes 0 + +[[open_issues/ext2fs_libports_reference_counting_assertion]]? + + <pinotree> hmm + <braunr> which is why i'm mentioning it + <braunr> :) + <braunr> i'll try to reproduce the assertion + <braunr> pinotree: actually, after a more in-depth look, reference counting + looks valid before the fix too + <pinotree> ok, thanks for checking + <braunr> pinotree: the assertion affects the root translator, and is + triggered by a test that stresses memory + <pinotree> memory as in ram, or as in disk storage? + <braunr> malloc + <pinotree> ok + <braunr> i suspect the code doesn't handle memory failure well + + +### IRC, freenode, #hurd, 2013-10-02 + + <teythoon_> braunr: btw, did you fix the leak? + <braunr> yes + <braunr> + http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/commit/a81c0c28ea606b0d0a2ad5eeb74071c746b7cdeb + <braunr> 1h after tagging 0.5 ( + <braunr> :( + <teythoon> ah yes, I've seen that commit + <teythoon> I just wanted to know whether this settled the issue + <braunr> it does :) + <teythoon> good + <braunr> i still can't figure out why youpi didn't had it + <braunr> the code path is run when no error (actually error != ENOENT) + <braunr> which explains why the leak was so visible + <teythoon> so my patch exposed this b/c of the allocation I added, makes + sense + <teythoon> it's funny actually, b/c this wasn't an issue for me as well, I + had my development vm running on that patches for two weeks + + +### IRC, freenode, #hurd, 2013-10-02 + + <braunr> libnetfs suffers from the same leak as libdiskfs when looking up a + translator + <braunr> i'll fix it too + + +## Multiple mtab Translators Spawned + +Fixed in 2013-10-05 procfs commit c87688a05a8b49479ee10127470cc60acebead4a? + + +### IRC, freenode, #hurd, 2013-09-20 <braunr> teythoon: how come i see three mtab translators running ? <braunr> 6 now oO @@ -2113,10 +2270,773 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <braunr> teythoon: more bug fixing for you :) -## IRC, freenode, #hurd, 2013-09-23 +### IRC, freenode, #hurd, 2013-09-23 <teythoon> so it might be a problem with either libnetfs (which afaics has never supported passive translator records before) or procfs, but tbh I haven't investigated this yet [[open_issues/libnetfs_passive_translators]]. + + +### [[!debbug 724868]] + + +### IRC, freenode, #hurd, 2013-10-03 + + <braunr> i can't manage to find out where the hurd stores information about + active translators ... + <braunr> there is this transbox per node + <braunr> but where are nodes stored ? + <braunr> what if they are are dropped ? + <pinotree> braunr: iirc, see libfshelp + <braunr> well i have + <braunr> i still can't find it + <braunr> i fear that it works for ext2fs because that particular translator + implements a cache of open nodes + <braunr> whereas things like procfs drop and recreate nodes per open + <braunr> which would be the root cause for the multiple mtab bug + <pinotree> doesn't tmpfs support translators? + <braunr> good idea + <braunr> although it's still a libdiskfs based one + <braunr> no problem for tmpfs, so it would be a netfs/procfs issue + <braunr> better than what i feared :) + <braunr> now, how is libdiskfs able to find active translators .. + <braunr> ah, there is a name cache in libdiskfs .. + <braunr> nope, looks fine + + +### IRC, freenode, #hurd, 2013-10-04 + + <braunr> nodes with a translator seem to keep a reference in libdiskfs and + not in libnetfs + <braunr> mhmmpf + <braunr> oh great .. + <braunr> each libdiskfs that "works" seems to implement its own + diskfs_cached_lookup function + <braunr> so both ext2fs and tmpfs actually maintain a list of nodes, + keeping a reference on those with a translator + <braunr> while procfs simply doesn't + <braunr> teythoon: ^ + <braunr> *sigh* + <teythoon> braunr: ok, thanks, I'll look into that + <braunr> i'm not sure how to fix it + <braunr> we can either fix node destruction to cleanly shut down + translators + <braunr> but this would mean starting mtab on each access + <braunr> or we could implement a custom cache in procfs + <braunr> or perhaps a very custom change in the lookup callback for mounts + <braunr> i'll try the latter + <teythoon> err, shouldn't we try to fix this in lib*fs? + <braunr> unless you really want to work on it + <braunr> i dont' know + <teythoon> ah, so the node is destroyed but the translator is kept running? + that's what you mean by the above? + <teythoon> and ext2fs makes an effort of killing it in its node cleanup + code? + <braunr> yes + <braunr> grmbl, i'm lagging a lot + <braunr> i'm not sure + <braunr> ext2fs maintains it + <braunr> with ext2fs, translators can only be explicitely removed + <braunr> i mean, ext2fs keeps all node descriptors alive once accessed + <braunr> while procfs doesn't + <braunr> teythoon: ok, looks like i have a working patch that merely caches + the node for mounts + + <braunr> i installed my fixed procfs on darnassus, only one mtab :) + <teythoon> nice :) + + <braunr> i have a fix for the multiple mtab issue, will send a patch + tonight + + +## `/home` Missing + +### IRC, freenode, #hurd, 2013-10-04 + + <braunr> now, why is there no /home in df output ? + <teythoon> not sure + <teythoon> note how /dev/tty* end up in /proc/mounts, those are passive + translators too, no? + <braunr> yes + <braunr> but that's a good thing i guess + <braunr> or was mounts intended for file systems only ? + <braunr> well, in the unix traditional meaning + <teythoon> I think its nice too, yes + <teythoon> but why are they fine and your /home is not... + <braunr> that's weirder + <braunr> also, mounts actually doesn't show passive translators + <braunr> teythoon: does your code perform any kind of comparison ? + <braunr> i see /servers/socket/26 but not /servers/socket/2 + <braunr> s/comparison/filter/g + <teythoon> hmm + <teythoon> well, yes, try /hurd/mtab --insecure / + <teythoon> (I cannot connect to darnassus from here...) + <braunr> ok but that looks unrelated + <braunr> both /servers/socket/26 and /servers/socket/2 refer to the same + translator + <braunr> i was wondering if mtab was filtering similar entries based on + that + <teythoon> no + <braunr> that's weird too then, isn't it ? + <teythoon> yes ;) + <braunr> ok + <teythoon> btw, how is that done with the same traanslator being bound to + two nodes? settrans cannot do that, can it? + <braunr> no it can't + <braunr> the translator does it when started + <teythoon> ah + <braunr> (which means there is a race if both are started simulatneously, + although it's very rare and not hard to solve) + <teythoon> a weird beaving translator then :) + + <braunr> teythoon: if ext2fs is set active, mtab output reports it + + <braunr> teythoon: looks like this bug is what allows mtab not to deadlock + <braunr> teythoon: when i attach it as an active translator, cat freezes + + <braunr> teythoon: if (control && control->pi.port_right == fsys) + <braunr> that's the filtering i was previously talking about + + <braunr> oh please don't name global variables "path" ... + + +### IRC, freenode, #hurd, 2013-10-06 + + <antrik> teythoon: pty-s also bind to two nodes, not only pfinet + + +### IRC, freenode, #hurd, 2013-10-07 + + <braunr> teythoon: please tell us when you're available, we need to work + out the last mtab issues + <teythoon> braunr: I'm available now :) + <teythoon> I'm sorry, I've been very busy the last two weeks, but I've + plenty of time now + <braunr> great :) + <braunr> did you see youpi's mail ? + <braunr> i have the exact same question + <teythoon> I did + <braunr> it seems your code registers active translators + <braunr> but parent translators don't seem to register them when they're + created from passive translators + <braunr> or am i mistaken ? + <teythoon> I'll need a moment to get my hurd machine and myself up to + speed... + <teythoon> braunr: I concur with youpi, hooking into fshelp_fetch_root + should do just fine + <teythoon> I'll just try that + <braunr> ok + <braunr> how do you deal with mtab reporting itself ? + <teythoon> o_O does it do that? + <braunr> no, but it should + <braunr> when i set it as an active translator, i get a deadlock + <braunr> hm + <braunr> teythoon: before you change libfshelp, i'd like you to try + something else + <braunr> use more appropriate names for global variables in mtab.c + <braunr> in particular, the variable path clashes with local names + <teythoon> noted + <braunr> teythoon: as a side note (i'm not asking to rewrite anything) + <braunr> i strongly recommend a very explicit object oriented style of + coding + <braunr> (or data-oriented as it's sometimes called) + <braunr> use prefixes for all your interfaces so they can be made public if + needed (which acts as a namespace and avoids lots of collisions + naturally) + <braunr> use "constructors" and "destructors" (functions that both allocate + and initialize) + <braunr> this helps avoiding leaks a lot too + <teythoon> hm, I thought I did that, could you be more specific? + <braunr> ok didn't see the comment + <braunr> /* XXX split up */ error_t mtab_populate (... + <braunr> :) + <braunr> as a better example, see your code in libfshelp/translator-list.c + <braunr> struct translator should have been treated as an object + <braunr> this would probably have completely avoided any leaks in the first + place + <teythoon> braunr: right, I deviated from that style there + <braunr> teythoon: these are minor details, don't mind them too much, i + just find it helps me a lot + <teythoon> braunr: sure, I appreciate the feedback :) + + +### IRC, freenode, #hurd, 2013-10-08 + + <teythoon> braunr: I'm on to the passive translator not getting registered + issue + <teythoon> however, removing them from the list if the active translator is + killed does not work as expected... I still need to fiddle with the + notifications to get this right + <braunr> ok + + +### IRC, freenode, #hurd, 2013-10-16 + + <teythoon> braunr: btw, I fixed the 'passive translator not showing up in + proc/mounts'-issue + <teythoon> but 4 ports do leak each time a translator is killed and + reinstalled + <teythoon> this happens with passive ones as well as active ones + <braunr> teythoon: is that issue tied to your changed ? + <braunr> changes* + <teythoon> I'm not sure tbh, testing that is on my list of things to do + <braunr> ok + <braunr> first thing to know i guess + <teythoon> yes + + +### IRC, freenode, #hurd, 2013-11-06 + + <braunr> by the way, did you fix mtab for passive translators ? + <braunr> or make any progress ? + <teythoon> I just cleaned up the patch series + <braunr> ah good + <teythoon> I'm still trying to decide whether I leak any ports + + +### IRC, freenode, #hurd, 2013-11-15 + + <teythoon> btw, I haven't forgotten about the passive translator not + showing up in /proc/mounts + <teythoon> I have a patch series, the first patch seems fine, but if I + build hurd packages with the other two (those that actually hook into + dir-lookup), strange things happen + <teythoon> on the first boot, everything is fine, passive translators + showing up in /proc/mounts, nice + <teythoon> but when I reboot, the system kind-of comes back, but something + is very wrong with many (passive?) translators + <teythoon> the system never recovers, I have no idea whats going on there + <braunr> ok + <braunr> push that work in a branch somewhere for review please + <teythoon> right, thanks + <teythoon> braunr: + http://darnassus.sceen.net/gitweb/teythoon/hurd.git/shortlog/refs/heads/feature-translatorslist-detect-passive-translators + + +### IRC, freenode, #hurd, 2014-01-04 + + <youpi> teythoon: did you eventually get any idea about why /proc/mounts is + missing mounts? + <youpi> e.g. I have /boot as a separate partition, it doesn't show up + + +### IRC, freenode, #hurd, 2014-01-05 + + <teythoon> youpi: yes, passive translators are not currently handled + <teythoon> youpi: i have patches for that, but they produce weird results, + braunr promised to take a look + <braunr> teythoon: hum + <teythoon> ^^ + <braunr> i thought they were pending review + <braunr> ! + <braunr> where are they again ? + <teythoon> + http://darnassus.sceen.net/gitweb/teythoon/hurd.git/shortlog/refs/heads/feature-translatorslist-detect-passive-translators + <braunr> ok + <teythoon> they are reasonably straight-forward + <teythoon> but cause this funny issue, after the first reboot with the + patched hurd everything is fine + <teythoon> after the second reboot, everything is weird and broken badly + <braunr> right + <braunr> interesting :) + + +### IRC, freenode, #hurd, 2014-01-06 + + <braunr> teythoon: is it normal that, if ext2fs is started as an active + translator for /home, and then for another directory inside my home, mtab + only reports / and /home and not this third file system ? + <braunr> (with the hurd master version) + <braunr> (the translator for /home is run by root, but the one inside my + home is started with my uid) + <braunr> (and every component on the path is readable/crossable) + + +### IRC, freenode, #hurd, 2014-01-07 + + <teythoon_> braunr: well yes, the mtab tool/translator does not follow + translators bound to nodes not owned by root + <teythoon> braunr: try /hurd/mtab --insecure /home + <braunr> ok + <braunr> good thinking + + <teythoon> braunr: did you encounter any problems after the second reboot ? + <braunr> i'm not yet there + <braunr> work still making me busy + <braunr> and i'm trying to isolate the problem first + <braunr> that is, restrict tests to a single leaf translator + <teythoon> you reproduced the weirdness ? + <braunr> teythoon: attempting + <braunr> teythoon: first i'm trying to check a few things + <braunr> teythoon: i'm running my leaf translator as root now + <braunr> active + <braunr> and i still don't see it :/ + <braunr> one of the components in the path is not own by root + <braunr> is that a problem ? + <teythoon> no, but maybe the mtab translator should check for that... + <braunr> does it check for the node ownership or the process rights ? + <braunr> credentials, rather + <teythoon> node ownership + <braunr> ah, ok + <braunr> ok i see it now + <braunr> oh, also, it looks like settrans -g on an active translator + doesn't work, i get ebusy all the time :/ + <teythoon> oh ? + <teythoon> that could explain the fs corruption i saw + <teythoon> did i break that ? + <braunr> i don't know + <braunr> maybe + <braunr> i think it was possible in the past + + <braunr> teythoon: when isolated, your code works fine + <braunr> i'll try applying it globally + <braunr> btw, how did you do that ? + <braunr> through debian packages ? + <teythoon> i'm trying to get to the point, but i'm still not there + <teythoon> with our uber-buildbot setup i picture myself pushing to a git + repo, wait a little and get the packages from my deb repo... + <teythoon> for now, i have my hurdtest tool that i used during gsoc + <teythoon> with that i can just drop files into a directory and have that + overlayed ontop of my test image + <braunr> hum + <braunr> so you replaced the lib*fs libraries directly ? + <braunr> and the static rootfs ? + <teythoon> yes + * teythoon checks + <teythoon> hm, maybe i just missed a file, not sure anymore + + <braunr> teythoon: with the new libraries, df -h doesn't see passive + translators :/ + <teythoon> braunr: see /proc/mounts please + <braunr> same + <teythoon> or /hurd/mtab / + <teythoon> weird + <braunr> no :/ + <teythoon> b/c when i developed it, i used a test suite to check that every + combination of tmpfs/ext2fs active/passive and every way to get rid of + any translator produced the desired results + <teythoon> i'll look into this + <braunr> teythoon: when i remove the active translator i set on /home, i + get + <braunr> /dev/hd0s1 8.1G 2.0G 5.8G 26% /home + <braunr> hd0s1 being used for / :/ + <braunr> this does need reviewing + <teythoon> this is how i expect the system to react currently + <braunr> oh + <teythoon> w/o these patches + <braunr> hm ok + <braunr> well + <braunr> i'm currently using them + <teythoon> including the root fs ? + <braunr> yes + <teythoon> hmpf + <braunr> i have to mention that i merged master into it + <teythoon> i did the same + <teythoon> currently compiling... + <braunr> i only changed libdiskfs, libnetfs and libfshelp + <braunr> is there something else that should be changed ? + <braunr> (i.e. because of inlining ?) + <braunr> i guess i should rebuild a hurd package just to be sure + <kilobug> braunr: isn't the translator for / statically linked ? if so it + needs to be rebuilt (sorry if I'm saying silly things by popping out of + nowhere) + <braunr> yes i took care of that + + <braunr> teythoon: i've built a hurd package with the three patches and i + don't see passive translators at all + <teythoon> :/ + <braunr> well + <braunr> actually i see a lot of the + <braunr> them + <braunr> just not /home + + <teythoon> braunr: please see + /home/teythoon/build/hurd-upstream/test.{bash,log} + <teythoon> the latter is a log i just created on darnassus + <teythoon> it shows no failures + <teythoon> do you have another translator that is started from a passive + translator record ? + <teythoon> besides /home, if so, does that show up ? + <braunr> well, as i just said, i can actually see many of them + <teythoon> weird + <braunr> http://darnassus.sceen.net/~rbraun/mounts + <braunr> hm + <braunr> let's try without --sync= + <braunr> ah, now i can see it + <teythoon> can you give me the command line you used before + <teythoon> for the /home translator + <braunr> /hurd/ext2fs --sync=30 /dev/hd0s6 + <braunr> but hm + <braunr> i can only see /home when the passive translator is started + <braunr> is that intentional ? + <teythoon> yes + <braunr> ok + <teythoon> and it doesn't work with --sync=30 o_O + <braunr> so, actually, mtab doesn't report passive translators + <teythoon> no + <braunr> it reports active ones only, whether they're started manually or + from passive translators + <teythoon> yes + <braunr> ok + <braunr> that's good enough + <braunr> reporting passive translators wouldprobably require a complete + scan + <teythoon> yes, that was deemed not feasible + <braunr> right + <braunr> i can't reproduce any weirdness + <teythoon> good + <braunr> it seems to just work well + <braunr> except this option parsing problem + <teythoon> thanks for looking into this + <teythoon> yeah + <braunr> sur + <braunr> e + <braunr> thanks for reminding me :) + <teythoon> the actual fix is implementing fsys_get_source + <braunr> i forgot that "pending review" was my review here he + <teythoon> which should actually be file_get_source + + <braunr> teythoon: why does mtab report errors for /proc/swaps and + /xconsole ? + <teythoon> not sure + + <teythoon> btw, i build hurd packages with my patches and it reliably + wreaks havoc on my test vms ... + <braunr> now that's really weird + <braunr> are you certain everything has been cleaned since your manual + replacement of the libraries ? + <teythoon> yes, i use mainly throwaway-vms for such experiments + <braunr> ok + <teythoon> did you include the debian patches ? + <braunr> yes + <teythoon> so did i + <braunr> i based my work on my own packages + <braunr> with thread destruction + <braunr> i'll redo it from the sid ones + <braunr> but before, i guess i should share mine with you + <braunr> so you can test them in your vms + <braunr> we may simply have different configurations + <teythoon> yes + <braunr> something we might have missed just like the --sync parameter + + +### IRC, freenode, #hurd, 2014-01-08 + + <braunr> teythoon: hello + <braunr> see http://darnassus.sceen.net/~rbraun/teythoon/ for the custom + hurd packages + <braunr> they need thread destruction so get the latest gnumach package + from unstable, and the libc packages from my repository first + + +### IRC, freenode, #hurd, 2014-01-09 + + <teythoon> braunr: your packages indeed seem to work + <teythoon> and with mine i encounter a different problem, the proc server + crashes *very* early + <teythoon> this is w/o a rebuilt libc + <teythoon> different as in not the weird one i remember having back when i + wrote those patches + <braunr> hum + <braunr> you're using all my glibc/hurd packages right ? + <teythoon> your packages work fine + <braunr> i wonder if your bug is caused by + 2c9422595f41635e2f4f7ef1afb7eece9001feae + <teythoon> mine don't + <braunr> (or rather, not having it) + <braunr> look at the patches i've added + <braunr> it's included, and i remember i really needed it + <braunr> althouhg it was just about a leak + <braunr> hm + <braunr> i don't know :/ + <braunr> but i strongly suspect your patches are ok + <braunr> and something else is wrong + <teythoon> why would my packages miss that patch ? + <braunr> hum + <braunr> are you testing with your packages built from upstream sources ? + <teythoon> always + <braunr> upstream hurd against debian glibc ? + <teythoon> yes + <braunr> check the patches again + <teythoon> what patches ? + <braunr> the debian ones that you don't include + <braunr> another thing you can do is + <teythoon> err + <braunr> get the latest debian hurd package + <braunr> add your patch only + <braunr> rebuild + <teythoon> i use hurd upstream + all the debian stuff + <braunr> that's weird + <braunr> but hurd upstream has received quite a lot of patches + <braunr> please try from debian hurd + your patch only + + <teythoon> braunr: i'm afraid it might be your patch 3a3fcc81 that breaks + proc + +[[open_issues/libpthread_set_stack_size]]. + + <braunr> teythoon: but anyway, it does look like your patches are actually + fine + <teythoon> yes + <braunr> i'll install my packages on darnassus and test a bit more + <teythoon> there is an issue however + <braunr> ah + <teythoon> grep sd2s1 /proc/mounts + <teythoon> /dev/sd2s1 /dev/sd2s1 /hurd/storeio writable 0 0 + <teythoon> that makes fsck think that /dev/sd2s1 is mounted + <braunr> hmpf + <teythoon> which makes debians fsck magic (when using sysvinit) drop to a + root shell at boot time + <braunr> why does it report a mount point ? + <braunr> or even a device + <braunr> why not none /dev/sd2s1 ? + <teythoon> b/c of the heuristic it uses + <teythoon> and i know, you told me it's a bad idea + <braunr> i did ? + <teythoon> probably + <braunr> hm + <braunr> we said so many things i don't remember + <braunr> but that doesn't look too hard to fix + <teythoon> well, i'll just have to make translators provide meaningful + get_source responses + <teythoon> and get rid of the heuristic + <braunr> ok + <teythoon> so if you use passive translators for the mounts, and not + /etc/fstab, you should be fine + <teythoon> my "traditional" hurd systems are + <braunr> teythoon: i'll wait a bit before deplying it on darnassus then + + +### IRC, freenode, #hurd, 2014-01-13 + + <braunr> teythoon: does your latest patch series take care of --sync ? + <teythoon> yeah, i finally got why the hurd would react strangely after an + reboot, it was umount --all removing vital passive translator records + <teythoon> i never had any issues with --sync + <braunr> ah, umount -a + <braunr> hm + <braunr> do you recall i did :) ? + <teythoon> umount -a was only run with the sysvinit scripts, that's why you + didn't see that issue, only me + <teythoon> yes, i do + <braunr> yes, i see + <teythoon> however, i'm also using --sync 30 on my fs + <braunr> ok so you couldn't reproduce that particular issue + <braunr> hum + <braunr> try --sync=30 + <teythoon> showtrans /media/scratch + <teythoon> /hurd/ext2fs --sync=30 /dev/sd1s1 + <teythoon> works fine + <braunr> now that's weird :) + <teythoon> then again, previously there was another bug + <braunr> but then the patches i've tested are not the complete series you + sent + <teythoon> in the dir lookup function, if a passive translator is started + <teythoon> say, if i first access /proc/foo, /proc/foo would be recorded, + not /proc + <teythoon> i fixed that yesterday + <braunr> ok + <teythoon> maybe it was b/c of that + <braunr> but hm + <braunr> why would /proc be recorded ? + <teythoon> now ? + <braunr> i mean, /proc should be recorded at /, and /foo at /proc + <braunr> right ? + <teythoon> yes + <braunr> and that wasn't the case ? + <teythoon> but what happened was that proc/foo was recorded as a child + translator for / + <braunr> ohh + <teythoon> yes + <braunr> i see + <braunr> well, i'm not sure it's that bug, since the translator involved + was on /home + <teythoon> same problem + <teythoon> it's unlikely that the translator was started b/c of a /home + lookup + <teythoon> much more likely that the first lookup is /home/someone + <braunr> yes + <braunr> but mtab correctly reported /home without --sync, and not when the + option was present + <braunr> and that part doesn't quite make sense to me + <teythoon> how did you trigger the startup + <teythoon> ? + <braunr> ssh i believe + <teythoon> hm + <teythoon> anyways, i could not reproduce this issue + <braunr> do you have packages somewhere i can test ? + <teythoon> yes + <braunr> oh and btw + <teythoon> http://darnassus.sceen.net/~teythoon/hurd-ci/ + <braunr> something you could do to deal with umount -a + <braunr> but i guess that's what you did already + <braunr> is to only shut the active translator down + <teythoon> + http://git.sceen.net/hurd/hurd.git/commitdiff/0033d20449b3bb558f2ea470983018db39b572aa + <teythoon> yeah, i thought about that + <teythoon> but i believe that is not the right hting to do + <braunr> yes i know but i'm not sure that's the right approach + <braunr> hm :) + <teythoon> b/c if on linux you do umount /foo && ls /foo, foo will be empty + <braunr> yours is probably more posix-friendly + <teythoon> if the passive translator lookup is left, /foo will be restarted + <braunr> ok + <teythoon> s/lookup/record/ + <braunr> that's one reason i'm not very fond of passive translators tbh + <teythoon> yep + <braunr> i'd reserve them as a user-oriented hurd-specific feature + <braunr> anything that must behave as mount/umount expects has to be active + anyway + <braunr> ok let's give a quick shot at your packages :) + + <braunr> teythoon: works fine :) + <braunr> mtab still reports console entries though + <braunr> is tha texpected ? + <teythoon> braunr: kind of + <teythoon> braunr: /bin/console is a netfs-based translator, probably for + multiplexing, dunno exactly + <braunr> i see + + +### IRC, freenode, #hurd, 2014-01-14 + + <youpi> teythoon: passive translators do work fine in mtab now, thanks :) + <braunr> indeed :) + + +### IRC, freenode, #hurd, 2014-02-11 + + <antrik> another topic: what's the rationale again behind umount removing + passive translators?... + <teythoon> antrik: umount is for compatibility with unixoid systems + <teythoon> consider umount /foo; ls /foo + <teythoon> if umount would leave the passive translator record on /foo, + /foo would be started again + <antrik> but mount never creates passive translators, right? + <antrik> so why would umount remove them? they are none of its business... + <teythoon> sure, you can see it this way + <teythoon> still, i like the way it is now, hence i implemented it this way + ;) + <youpi> teythoon: but then umount -a unmounts all passive translators + <youpi> include ~joe/http:/ + <youpi> s/include/including/ + <youpi> I tend to agree with antrik + <teythoon> i won't oppose a change of course + <teythoon> and yes, we have seen problems b/c of that. otoh those can be + fixed (and they are, i just sent a patch fixing that) + <youpi> teythoon: well, it's not only about http:, joe user may want to + mount its own iso image, or whatever + <teythoon> thats true + <teythoon> no + <teythoon> it's not + <teythoon> /proc/mounts does not contain translators bound to nodes that do + not belong to root + <teythoon> but sure, we can change umount + <braunr> i agree + <braunr> active translators can be viewed as unix mounts + <braunr> passive translators are an entirely hurdish feature + <braunr> but then, servers such as pflocal and pfinet shouldn't probably + not be passive translators + <antrik> braunr: shouldn't not? what are you trying to say? :-) + <braunr> woops + <braunr> i'm not trying to make this unconfusingly clearer + <braunr> :p + <braunr> pflocal and pfinet should probably be active translators + <antrik> why? + <braunr> hum wait + <braunr> i had a reason weeks ago + <braunr> but now it looks the opposite is better actually :p + <braunr> so that they don't appear in mounts + <braunr> but aiui, there is another property that is tested to make + translators appear in mounts + <antrik> hm... I know this question has been discussed when first talking + about an mtab translator years ago... but don't remember whether there + was any conclusion + <antrik> I think one of the ideas was that translators would opt in for + being considered as mounts... + <braunr> it makes sense to only have file systems in mounts anyway + <antrik> instead of going by the translator type, another option might be + ignoring anything that is backed by a passive translator?... + <antrik> or have a startup option (perhaps with some "smart" defaults) to + request a translator to manifest as a mount or not + <antrik> so many ideas... ;-) + + +## coreutils' `df` + +### IRC, freenode, #hurd, 2014-01-24 + + <braunr> gnu_srs: "df: Warning: cannot read table of mounted file systems: + No such file or directory" + <braunr> you should be able to fix that easily + + +### IRC, OFTC, #debian-hurd, 2014-02-03 + + <pere> /run/mtab also seem to be missing. df do not work. + <teythoon> that's a libc bug + + +### IRC, OFTC, #debian-hurd, 2014-02-05 + + <gg0> i had to ln -s /proc/mounts /var/run/mtab to make df work, what's the + proper fix? + <gg0> (here sysvinit+openrc) + <youpi> gg0: the proper fix for df is to fix the coreutils build + + <pere> I checked the mtab problem, and /etc/hurd/runsystem.gnu via + /etc/hurd/rc fixes the symlink, while runsystem.sysv do not. I suspect + /etc/init.d/checkroot.sh should fix the symlink too. + <youpi> well, atm df looks at /var/run/mtab instead of /etc/mtab only + because it hasn't been rebuilt against a recent glibc, that's all + <youpi> but we can brownpaperbag fix it, yes + <pere> right. so perhaps that is the bug to fix? + <youpi> yes, it is + <youpi> it depends on coreutils actually building + <teythoon> youpi: i thought the proper way to fix the /var/run/mtab issue + is to patch the libc ? + <youpi> it is + <teythoon> the libc defines some macro, on linux it expands to /etc/mtab, + on hurd to /var/run/mtab + <youpi> but you need to rebuild coreutils to get a fixed df + <teythoon> ok, right + <pere> should it be /var/run/mtab or /etc/mtab on hurd? the former seem + more correct, but /run/mtab give more sense given that it should be + available also before /var/ is mounted. + <youpi> to be honest, I don't really care + <youpi> and I thus tend to agree on sticking with what linux does + <youpi> to avoid issues + <youpi> as in: keep debian working mostly the same on all kernels, to avoid + issue + <youpi> s + <pere> well, linux really should move that file away from /etc/ too. :) + <youpi> pere: ok, but let's move at the same time + <youpi> rather than hitting bugs ourselves + <pere> perhaps df should use /proc/mount instead, and get rid of the + problem completely... + <youpi> that can be a way, too + + <pere> I believe <URL: http://bugs.debian.org/737759 > is a good fix for + the mtab problem. + + <rleigh> WRT /etc/mtab the main reason for keeping it is solely for + compatibility; there's no reason not to use /proc/mounts directly (or + /run/mtab if we want a kernel-agnostic location). Whether it's worth + doing something like that is debatable. + <rleigh> The main issue with doing stuff like this nowadays is that you get + shouted at by all the systemd people for making changes... + + +## Memory Leak in `translator_ihash_cleanup` + +### IRC, freenode, #hurd, 2013-10-04 + + <braunr> teythoon: isn't there a leak in translator_ihash_cleanup ? + <teythoon> braunr: looks like, yes + <teythoon> braunr: I probably forgot to add the free (element->name) when I + added the name field + <braunr> teythoon: ok + <braunr> teythoon: i let you fix that :p + <teythoon> braunr: sure ;) diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn index 3e66c870..7b2f07aa 100644 --- a/hurd/translator/pfinet/implementation.mdwn +++ b/hurd/translator/pfinet/implementation.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2000, 2008, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2000, 2008, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -166,6 +166,14 @@ In context of the item on [[/contributing]]. <braunr> rekado: development pace on the hurd has always been slow, no need to apologize + +### IRC, freenode, #hurd, 2014-02-12 + + <braunr> youpi: btw, the patch you finally decided to write yourself making + pfinet continue on driver failure is as expected quite handy :) + <youpi> :) + + ## MAC Addresses [[!tag open_issue_hurd]] @@ -192,6 +200,82 @@ In context of the item on [[/contributing]]. <youpi> it's not plugged inside pfinet anyway +## IRC, freenode, #hurd, 2014-01-15 + + <braunr> 2014-01-14 23:06:38 IPv4 socket creation failed: Computer bought + the farm + <braunr> :O + <youpi> hum :) + <youpi> perhaps related with your change for "lo" performance? + <braunr> unlikely + <youpi> I don't see what would have changed in pfinet otherwise + <braunr> mig generated code if i'm right + <braunr> lib*fs + <braunr> libfshelp + <braunr> looks plenty enough + <braunr> teythoon's output has been quite high, it's not so suprising to + spot such integration issues + + +### IRC, freenode, #hurd, 2014-01-16 + + <braunr> teythoon: so, did you see we have bugs on the latest hurd packages + :) + <braunr> for some reason, exim4 starts nicely on darnassus, but not on + another test vm + <braunr> and there is a "deallocate invalid name" error at boot time + <braunr> it's also present with your packages + <teythoon> yes + + <braunr> not being able to start exim4 and other servers on some machines, + apparently randomly, is a bit frightening to me + <braunr> as the message says, "most probably a bug" + <teythoon> yes + <braunr> so we have to get rid of it as soon as possible so we can get to + the more interesting stuff + <teythoon> but there is no way to attribute this message to a process + <braunr> well, for those at boot time, there is + <teythoon> ? + <braunr> if i disable exim, i don't get it :p + <teythoon> oh ? + <braunr> but again, it doesn't occur on all machines + <braunr> and that part is the one i don't like at all + <teythoon> still, is it in exim, pfinet, pflocal, ... ? + <teythoon> no way to answer that + <braunr> ah right sorry + <braunr> it's probably pfinet, since exim says computer bought the farm on + a socket + <braunr> pflocal had its same pid + <teythoon> ok + <braunr> and after an upgrade, i don't reproduce that + <braunr> good, in a way + <braunr> there still is the one, after auth + <teythoon> yes + <teythoon> i'm seeing that too + <braunr> (as in "exec init proc auth" + <braunr> shouldn't be too hard to fix + <braunr> i'll settle on this one after i'm done with libps + <gnu_srs> (15:21:34) braunr: it's probably pfinet, since exim says computer + bought the farm on a socket: + <gnu_srs> remember my having problems with removing a socket file, maybe + related, probably not pfinet then? + <braunr> gnu_srs: unlikely + <braunr> that pfinet bug may have been completely transient + <braunr> fixed by upgrading packages + <gnu_srs> braunr: k! + + <braunr> and exim4 keeps crashing on my hurd instance at home + <braunr> (pfinet actually) + <braunr> uh, ok, a stupid typo .. + <braunr> teythoon: --natmask in the /servers/socket/2 node, but correct + options in the 26 one .... :) + + +### IRC, freenode, #hurd, 2014-01-17 + + <teythoon> braunr: *phew* + + # Reimplementation, [[!GNU_Savannah_task 5469]] ## [[community/gsoc/project_ideas/tcp_ip_stack]] @@ -205,6 +289,10 @@ In context of the item on [[/contributing]]. <braunr> hm, why not <braunr> i would still prefer using code from netbsd <braunr> especially now with the rump kernel project making it even easier + +[[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel +and Rump Kernels*. + <youpi> well, whatever is easy to maintain up to date actually <braunr> netbsd's focus on general portability normally makes it easy to maintain @@ -225,3 +313,93 @@ In context of the item on [[/contributing]]. Cloudius OSv apparently have isolated/re-used a BSD networking stack, <http://www.osv.io/>, <https://github.com/cloudius-systems/osv>. + + +## IRC, freenode, #hurd, 2014-02-06 + + <akshay1994> Hello Everyone! Just set up my Hurd system. I need some help + now, in selecting a project on which i can work, and delving further into + this. + <braunr> akshay1994: what are you interested in ? + <akshay1994> I was going through the project ideas. Found TCP/IP Stack, and + CD Audio grabbing interesting. + <braunr> cd audio grabbing ? + <braunr> hm why not + <braunr> akshay1994: you have to understand that, when it come to drivers, + we prefer reusing existing implementations in contained servers than + rewriting ourselves + <braunr> the networking stack project would be very interesting, yes + <akshay1994> Yes. I was indeed reading about the network stack. + <akshay1994> So we need an easily modularise-able userspace stack, which we + can run as a server for now. + <akshay1994> And split into different protocol layers later. + <braunr> hum no + <braunr> we probably want to stick to the model we're currently using with + pfinet + <braunr> for network drivers, yes + <braunr> i strongly suspect we want the whole IPv4/IPv6 networking stack in + a single server + <braunr> and writing glue code so that it works on the hurd + <braunr> then, you may want to add hooks for firewall/qos/etc... + <braunr> (although i think qos should be embedded to) + <braunr> sjbalaji: i also suggest reusing the netbsd networking stack, + since netbsd is well known for its clean portable code, and it has a + rather large user base (compared to us or other less known projects) and + is well maintained + <braunr> the rump project might make porting even easier + +[[open_issues/user-space_device_drivers]], *External Projects*, *The Anykernel +and Rump Kernels*. + + <akshay1994> okay! I was reading the project idea, where they mention that + a true hurdish stack will use a set of translator processes , each + implementing a different protocol layer + <braunr> a true hurdish stack would + <braunr> i strongly doubt we'll ever have the man power to write one + <braunr> i don't really see the point either to be honest :/ + <akshay1994> haha! + <braunr> but others have better vision than me for these things so i don't + know + <akshay1994> So, what are the problems we are facing with the current + pfinet implementation? + <braunr> it's old + <braunr> meaning it doesn't implement some features that may be important, + and has a few bugs due to lack of maintenance + <braunr> maintenance here being updating the code base with a newer + version, and we don't particularly want to continue grabbing code from + linux 2.2 :) + <akshay1994> I see. I was just skimming through google, about userspace + network stacks, but I think I might need to first understand how the + current one works and interacts with the system, before proceeding + further! + <braunr> yes + <braunr> the very idea of a userspace stack itself has little implications + <braunr> it basically means it doesn't run in system mode, and instead of + directly calling functions, it uses RPCs to communicate with other parts + of the system + + <akshay1994> braunr: I looked at the netBSD net-stack, and also how hurd + (and mach) work. I'm starting with the hacking guide. Seems a little + difficult :p + <akshay1994> But i feel, I'll get over it. Any tips? + <braunr> akshay1994: it's not straightforward + <akshay1994> I know. Browsing through pfinet gave me an idea, how complex a + thing I'm trying to deal with in first try :p + + +### IRC, freenode, #hurd, 2014-02-09 + + <antrik> braunr: the point of a hurdisch network stack is the same as a + hurdish block layer, and in fact anything hurdish: you can do things like + tunelling in a natural manner, rather than needing special loopback code + and complex control interfaces + <braunr> antrik: i don't see how something like the current pfinet would + prevent that + + +# IRC, freenode, #hurd, 2013-10-31 + + <braunr> looks like there is a deadlock in pfinet + <braunr> maybe triggered or caused by my thread destruction patch + +[[open_issues/libpthread/t/fix_have_kernel_resources]]. diff --git a/hurd/translator/pflocal.mdwn b/hurd/translator/pflocal.mdwn index fdcc39f1..13b5e01b 100644 --- a/hurd/translator/pflocal.mdwn +++ b/hurd/translator/pflocal.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2000, 2008, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2000, 2008, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -33,3 +33,42 @@ implementation). (maybe not so interesting case). <pinotree> pflocal does not support it <gnu_srs> Is that of interest at all? + + +## IRC, freenode, #hurd, 2014-01-14 + + <braunr> sudo -s eats 100 cpu :/ + <braunr> possibly because of pflocal + <braunr> only change on pflocal (notwithstanding the libraries) is + "pflocal: improve the demuxer functions" + <braunr> teythoon: why did you change the order of the function calls in + sock_demuxer ? + <youpi> for efficiency iirc + <braunr> yes, looks reasonable + + +### IRC, freenode, #hurd, 2014-01-16 + + <braunr> i suspect the "improve the demuxer functions" changes may have + hard-to-understand side effects + <teythoon> yes, mostly being faster + <braunr> ah, the latest sudo has been fixed + <braunr> haha :) + <teythoon> ^^ + <braunr> that one is easy to understand :) + <braunr> sudo was looping around calls to pflocal + <braunr> and exim crashed because of pfinet + <braunr> and those servers were only affected by these changes, other than + the library ones which don't seem to apply at all + <braunr> but with sudo being fixed, i'm not sure it's relevant any more + <teythoon> i'd say being faster could easily cause hard-to-understand side + effects + <braunr> ah, yes + <braunr> being faster isn't the side effect itself ;p + <braunr> nice, sudo was bugged on linux too, its behaviour matched its hurd + version perfectly + + +## [[hurd/fsysopts]] + +Doesn't support [[hurd/fsysopts]]. diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn index d5e0960c..924abc99 100644 --- a/hurd/translator/proc.mdwn +++ b/hurd/translator/proc.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 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 @@ -63,6 +64,11 @@ It is stated by `/hurd/init`. something special +## IRC, freenode, #hurd, 2013-09-25 + + <braunr> so nice to finally see proc in top :) + + # Process Discovery ## IRC, freenode, #hurd, 2013-08-26 @@ -73,3 +79,68 @@ It is stated by `/hurd/init`. < braunr> teythoon: i agree with you on proc process-to-task mapping < braunr> that's something i intend to completely rework on propel < braunr> in a way similar to how pid namespaces work on linux + + +# PID "Races" + +## IRC, freenode, #hurd, 2014-01-26 + + <quotemstr> Does Hurd have anything that generally solves PID races? + <youpi> what kind of race are you thinking about? + <youpi> I'm not sure, but I guess keeping a reference to a task port will + prevent the proc server from recycling the corresponding pid + <quotemstr> Yep. + <quotemstr> How does the Hurd avoid the obvious denial-of-service attack + that results? + <youpi> well quotas would probably be enough + <youpi> that's not a new issue :) + <quotemstr> Fair enough. + <quotemstr> Returning to the POSIX-y world after a few year stint over in + NT-land, it's infuriating that it's still not possible to write a + reliable killall(1) under Linux or the BSDs. + <quotemstr> I'm glad Hurd solves the problem. :-) + <braunr> but it doesn't + <braunr> how can you write a reliable killall ? + <youpi> so keeping a reference to the task port is not enough? + <braunr> i'm not sure + <braunr> first i'd like quotemstr to clearly define the reliability problem + of killall + <quotemstr> braunr: The possibility that a PID might be used between the + time you decide to kill it and the time you actually kill it. + <braunr> well, it would have to wrap around for that + <quotemstr> braunr: So? It's possible. + <braunr> i guess that's what you refer to + <braunr> ok + <braunr> well yes, it's possible to easily create a routine that atomically + increases the number of references on a task/process when looking it up + <braunr> preventing its removal from the list of processes reported by the + proc server + <quotemstr> Like OpenProcess? :-) Would this reference count be + automatically decremented if the task owning the reference is killed? + <braunr> it would clearly not be a "posixy killall" then, but i suppose we + don't care about that at all + <braunr> no + <quotemstr> Oh. + <braunr> destroying an object doesn't remove its references + <quotemstr> So it's possible to leak the reference and prevent reuse of + that PID forever. + <braunr> hardly + <braunr> for that, killall would have to run a long time + <quotemstr> braunr: No, I'm talking about our hypothetical killall itself + being killed after taking out a reference on another process, but before + releasing it + <braunr> but a malicious killall could + <braunr> when a task is destroyed, its capability space is destroyed too + <braunr> removing all the references it previously had + <quotemstr> Ah, I see. + <braunr> the leaks we have occur in servers + <braunr> which sometimes act as clients to other servers + <braunr> and run forever + + +# Crashes due to rpctrace + +## IRC, freenode, #hurd, 2014-02-18 + + <braunr> something is wrong in the proc server + <braunr> rpctrace is often causing it to crash .. diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index fc071337..54de54c2 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2012, 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 @@ -348,6 +348,35 @@ Disadvantage is that every program using this needs to be patched. This is used in `[LLVM]/lib/Support/Unix/Path.inc`. +### IRC, OFTC, #debian-hurd, 2013-11-10 + + <mjt> Hello. Does hurd have /proc/self/exe equivalent, to "re-exec myself" + ? + <youpi> no, only argv[0] + <mjt> busybox uses /proc/self/exe by default to re-exec itself when running + one of its applets, or failing that, tries to find it in $PATH. I guess + it doesn't work on hurd... :) + <mjt> and argv0 is unreliable + <youpi> some discussion on the hurd wiki talks about using Dl_info DLInfo + <youpi> which contains DLInfo.dli_fname + <youpi> err, I mean, callling dladdr(&main, &DLInfo); + <youpi> this is kernel-agnostic, provided one uses glibc + <mjt> um. -ldl. nice for static linking + <mjt> gcc t.c -ldl -static + <mjt> ./a.out + <mjt> fname=AVA� �j + <mjt> bah :) + <mjt> (it just prints dli_fname) + <teythoon> :/ + <youpi> ah, yes, that won't work with static linking + <teythoon> fixing /proc/self is on my todo list, it shouldn't be too hard + <youpi> since in that case it's the exec server which sets the process up, + not dl.so + <teythoon> but we do not have the exe link either + <mjt> (the above test run was on linux not on hurd, fwiw_ + <mjt> ) + + # `/proc/[PID]/fd/` ## IRC, freenode, #hurd, 2012-04-24 @@ -436,6 +465,89 @@ Also used in `[GCC]/intl/relocatable.c`:`find_shared_library_fullname` for `#ifdef __linux__`. +### IRC, freenode, #hurd, 2013-10-03 + + <camm`> what's the equivalent of cat /proc/self/maps on hurd? + <braunr> camm`: for now, /proc/self doesn't work as expected + <camm`> thanks, I just want to get a list of maps and protection status for + a running process -- how? + <braunr> vminfo + <camm`> thanks so much! I'm trying to debug an unexec failure on hurd when + a linker script is present. All works with the default script, but when + the text address is changed, unexec fails, running into a page with no + access in the middle of the executable: 0xc4b000[0x1000] (prot=0, + max_prot=RWX, offs=0xb55000) + <camm`> I get a segfault when trying to read from this page. + <braunr> unexec ? + <camm`> emacs/gcl/maxima/acl2/hol88/axiom use unexec to dump a running + image into a saved executable elf file. + <braunr> what is unexec ? + <braunr> ok looks like a dirty tool + <braunr> camm`: what is segfaulting, unexec or the resulting executable ? + <camm`> unexec opens the file from which the running program was originally + executed, finds its section start addresses, then writes a new file + replacing any data in the old file with possibly modified versions in + running memory. The reverse of 'exec'. + <camm`> the read from running memory delimited by the addresses in the + executable file is hitting a page which has been protected with *no* + access, and is segfaulting. Somehow, when the binary file is loaded, + hurd turning off all rights to this page. + <camm`> let me check the stack location ... + <camm`> ok I think I've got it -- hurd moves the sbrk(0) address away from + the end of .data (as reported by readelf) if the addresses are low, + presumably to avoid running into the stack. + <camm`> starting sbrk(0)!=.data+data_size on hurd + <braunr> i'm not sure there is anything like the heap on the hurd + <braunr> sbrk is probably implemented on top of mmap + <braunr> camm`: hm no, i'm wrong, glibc implements brk and sbrk mostly as + expected, but remapping the area isn't atomic + <braunr> "Now reallocate it with no access allowed" + <braunr> then, there is a call to vm_protect + <braunr> and no error checking + <braunr> ... + <camm`> ok, that's fine, but need to know -- in general there is no + relationship between the address returned by sbrk(0) and the .data + addresses reported by readelf on the file, (hurd only) yes? + <braunr> i don't know about that + <braunr> there should be .. + <camm`> Specific example: readelf -a -> [24] .data PROGBITS + 000f5580 0c4580 000328 00 WA 0 0 32 + <camm`> + <camm`> sbrk(0)->(void *) 0x8021000 + <braunr> camm`: is that on an executable or a shared object ? + <camm`> executable + <braunr> 000f5580 looks very low + <camm`> This is using a linker script. The default setup works just fine. + <camm`> I think it (might) make sense for hurd to silently do this give the + placement of the C stack, but the assumptions behind my algorithm need + changing (perhaps). + <camm`> (I probe in configure the allowable range of __executable_start, + and then choose a value to either ensure a large free signed range around + NULL, or a low data start to maximize heap) + <camm`> braunr: are there any guarantees of sbrk(0)==.data+size without a + linker script? + <braunr> camm`: i'm not sure at all + <braunr> sbrk isn't even posix + <camm`> thanks + + +## IRC, freenode, #hurd, 2014-02-22 + + <ignaker> i'm trying to implement proc/maps + <ignaker> actually I can't well evaluate complexity of tasks. However, I + appreciate your comments + <braunr> the complexity can be roughly estimated from the number of + components involved + <braunr> proc/maps involves procfs, ports, virtual memory, and file systems + <braunr> the naive implementation would merely be associating names to + memory objects, and why not, but a more complete one would go ask file + system servers about them + <braunr> perhaps more + <braunr> although personally i'd go for the naive one because less + dependencies usually means better reliability + <braunr> something similar to task_set_name could do the job + + # `/proc/[PID]/mem` Needed by glibc's `pldd` tool (commit @@ -471,3 +583,56 @@ Needed by glibc's `pldd` tool (commit <braunr> both htop and top seem to have problems report the cpu time <braunr> so i expect the problem to be in procfs + + +# IRC, freenode, #hurd, 2013-10-03 + + <braunr> teythoon: any reason the static variable translator_exists isn't + protected by a lock in procfs/rootdir.c ? + + +## IRC, freenode, #hurd, 2013-10-04 + + <braunr> teythoon: can you tell me why translator_exists isn't protected + from shared access in rootdir_mounts_exists ? + <teythoon> braunr: hm, dunno tbh, I probably thought the race was harmless + enough + <braunr> it probably is + <braunr> settrans -Rg doesn't work on procfs :( + + +# Kernel PID + +## IRC, freenode, #hurd, 2013-09-25 + + <braunr> hm cute, htop layout has become buggy, top just won't start + <teythoon> braunr: make sure your procfs knows the correct kernel pid + <teythoon> # showtrans /proc + <teythoon> /hurd/procfs -c -k 3 + <teythoon> we could have handled this nicer if procfs were integrated + upstream + <teythoon> we should probably just update the default + <braunr> teythoon: mhm + <braunr> $ fsysopts /proc + <braunr> /hurd/procfs --stat-mode=444 --fake-self=1 + <braunr> $ showtrans /proc + <braunr> /hurd/procfs -c + <pinotree> -c == --stat-mode=444 --fake-self=1 + <braunr> better indeed + <braunr> teythoon: thanks + + +## IRC, freenode, #hurd, 2013-10-04 + + <braunr> youpi: i fixed procfs on ironforge and exodar to be started as + procfs -c -k 3 + <braunr> without -k 3, many things as simple as top and uptime won't work + + +## IRC, freenode, #hurd, 2013-10-24 + + <gg0> braunr: i'm using your repo and i can't see cpu percentage in htop + anymore, all zeroes, confirmed? + <braunr> gg0: no + <braunr> gg0: you probably need to reset procfs + <braunr> gg0: settrans /proc /hurd/procfs -c -k 3 diff --git a/hurd/translator/term.mdwn b/hurd/translator/term.mdwn new file mode 100644 index 00000000..834ef9bd --- /dev/null +++ b/hurd/translator/term.mdwn @@ -0,0 +1,220 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +The *term* translator implements POSIX termios discipline. + + +# Open Issues + +## [[open_issues/Term_Blocking]] + +## Leaks/Not Re-used/Not Terminating + +[[!tag open_issue_hurd]] + + +### IRC, freenode, #hurd, 2013-10-14 + + <braunr> good news + <braunr> the terminal leak is related to privilege separation + +[[tschwinge]] confirming (using `ssh -t [machine] tty`) that with privilege +separation enabled there is this problem, and once disabled it goes away. + + <atheia> I love how, as an unknowing by-stander, that is somehow good news + :-) + <braunr> :) + <braunr> it's a good news because 1/ we have more knowledge about the issue + <braunr> and 2/ it may not even be a hurd bug + <braunr> but rather an openssh-on-hurd bug + <braunr> this explains why i didn't see the issue on anything else + (mach/hurd consoles, x terminals) + <braunr> and this will also indirectly solve the screen lockup issue + <teythoon> braunr: good catch :) + <braunr> s/a good news/good news/ + <atheia> ah, yes, both definitely good news. Congrats on the progress. + <braunr> i remember we used to disable privilege separation in the past + <braunr> i'll have to dig what made us use it + +[[news/2010-09]]. + + <braunr> interesting, screen seems to be affected nonetheless + <braunr> so it's something common to both screen and ssh privsep + <braunr> apparently, what sshd+privse and screen have in common is a fifo + <braunr> so it's probably a tricky hurd bug actually + + +### IRC, freenode, #hurd, 2013-10-16 + + <braunr> pflocal is leaking ports .. + <braunr> this might be what blocks terminals + * pinotree gives braunr a stick of glue + <braunr> thanks + + <braunr> pflocal leaks struct sock .. + <braunr> grmbl + + <braunr> hm nice, pflocal leaks each time a socket is bound and/or accepted + on + <braunr> looks like a simple ref mess + <pinotree> braunr: really? + <braunr> yes + <pinotree> a leak in pflocal feels strange, never noticed it taking lots of + memory (and it's used a lot) + <braunr> it's a port leak + <braunr> well + <braunr> no it's both a memory and port leak + <braunr> not sure which one is the root cause yet + <braunr> i guess server sockets aren't automatically unbound + <braunr> if you want to see the leak, just disable priv separation in ssh + (to avoid the terminal leak ....) and write a shell loop to start ssh + your_server echo hello + <braunr> google shows mails about the leak in the past + <braunr> i also hope it fixes the terminal leak, although i'm really not + sure :( + + +### IRC, freenode, #hurd, 2013-10-17 + + <braunr> hm nice, apparently, there is no pflocal leak + <braunr> but a libdiskfs one ! + <braunr> since ext2fs enables the ifsock shortcut + <braunr> seems like it leaks a reference on sock node deletion + <teythoon> braunr: have you looked at libdiskfs/dead-name.c? + <teythoon> braunr: I think I'm hunting a very similar problem + <braunr> i'm doing it now + <teythoon> I had the problem of dead name notifications not being delivered + <braunr> wow + <teythoon> b/c I held no reference to the ports_info thing, so the dead + name handler in libports could no longer find the pi struct, so the + notification was silently dropped + <braunr> i see + <braunr> but it looks like dropping a node makes sure the associated + sockaddr has been deleted if any + <teythoon> are you sure the node is dropped in the first place? + <braunr> no + <braunr> well + <braunr> i see something happenning at the pflocal side when removing the + node + <braunr> but there is still a send right lingering somewhere + <braunr> (see why we need a global lsof :p) + <teythoon> indeed + <braunr> i'll try portinfo with that option we talked about + <teythoon> yes + <braunr> 121 => 1682: send (refs: 1) + <braunr> yep, ext2fs still has it + <teythoon> (I wonder how portinfo does that...) + <braunr> i guess it imports rights from the target task + <braunr> and see if it gets the same name as a local right + <teythoon> makes sense + <braunr> easy to check + <teythoon> well, no, it cannot do that for receive rights + <braunr> it creates an empty task just for that purpose + <braunr> and uses mach_port_extract_right + <teythoon> but it works as you described, yes + <braunr> so yes it does work for receive rights too + <teythoon> yes + <teythoon> cool :) + <braunr> so it assumes identical port names are part of the ipc interface + <braunr> something neal said we shouldn't rely on + <braunr> iirc + <teythoon> yes, I remember something like that too + <braunr> here is the strange thing + <braunr> node->sockaddr is deallocated on a dead name notification + <braunr> drop_node checks that sockaddr is null + <braunr> so how can the dead name notification occur before the node is + dropped ? + <braunr> so maybe the node is still around indeed + <braunr> apparently, libdiskfs considers the address holds a reference on + the node + <braunr> on the other hand, the server socket won't get released unless the + address gets a no-sender notification ... + <braunr> this should probably be turned into a weak reference + <braunr> teythoon: indeed, the node is leaked + + <braunr> pflocal crashes when removing correctly deallocating addresses and + removing server sockets :/ + + <braunr> ok, pflocal bug fixed + <braunr> still have to fix the libdiskfs leak + <braunr> and libdiskfs leak fixed too + <braunr> :) + <braunr> i'll build hurd packages with my changes to make sure i don't + break something before comitting + <braunr> and see if this fixes the term issue + + <braunr> looks like my patches work just fine :) + <braunr> it doesn't solve the term issue though + + <braunr> so, according to portinfo, pflocal has send rights to terminals oO + + <braunr> mhhhmmmmmm + <braunr> openssh seems to pass terminal file descriptors through unix + sockets when using privilege separation + <pinotree> braunr: i a write(sock, &pid, sizeof int) (or the like)? + <pinotree> *ie + <braunr> not pid, file descriptors + <braunr> SCM_RIGHTS + <pinotree> ah ok + <braunr> the socket send/recv interface does support passing mach ports + <braunr> and the leaked ports do turn into dead names when i kill terminals + <pinotree> yes, we support with a patch pochu did few years ago + <braunr> so it seems the leak is related to libpipe this time + <braunr> ok got it :) + <braunr> pflocal used copy_send instead of move_send + <braunr> \o/ + <braunr> that bug was such a pain + * braunr happy + <teythoon> :) + <pinotree> speaking of it, in pflocal' S_socket_recv is it correct the + "out_flags = 0;"? + <braunr> nice catch + <braunr> although i wonder why flags are returned + <braunr> it may have been set to null to tell us that we don't want to + return flags + <braunr> pfinet seems to use it + <pinotree> but you change a local variable anyway + <braunr> yes it's not useful + <braunr> hmm + <braunr> out_flags is what gets in struct msghdr -> msg_flags + <braunr> so i guess it makes sense to fix it to *out_flags = 0, just to be + safe + <braunr> pinotree: do you want me to push it tonight along with the others + ? + <pinotree> yes please + <braunr> ok + <pinotree> thanks! + <braunr> pflocal seems to not leak any memory or ports at all + <braunr> great :> + + <braunr> there, patches pushed :) + + +### IRC, freenode, #hurd, 2014-02-07 + + <braunr> btw, as a note, there really are leaks in terminals + <braunr> i managed to get a term server eat up to 300M of memory yesterday + + +## `screen` Logout Hang + +[[!tag open_issue_hurd]] + + +### IRC, freenode, #hurd, 2013-10-14 + + <braunr> i fixed term so that screen can shutdown properly + <braunr> read() wouldn't return EIO after terminal hangup + + +### IRC, freenode, #hurd, 2013-10-17 + + <braunr> and the missing EOI prevented screen from correctly shutting down + windows diff --git a/hurd/translator/tmpfs/discussion.mdwn b/hurd/translator/tmpfs/discussion.mdwn index 20aba837..72400121 100644 --- a/hurd/translator/tmpfs/discussion.mdwn +++ b/hurd/translator/tmpfs/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation, +[[!meta copyright="Copyright © 2011, 2012, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -19,6 +19,8 @@ License|/fdl]]."]]"""]] * [[!GNU_Savannah_bug 26751]] +[[!toc]] + # [[Maksym_Planeta]] @@ -430,3 +432,72 @@ License|/fdl]]."]]"""]] <youpi> ok <youpi> but that indeed means writeback of ext2fs works, which is a good sign :) + + +# IRC, freenode, #hurd, 2013-10-04 + + <teythoon> btw, I noticed that fifos do not work on tmpfs + <braunr> teythoon: tmpfs seems limited, yes + <teythoon> that's annoying b/c /run is a tmpfs on Debian and sysvinit + creates a crontrol fifo there + <teythoon> I wonder why I didn't notice that before + <braunr> also, fifos, like symlinks, can be shortcircuited in libdiskfs + <braunr> i wonder if that has anything to do with the problem at hand + +[[mtab/discussion]], *Multiple mtab Translators Spawned*. + + <teythoon> b/c this breaks reboot & friends + <teythoon> I do too + <teythoon> b/c I cannot find any shortcut related code in tmpfs + <braunr> well, it's optional normally + <braunr> so that's ok + <braunr> but has it really been tested when the option wasn't there ? :) + <teythoon> yes, but the tmpfs requests this by setting diskfs_shortcut_fifo + = 1; + <pinotree> hm i remember tmpfs was said to be working with + sockets/fifos/etc, back then when it was fixed + <braunr> teythoon: oh + + +## IRC, freenode, #hurd, 2013-10-11 + + <teythoon> this will have to wait for the next hurd pkg unfortunately, b/c + I broke tmpfs by accident :-/ + <pinotree> how so? + <teythoon> the dropping of privileges broke passive translators and mkfifo + <braunr> there actually is a reason why those are run as root or with the + privilege of their owner + <braunr> privileges should be decoupled from identity + <teythoon> yes + + +## IRC, freenode, #hurd, 2013-11-08 + + <teythoon> braunr: I'm investigating this port leak of mine + <teythoon> well, I thought I introduced one + <teythoon> but I'm not too sure anymore + <teythoon> the setting is this + <teythoon> i start an active tmpfs translator, bind it to foo + <teythoon> then, i create foo/bar with a passive translator entry + <teythoon> i access foo/bar, the passive translator is started + <teythoon> my test suite now covers several methods of making that + translator go away + <teythoon> killing it with 15 or 9 is fine, i.e. does not make the first + tmpfs leak ports + <teythoon> however, doing settrans -g foo/bar does for some reason + <teythoon> i think my code is fine, i spent considerable time on tracking + down this problem, always thinking that i must have introduced it + <teythoon> but another thing just cought my eye, the first tmpfs translator + says this when i do settrans -g foo/bar: + <teythoon> tmpfs/tmpfs: pthread_create: Resource temporarily unavailable + <teythoon> could it be that a no-sender notification is ignored b/c the + handler thread failed to start ? + <braunr> teythoon: i saw this pthread error too + + +# IRC, freenode, #hurd, 2014-02-09 + + <gg0> remounting tmpfs doesn't work if in use + http://paste.debian.net/plain/80937/ + <gg0> you will also get a pthread_create: Resource temporarily unavailable + <youpi> iirc the pthread_create warning happens for any kind of translator diff --git a/hurd/translator/unionfs.mdwn b/hurd/translator/unionfs.mdwn index 2fcd1fad..06524f3e 100644 --- a/hurd/translator/unionfs.mdwn +++ b/hurd/translator/unionfs.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010, 2013 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010, 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 @@ -116,7 +116,7 @@ one will see the information about the `<translator>`, not the `unionfs` translator. Although this might seem the only natural way to do union mounts, one must keep in mind that such transparency deprives one of the possibility to modify the unioned virtual -filesystem exported by `unionfs` at run-time (via `fsysopts`). +filesystem exported by `unionfs` at run-time (via [[fsysopts]]). One can create a nontransparent union mount with the following command: @@ -127,7 +127,7 @@ When running $ fsysopts <node> one will see the information about the `unionfs` translator. Although -this way allows modifying the contents of the unioned filesystem +this way allows [[modifying|fsysopts]] the contents of the unioned filesystem exported by `unionfs` at runtime, the access to `<translator>` is blocked. diff --git a/hurd/translator/wishlist.mdwn b/hurd/translator/wishlist.mdwn index 5b473a2d..4d074df0 100644 --- a/hurd/translator/wishlist.mdwn +++ b/hurd/translator/wishlist.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2013 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 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 @@ -307,10 +307,3 @@ Firmlink to a file according to a filename matching pattern. When a file goes aw ## alphabetfs Organize a large group of files by their first letter. Present one subdirectory for each letter in the alphabet. - -## fsysoptsctl - -Send an fsysopts command to a set of translators. When you have a directory full of translators and you want to send each of them the same runtime option, this translator can do it for you. - - $ settrans -ac all /hurd/fsysoptsctl '/tmp/mystuff/*' - $ fsysopts all --update |