Fwd: Hurd shutdown problems

Further progress trying to track this down: I don't have to shutdown the system to have problems. "swapoff /dev/hd0s5" is enough to cause problems, once enough swap is in use. After a failed swapoff, I have an extra 98 storeio processes running! I don't have to swapoff to have "symptoms". The

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

Hello, Christian Seiler, on Fri 05 Aug 2016 21:09:21 +0200, wrote: > I've attached a patch that fixes this specific issue for me. I > probably won't have time to look at the other issue I reported > here, but with that I'd at least be able to have open-isns > working on Hurd. (And the patch will

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

Richard Braun writes: > On Mon, Aug 08, 2016 at 04:54:47PM +0200, Justus Winter wrote: >> Richard Braun writes: >> > Why not start the translator from the remapped environment too ? >> >> No reason, but this has to be implemented. I started working on a >>

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

On Mon, Aug 08, 2016 at 04:54:47PM +0200, Justus Winter wrote: > Richard Braun writes: > > Why not start the translator from the remapped environment too ? > > No reason, but this has to be implemented. I started working on a > library for writing such chrooting translators,

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

Richard Braun writes: > On Mon, Aug 08, 2016 at 12:55:24PM +0200, Justus Winter wrote: >> Right, I can see how this is a problem. The thing is, remap doesn't >> quite do the job: 1/ it fails to remap relative paths, 2/ if one sets a >> translator record on a node, and that

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

On Mon, Aug 08, 2016 at 12:55:24PM +0200, Justus Winter wrote: > Right, I can see how this is a problem. The thing is, remap doesn't > quite do the job: 1/ it fails to remap relative paths, 2/ if one sets a > translator record on a node, and that translator is then started by the > filesystem, it

Re: Hurd shutdown problems

Hi, Justus Winter wrote: >Have you tried using halt-hurd instead of shutdown? As far as I can >remember, halt-hurd has never caused file system corruption for me, >but I'm pretty sure shutdown did way back when I was still trying >to use it. That is correct. halt-hurd is basically halt -f,

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

Christian Seiler writes: Use the remap translator instead, which is one of the things the Hurd design allows you to do easily. See /bin/remap to easily set one. >>> >>> remap doesn't work at all here, programs then complain >>> that they can't assign

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

On 08/08/2016 12:18 PM, Justus Winter wrote: >> [settrans -ck stuff] > All in all this was just bad advice. Ok, good to know. :) >>> Use the remap translator instead, which is one of the things the Hurd >>> design allows you to do easily. >>> >>> See /bin/remap to easily set one. >> >> remap

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

Christian Seiler writes: > (The following is not really important, rebooting does > work, so it's not a showstopper.) > > On 08/07/2016 09:13 PM, Richard Braun wrote: >> On Sun, Aug 07, 2016 at 08:44:56PM +0300, Esa Peuha wrote: PS: Is there any way to sanely restart

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

(The following is not really important, rebooting does work, so it's not a showstopper.) On 08/07/2016 09:13 PM, Richard Braun wrote: > On Sun, Aug 07, 2016 at 08:44:56PM +0300, Esa Peuha wrote: >>> PS: Is there any way to sanely restart /hurd/pflocal without >>> rebooting? >> >> Yes, the

Re: Hurd shutdown problems

"Brent W. Baccala" writes: > On Sat, Aug 6, 2016 at 7:59 AM, Justus Winter wrote: > >> >> To prevent filesystem damage, try the following. Break into the kernel >> debugger, and kill the auth server using: >> >> !task_terminate($task5) >> >> Then continue

Re: Hurd shutdown problems

On Sat, Aug 6, 2016 at 7:59 AM, Justus Winter wrote: > > To prevent filesystem damage, try the following. Break into the kernel > debugger, and kill the auth server using: > > !task_terminate($task5) > > Then continue using "c", and /hurd/startup should cleanly shutdown the >