Re: Bug#768188: Jessie Installer hangs after processing DHCPv6 stateful addressing
Philipp Kern pk...@debian.org (2015-02-18): On Tue, Feb 10, 2015 at 09:22:25AM +0100, Philipp Kern wrote: On Sun, Feb 08, 2015 at 04:21:25PM +0100, Philipp Kern wrote: On the other hand it also seems wrong for di_exec_shell_log to continue after the invoked binary exited. I suspect that'd mean ppoll() and proper signal handling, but I'm at a loss right now how to do that properly in C. Maybe that's the right place to fix it in the meantime. I guess signalfd would make this rather neat, but it's not available on FreeBSD. :( The alternative would be to overwrite the SIGCHLD signal handler regardless of what has been set before and handle the signal in the library. So now I guess the question is if we revert the change that broke it: Don't kill_dhcp_client without reason (Closes: #757711, #757988) Do not kill_dhcp_client after setting the hostname and domain, otherwise Linux udhcpc will stop renewing its lease, and on other platforms dhclient will de-configure the network interface (Closes: #757711, #757988) At this point kFreeBSD is no longer a release architecture and the other platform using dhclient is Ubuntu. GNU/kFreeBSD people are (AFAICT) going to try and get an unofficial release out, so pushing a regression in their way doesn't look too good to me. Maybe using an #ifdef here to avoid killing the DHCP client on kfreebsd, and reinstating the previous codepath on linux would be an acceptable compromise until some evolved signal/process handling pops up (during the stretch release cycle)? (No idea about hurd; anyway, adding both porter lists to Cc.) Mraw, KiBi. signature.asc Description: Digital signature
Re: Bug#768188: Jessie Installer hangs after processing DHCPv6 stateful addressing
Cyril Brulebois wrote: Philipp Kern pk...@debian.org (2015-02-18): So now I guess the question is if we revert the change that broke it: Don't kill_dhcp_client without reason (Closes: #757711, #757988) Do not kill_dhcp_client after setting the hostname and domain, otherwise Linux udhcpc will stop renewing its lease, and on other platforms dhclient will de-configure the network interface (Closes: #757711, #757988) At this point kFreeBSD is no longer a release architecture and the other platform using dhclient is Ubuntu. GNU/kFreeBSD people are (AFAICT) going to try and get an unofficial release out, so pushing a regression in their way doesn't look too good to me. Maybe using an #ifdef here to avoid killing the DHCP client on kfreebsd, and reinstating the previous codepath on linux would be an acceptable compromise until some evolved signal/process handling pops up (during the stretch release cycle)? Firstly, thanks for the heads-up. We did expect that during freeze, some regressions may be introduced that affect only GNU/kFreeBSD, and we'd have to fix things up in our unofficial release, perhaps rolling packages back to an older version, or uploading a patched version with +kfreebsd suffix. So, I'm happy if you decide to revert this. At first glance, it reads like a limitation of udhcpc/dhcp6c only? Killing it sounds like a workaround (which perhaps creates other issues), and an ifdef linux also seems wrong in this context (and for Ubuntu). kill-all-dhcp could be told never to kill ISC dhclient, but that too is wrong, as this is also used to implement the 'Cancel' button in the netcfg dialogs. Maybe there is still a better solution? Or perhaps we could add something that kills *only* udhcpc/dhcp6c, could clearly annotate it as this is a workaround for bug #768188. Then it shouldn't affect Ubuntu, or derivatives/ports using ISC DHCP at all. And if many years pass before someone comes back to look at this, they should understand why it's there. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150218220527.gc22...@squeeze.pyro.eu.org
Re: Static binaries and nss (dlopen actually)
Roland McGrath, le Wed 18 Feb 2015 16:40:06 -0800, a écrit : The short answer is that it's pretty well hopeless. Ok, that's what I was feeling, thanks for the confirmation :) Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150219004829.gi2...@type.youpi.perso.aquilenet.fr
Re: Static binaries and nss (dlopen actually)
The short answer is that it's pretty well hopeless. For the Hurd you really really do not want to use static linking. Because of the structure of the system, it's much like having a quarter or third of the Linux kernel baked into each application binary. On Linux and other Unix-like systems, we can get away with the multiple libcs situation because there really is not very much information that they need to share. We have a little bit of effort for one libc to notice the sbrk usage of the other libc, but beyond that they can be ignorant of each other's existence and get along OK. In the Hurd, there is so much more crucial state of the process that is maintained only by libc that it's a wholly different picture. If you have two Hurd libcs, each one will have its own idea of file descriptors, of signals and the signal state of each thread, and on and on. If we bent over backwards to invent new ways for them to communicate with each other, it would just wind up being some bad kludges implementing the crux of what dynamic linking is really about. There is really no reason not to just use actual dynamic linking instead. -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150219004006.39f732c3...@topped-with-meat.com
