The term translator implements POSIX termios discipline.
Open Issues
Term Blocking
Leaks/Not Re-used/Not Terminating
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
<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
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