ifupdown hangs pc either in boot or shutdown

[Debian Bug Importer]

Automatically imported from Debian bug report #256680
http://bugs.debian.org/256680

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #256680
http://bugs.debian.org/256680

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 28 Jun 2004 14:53:30 +0200
From: Helge Hafting <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: ifupdown hangs pc either in boot or shutdown

Package: ifupdown
Version: 0.6.4-4.8
Severity: critical
Justification: breaks the whole system

For a long time, I have been unable to shutdown the pc. Today
I figured out why.

My /etc/network/interfaces contains the line
auto lo eth0
in order to bring up both the loopback and the ethernet
interfaces. Documentation supports this config.

Unfortunately, this means ifupdown brings down "lo" too at
shutdown time, and that hangs shutdown because the
command "ifdown -a" which is part of this package never
ever completes. It hangs - forever.
(I can bring down lo anythime with ifconfig, but not with ifdown)

I tried to simply remove "lo" from "interfaces". That
wreaks havoc on the boot, because "lo" does not come up
and ifup hangs. So I tried a simple workaround, by putting
"ifconfig lo up" in another script so that lo is up
when "ifup -a" runs. Unfortunately, this didd not help.
"ifup -a" still hangs, "making the whole system unuseable".

So I am stuck.
ifup seems to really need to bring up lo itself.
ifdown seems to really need to _not_ touch lo.
(Removing lo from "interfaces" and "ifstate" before
shutting down lets me shot down normally)

Rebooting this machine remotely is completely impossible,
It will either get stuck shutting down or while booting.
Getting stuck at shutdown is easy, because sysrq+S+U+B
shuts down the filesystems and reboots without
furter shutdown scripts. Unfortunately, I have to be
at the console to do this.
Getting stuck at boot means to boot with init=/bin/sh
and then fix the config files and reboots. This is a major
annoyance.

ifup and ifdown seems to be broken, unfortunately netbase
depends on the ifupdown package when using debian testing.

Helge Hafting

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.7-mm3
Locale: LANG=no_NO.UTF-8, LC_CTYPE=no_NO.UTF-8

Versions of packages ifupdown depends on:
ii debconf [debconf-2.0] 1.4.28 Debian configuration management sy
ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an
ii net-tools 1.60-10 The NET-3 networking toolkit

-- debconf information:
  ifupdown/convert-interfaces: true

[Thomas Hood (jdthood-aglu)]

severity 256680 important
severity 254705 important
severity 208700 important
merge 254705 256680 208700
thanks

On Mon, 2004-06-28 at 14:53, Helge Hafting wrote:
> Unfortunately, this means ifupdown brings down "lo" too at
> shutdown time, and that hangs shutdown because the
> command "ifdown -a" which is part of this package never
> ever completes. It hangs - forever.

Can you figure out why it hangs? At what stage, exactly, does it hang?

Does it help if you apply this patch to /etc/init.d/networking?

--- networking_ORIG 2004-06-28 23:18:57.000000000 +0200
+++ networking 2004-06-28 23:19:19.000000000 +0200
@@ -83,6 +83,7 @@
         else
             echo -n "Deconfiguring network interfaces..."
             ifdown -a
+ ifup lo
      echo "done."
         fi
  ;;

--
Thomas Hood <email address hidden>

[Debian Bug Importer (debzilla)]

Message-Id: <1088457609.7370.460.camel@thanatos>
Date: Mon, 28 Jun 2004 23:20:10 +0200
From: Thomas Hood <email address hidden>
To: <email address hidden>
Subject: Re: Bug#256680: ifupdown hangs pc either in boot or shutdown

severity 256680 important
severity 254705 important
severity 208700 important
merge 254705 256680 208700
thanks

On Mon, 2004-06-28 at 14:53, Helge Hafting wrote:
> Unfortunately, this means ifupdown brings down "lo" too at
> shutdown time, and that hangs shutdown because the
> command "ifdown -a" which is part of this package never
> ever completes. It hangs - forever.

Can you figure out why it hangs? At what stage, exactly, does it hang?

Does it help if you apply this patch to /etc/init.d/networking?

--- networking_ORIG 2004-06-28 23:18:57.000000000 +0200
+++ networking 2004-06-28 23:19:19.000000000 +0200
@@ -83,6 +83,7 @@
         else
             echo -n "Deconfiguring network interfaces..."
             ifdown -a
+ ifup lo
      echo "done."
         fi
  ;;

--
Thomas Hood <email address hidden>

[Helge Hafting (helge-hafting)]

Thomas Hood wrote:

>severity 256680 important
>severity 254705 important
>severity 208700 important
>merge 254705 256680 208700
>thanks
>
>On Mon, 2004-06-28 at 14:53, Helge Hafting wrote:
>
>
>>Unfortunately, this means ifupdown brings down "lo" too at
>>shutdown time, and that hangs shutdown because the
>>command "ifdown -a" which is part of this package never
>>ever completes. It hangs - forever.
>>
>>
>
>Can you figure out why it hangs? At what stage, exactly, does it hang?
>
>
>
>Does it help if you apply this patch to /etc/init.d/networking?
>
>--- networking_ORIG 2004-06-28 23:18:57.000000000 +0200
>+++ networking 2004-06-28 23:19:19.000000000 +0200
>@@ -83,6 +83,7 @@
> else
> echo -n "Deconfiguring network interfaces..."
> ifdown -a
>+ ifup lo
> echo "done."
> fi
> ;;
>
>
>
Thank you for the quick response. I don't think this will help,
it is not some later command missing the lo interface and hanging, it is
ifdown itself that stops. I figured that out with echo statements
and by running the shutdown scripts manually. And finally trying
ifdown under various circumstances.

It turns out that doing a "su" and running "ifdown -a" when the
machine runs normally is no problem. The interfaces go down
and ifdown exits. Bringing the machine partially down by "init 1"
first puts it in a state where "ifdown -a" will hang. "ifconfig lo down"
and "ifconfig eth0 down" works though, it doesn't look like
a kernel networking problem. Similiarly, an "ifup -a" will hang at
boot if "lo" isn't mentioned in /etc/network/interfaces.

I have attached two straces for ifdown.
strace.ifdown.ok shows what happens when ifdown works.
strace.ifdown.hang shows what happens when ifdown hangs - I
used ctrl+C to break out of it as it stopped. I captured both traces
like this:
 # strace ifdown -a 2> tracefile
The "ok" trace was captured running in an xterm. The "hanging"
trace was captured after init 1, with / mounted synchronously as a
safeguard in case I had to reset the machine. Ctrl+C worked though.

It seems to me that there is two problems here:
1. ifup/ifdown shouldn't hang like that
2. Independent of that, "ifdown -a" shouldn't bring down interfaces
specified with "iface <name> inet loopback", because loopback interfaces
are needed for a lot of things and nothing comes in from outside anyway.
This is what I believe everybody want.
(Those few who really want to close "lo" can spell it out using a static
address of 127.0.0.1 and use the "up" and "down" commands as needed.)

I hope this helps - I'll run more tests if necessary.

Helge Hafting

[Thomas Hood (jdthood-aglu)]

On Tue, 2004-06-29 at 09:56, Helge Hafting wrote:
> Thank you for the quick response. I don't think this will help,
> it is not some later command missing the lo interface and hanging, it is
> ifdown itself that stops.

OK

Here is another thing that might help. Just before the "ifdown -a"
in /etc/init.d/networking add the following:

    ifdown lo
    ifup lo

What this will do is make "lo=lo" the last line in the ifstate file
and this will cause "ifdown -a" to bring down lo last.
--
Thomas

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 29 Jun 2004 09:56:56 +0200
From: Helge Hafting <email address hidden>
To: Thomas Hood <email address hidden>, <email address hidden>
Subject: Re: Bug#256680: ifupdown hangs pc either in boot or shutdown

--------------000605040002080708060507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thomas Hood wrote:

>severity 256680 important
>severity 254705 important
>severity 208700 important
>merge 254705 256680 208700
>thanks
>
>On Mon, 2004-06-28 at 14:53, Helge Hafting wrote:
>
>
>>Unfortunately, this means ifupdown brings down "lo" too at
>>shutdown time, and that hangs shutdown because the
>>command "ifdown -a" which is part of this package never
>>ever completes. It hangs - forever.
>>
>>
>
>Can you figure out why it hangs? At what stage, exactly, does it hang?
>
>
>
>Does it help if you apply this patch to /etc/init.d/networking?
>
>--- networking_ORIG 2004-06-28 23:18:57.000000000 +0200
>+++ networking 2004-06-28 23:19:19.000000000 +0200
>@@ -83,6 +83,7 @@
> else
> echo -n "Deconfiguring network interfaces..."
> ifdown -a
>+ ifup lo
> echo "done."
> fi
> ;;
>
>
>
Thank you for the quick response. I don't think this will help,
it is not some later command missing the lo interface and hanging, it is
ifdown itself that stops. I figured that out with echo statements
and by running the shutdown scripts manually. And finally trying
ifdown under various circumstances.

It turns out that doing a "su" and running "ifdown -a" when the
machine runs normally is no problem. The interfaces go down
and ifdown exits. Bringing the machine partially down by "init 1"
first puts it in a state where "ifdown -a" will hang. "ifconfig lo down"
and "ifconfig eth0 down" works though, it doesn't look like
a kernel networking problem. Similiarly, an "ifup -a" will hang at
boot if "lo" isn't mentioned in /etc/network/interfaces.

I have attached two straces for ifdown.
strace.ifdown.ok shows what happens when ifdown works.
strace.ifdown.hang shows what happens when ifdown hangs - I
used ctrl+C to break out of it as it stopped. I captured both traces
like this:
 # strace ifdown -a 2> tracefile
The "ok" trace was captured running in an xterm. The "hanging"
trace was captured after init 1, with / mounted synchronously as a
safeguard in case I had to reset the machine. Ctrl+C worked though.

It seems to me that there is two problems here:
1. ifup/ifdown shouldn't hang like that
2. Independent of that, "ifdown -a" shouldn't bring down interfaces
specified with "iface <name> inet loopback", because loopback interfaces
are needed for a lot of things and nothing comes in from outside anyway.
This is what I believe everybody want.
(Those few who really want to close "lo" can spell it out using a static
address of 127.0.0.1 and use the "up" and "down" commands as needed.)

I hope this helps - I'll run more tests if necessary.

Helge Hafting

--------------000605040002080708060507
Content-Type: text/plain;
 name="strace.ifdown.ok"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filena...

[Debian Bug Importer (debzilla)]

Message-Id: <1088495900.7371.561.camel@thanatos>
Date: Tue, 29 Jun 2004 09:58:21 +0200
From: Thomas Hood <email address hidden>
To: Helge Hafting <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#256680: ifupdown hangs pc either in boot or shutdown

On Tue, 2004-06-29 at 09:56, Helge Hafting wrote:
> Thank you for the quick response. I don't think this will help,
> it is not some later command missing the lo interface and hanging, it is
> ifdown itself that stops.

OK

Here is another thing that might help. Just before the "ifdown -a"
in /etc/init.d/networking add the following:

    ifdown lo
    ifup lo

What this will do is make "lo=lo" the last line in the ifstate file
and this will cause "ifdown -a" to bring down lo last.
--
Thomas

[Matt Zimmerman (mdz)]

Could you send a copy of your ifupdown configuration? A tar of /etc/network
would be best, since that will have everything.

--
 - mdz

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 30 Jun 2004 12:03:33 -0700
From: Matt Zimmerman <email address hidden>
To: <email address hidden>
Subject: Configuration?

Could you send a copy of your ifupdown configuration? A tar of /etc/network
would be best, since that will have everything.

--
 - mdz

[Helge Hafting (helge-hafting)]

Matt Zimmerman wrote:

>Could you send a copy of your ifupdown configuration? A tar of /etc/network
>would be best, since that will have everything.
>
>
>
Of course, here it is.

Helge Hafting

[Thomas Hood (jdthood-aglu)]

Did the "ifdown lo ; ifup lo" trick work?
--
Thomas Hood <email address hidden>

[Thomas Hood (jdthood-aglu)]

Another thing to try is upgrading to the latest hotplug package
in unstable -- version 0.0.20040329-11 is the latest as I write
this. Versions 0.0.20040329-4 through 0.0.20040329-8 did things
to the ifstate file that really shouldn't be done and which
caused problems for some people.
--
Thomas

[Helge Hafting (helge-hafting)]

Thomas Hood wrote:

>Did the "ifdown lo ; ifup lo" trick work?
>
>
You mean the "ifdown -a ; ifup lo" trick?

It does not work. I was pretty sure of that, but I now
tested it because you asked again, and it did not help.

The problem is _not_ that "lo" is closed thereby confusing programs
that expect "lo" to work.

The problem is that "ifdown -a" waits forever. The command
never exits, so no further progress is made. Even the
next command in the script (which now is "echo after-ifdown")
never executes. ifdown waits on something that doesn't happen
at all during shutdown. That's why I sent those traces, one showing
normal operation when ifdown happen to work, and another that
show what happens when it hangs (and is killed with CTRL+C)

The hanging ifdown prevents shutdown, and modifying the configuration
to not mess with "lo" gives me a hang at boot time instead.

The only workaround that allows both shutdown and bootup is to
skip ifdown/ifup and bring the network up and down using
"ifconfig" or "ip" directly. But the purpose if ifup/ifdown is
to make things easier . . .

Helge Hafting

[Thomas Hood (jdthood-aglu)]

On Thu, 2004-07-01 at 11:35, Helge Hafting wrote:
> Thomas Hood wrote:
> >Did the "ifdown lo ; ifup lo" trick work?
> >
> You mean the "ifdown -a ; ifup lo" trick?
>
> It does not work. I was pretty sure of that, but I now
> tested it because you asked again, and it did not help.

No, I mean the trick wherein you do:

    ifdown lo
    ifup lo

just before you do

    ifdown -a

That is: after the change, /etc/init.d/networking contains the
following lines in the "stop" method:

    echo -n "Deconfiguring network interfaces..."
    ifdown lo
    ifup lo
    ifdown -a
    echo "done."

This was a second, different, suggestion from the first one I made.
If you didn't receive that message for some reason then please note
that you can review this whole conversation at
http://bugs.debian.org/256680. The message containing my second
suggestion had i.d. <1088495900.7371.561.camel@thanatos>.

There is a good chance that this second trick will work. If it
works then that provides us with a good reason to get off our
fannies and do something about the order in which "ifdown -a"
brings down interfaces.
--
Thomas

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 01 Jul 2004 10:37:25 +0200
From: Helge Hafting <email address hidden>
To: Matt Zimmerman <email address hidden>, <email address hidden>
Subject: Re: Bug#256680: Configuration?

--------------000804020205040607010606
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Matt Zimmerman wrote:

>Could you send a copy of your ifupdown configuration? A tar of /etc/network
>would be best, since that will have everything.
>
>
>
Of course, here it is.

Helge Hafting

--------------000804020205040607010606
Content-Type: application/octet-stream;
 name="network.tar.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="network.tar.bz2"

QlpoOTFBWSZTWW2RGbAAA7f/k+6wAEBIZ//SpvV0QP/v3qAEIEAAAAIACFADnutAyAAA0qaa
fqEaAyDIDQ0xGgZMhhGmgHMAmAmRgBGJiYTCYIaYmmAlExCp6mgaNBo09QBoaABk00ABzAJg
JkYARiYmEwmCGmJpgJIhNGiZGp6EZJsknkJ5RkbU9T01P0ajJHqcRI/Hfydzfdjvd9Yc6YY9
rkhg0JhNcIBEdnPuWtarPbYiChQFFkIhRhldRonrhNXiVxVRCiSOZIZAnASuSOL2eA5QuHI9
nDeNxKBqCTulzYbdc7ic6CFTIsCILkQoIgi4M4MUGiEgSwpBjqIEUaKZFYNUVptBWW9haSzJ
yisKGocJEfLquNBExKy8brjhe9xKUSBFy+A5nkZzhKcifKfkZCnQtNR8zlYtwNhWVG1lo++L
FbNlkdQxvPeMMXgGjQzZWNtDHBMkfoM4vhckAfjeDIzBASAPH7cDw8eEuEOP07Ej7JDIAfmR
9IJGZ4m2CHiLPGOMsTEJo/mk4yHFWyyAasX1KvDNC6kGoKwsqQsTYo9iyglKVQKQI8KlJE1U
YBSzOQiEIVEqA1KlUhnFqhYwkO4JIBZzh483DQEkPIVBXRsexFSTTRUJxS8Ku4JgOB64T+e7
d8fiVK/jxdB5xB5fCEEj9u1I9AzB5l3aMepYb4JHacYlBzSRCR+5ZnCB9T+Cru/wagUyC0/O
OBiMYl45zA3BJMYsWaNA5SR8gjMU8lrJUIluRqO5xy8cctPdF8pueg6saW2BXFKzxYMrDEPI
9LEbYiRYEwmMDIkOojiby1xFsiHJAfYTHGaBYlBj1BlrbeMV4BeE05uHNJtCcA3mIOE0RS86
jWSN3Tylh7hhxklv6eZzAfUZFRI23AYbXCl5oIUtCwwE5t54kg5wmfIpmP9YNZ/3tDrvL7gd
jNyGbnlJBmOnlGZZDuOMtaKlvmLYSfo5oxCYkTC4y6DYkDFchIzT6GbrFklfUEM+7UZXVLUk
MaaEEX8haSSkbiaQTHCfekdSQ9+BMcsxZZyhUtcVdE98BwyKWFSRoNZXISLQa2qhEYbGboCB
aTZUSYIJSK2GgOwXqJYE5TLpJBHlwywrZaTQaS/2SKOFt1g4NEVqQSC5qjbjpQL/xdyRThQk
G2RGbAA=
--------------000804020205040607010606--

[Helge Hafting (helge-hafting)]

Thomas Hood wrote:

>Another thing to try is upgrading to the latest hotplug package
>in unstable -- version 0.0.20040329-11 is the latest as I write
>this. Versions 0.0.20040329-4 through 0.0.20040329-8 did things
>to the ifstate file that really shouldn't be done and which
>caused problems for some people.
>--
>Thomas
>
>
I did that, it didn't change anything. "ifdown -a" still waits
forever during shutdown. Thanks for trying though!

Helge Hafting

[Javier Fernández-Sanguino (jfs)]

> I did that, it didn't change anything. "ifdown -a" still waits
> forever during shutdown. Thanks for trying though!

Could you please provide straces of the ifdown -a call using '-p' to trace
the children? Because the error strace ends with:

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x401632e8) = 20028
waitpid(20028, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 20028
--- SIGCHLD (Child exited) @ 0 (0) ---
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x401632e8) = 20033 waitpid(20033, <unfinished ...>

Which prevents us from reviewing what exactly happened to the chile and why
does it stall.... I know this is a major issue (you will need to reboot the
system) but it probably could help debug the issue better.

Regards

Javier

[Matt Zimmerman (mdz)]

On Thu, Jul 01, 2004 at 10:37:25AM +0200, Helge Hafting wrote:

> Matt Zimmerman wrote:
>
> >Could you send a copy of your ifupdown configuration? A tar of
> >/etc/network
> >would be best, since that will have everything.
> >
> >
> >
> Of course, here it is.

Strange; you're even using static addressing on the non-loopback interface.
I can't think of any reason that deconfiguring a statically-configured
interface should hang, regardless of the network status.

Change the "ifdown -a" line to:

strace -f -o /var/log/ifdown-strace.log ifdown -a

then reproduce the problem on shutdown, and send ifdown-strace.log
(gzipped)

--
 - mdz

[Debian Bug Importer (debzilla)]

Message-Id: <1088671594.8482.35.camel@thanatos>
Date: Thu, 01 Jul 2004 10:46:34 +0200
From: Thomas Hood <email address hidden>
To: <email address hidden>
Subject: Re: Bug#256680: Configuration?

Did the "ifdown lo ; ifup lo" trick work?
--
Thomas Hood <email address hidden>

[Debian Bug Importer (debzilla)]

Message-Id: <1088672237.8481.51.camel@thanatos>
Date: Thu, 01 Jul 2004 10:57:18 +0200
From: Thomas Hood <email address hidden>
To: <email address hidden>
Cc: Matt Zimmerman <email address hidden>
Subject: Re: Bug#256680: Configuration?

Another thing to try is upgrading to the latest hotplug package
in unstable -- version 0.0.20040329-11 is the latest as I write
this. Versions 0.0.20040329-4 through 0.0.20040329-8 did things
to the ifstate file that really shouldn't be done and which
caused problems for some people.
--
Thomas

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 01 Jul 2004 11:35:11 +0200
From: Helge Hafting <email address hidden>
To: Thomas Hood <email address hidden>, <email address hidden>
Subject: Re: Bug#256680: Configuration?

Thomas Hood wrote:

>Did the "ifdown lo ; ifup lo" trick work?
>
>
You mean the "ifdown -a ; ifup lo" trick?

It does not work. I was pretty sure of that, but I now
tested it because you asked again, and it did not help.

The problem is _not_ that "lo" is closed thereby confusing programs
that expect "lo" to work.

The problem is that "ifdown -a" waits forever. The command
never exits, so no further progress is made. Even the
next command in the script (which now is "echo after-ifdown")
never executes. ifdown waits on something that doesn't happen
at all during shutdown. That's why I sent those traces, one showing
normal operation when ifdown happen to work, and another that
show what happens when it hangs (and is killed with CTRL+C)

The hanging ifdown prevents shutdown, and modifying the configuration
to not mess with "lo" gives me a hang at boot time instead.

The only workaround that allows both shutdown and bootup is to
skip ifdown/ifup and bring the network up and down using
"ifconfig" or "ip" directly. But the purpose if ifup/ifdown is
to make things easier . . .

Helge Hafting

[Debian Bug Importer (debzilla)]

Message-Id: <1088674903.8481.99.camel@thanatos>
Date: Thu, 01 Jul 2004 11:41:44 +0200
From: Thomas Hood <email address hidden>
To: Helge Hafting <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#256680: Configuration?

On Thu, 2004-07-01 at 11:35, Helge Hafting wrote:
> Thomas Hood wrote:
> >Did the "ifdown lo ; ifup lo" trick work?
> >
> You mean the "ifdown -a ; ifup lo" trick?
>
> It does not work. I was pretty sure of that, but I now
> tested it because you asked again, and it did not help.

No, I mean the trick wherein you do:

    ifdown lo
    ifup lo

just before you do

    ifdown -a

That is: after the change, /etc/init.d/networking contains the
following lines in the "stop" method:

    echo -n "Deconfiguring network interfaces..."
    ifdown lo
    ifup lo
    ifdown -a
    echo "done."

This was a second, different, suggestion from the first one I made.
If you didn't receive that message for some reason then please note
that you can review this whole conversation at
http://bugs.debian.org/256680. The message containing my second
suggestion had i.d. <1088495900.7371.561.camel@thanatos>.

There is a good chance that this second trick will work. If it
works then that provides us with a good reason to get off our
fannies and do something about the order in which "ifdown -a"
brings down interfaces.
--
Thomas

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 01 Jul 2004 12:43:22 +0200
From: Helge Hafting <email address hidden>
To: Thomas Hood <email address hidden>, <email address hidden>
Subject: Re: Bug#256680: Configuration?

Thomas Hood wrote:

>Another thing to try is upgrading to the latest hotplug package
>in unstable -- version 0.0.20040329-11 is the latest as I write
>this. Versions 0.0.20040329-4 through 0.0.20040329-8 did things
>to the ifstate file that really shouldn't be done and which
>caused problems for some people.
>--
>Thomas
>
>
I did that, it didn't change anything. "ifdown -a" still waits
forever during shutdown. Thanks for trying though!

Helge Hafting

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 1 Jul 2004 14:53:07 +0200
From: Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?= <email address hidden>
To: Helge Hafting <email address hidden>, <email address hidden>
Cc: Thomas Hood <email address hidden>
Subject: Re: Bug#256680: Configuration?

--zYM0uCDKw75PZbzx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> I did that, it didn't change anything. "ifdown -a" still waits
> forever during shutdown. Thanks for trying though!

Could you please provide straces of the ifdown -a call using '-p' to trace=
=20
the children? Because the error strace ends with:

clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGC=
HLD,=20
child_tidptr=3D0x401632e8) =3D 20028
waitpid(20028, [{WIFEXITED(s) && WEXITSTATUS(s) =3D=3D 0}], 0) =3D 20028
--- SIGCHLD (Child exited) @ 0 (0) ---
clone(child_stack=3D0, flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGC=
HLD,=20
child_tidptr=3D0x401632e8) =3D 20033 waitpid(20033, <unfinished ...>

Which prevents us from reviewing what exactly happened to the chile and why=
=20
does it stall.... I know this is a major issue (you will need to reboot the=
=20
system) but it probably could help debug the issue better.

Regards

Javier

--zYM0uCDKw75PZbzx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA5Akyi4sehJTrj0oRAkYgAJ0SwUqd+el+oXzTm4XE9/N5RguX7QCg1Oex
sc+TEw6RDiO47Ru5sOLIwZ4=
=D5dm
-----END PGP SIGNATURE-----

--zYM0uCDKw75PZbzx--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 1 Jul 2004 10:05:29 -0700
From: Matt Zimmerman <email address hidden>
To: Helge Hafting <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#256680: Configuration?

On Thu, Jul 01, 2004 at 10:37:25AM +0200, Helge Hafting wrote:

> Matt Zimmerman wrote:
>
> >Could you send a copy of your ifupdown configuration? A tar of
> >/etc/network
> >would be best, since that will have everything.
> >
> >
> >
> Of course, here it is.

Strange; you're even using static addressing on the non-loopback interface.
I can't think of any reason that deconfiguring a statically-configured
interface should hang, regardless of the network status.

Change the "ifdown -a" line to:

strace -f -o /var/log/ifdown-strace.log ifdown -a

then reproduce the problem on shutdown, and send ifdown-strace.log
(gzipped)

--
 - mdz

[Thomas Hood (jdthood-yahoo)]

On Thu, 2004-07-01 at 11:35, Helge Hafting wrote:
> Thomas Hood wrote:
> >Did the "ifdown lo ; ifup lo" trick work?
> >
> You mean the "ifdown -a ; ifup lo" trick?
>
> It does not work. I was pretty sure of that, but I now
> tested it because you asked again, and it did not help.

No, I mean the trick wherein you do:

    ifdown lo
    ifup lo

just before you do

    ifdown -a

That is: after the change, /etc/init.d/networking contains the
following lines in the "stop" method:

    echo -n "Deconfiguring network interfaces..."
    ifdown lo
    ifup lo
    ifdown -a
    echo "done."

This was a second, different, suggestion from the first one I made.
If you didn't receive that message for some reason then please note
that you can review this whole conversation at
http://bugs.debian.org/256680. The message containing my second
suggestion had i.d. <1088495900.7371.561.camel@thanatos>.

There is a good chance that this second trick will work. If it
works then that provides us with a good reason to get off our
fannies and do something about the order in which "ifdown -a"
brings down interfaces.
--
Thomas

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 2 Jul 2004 14:36:26 +0200
From: <email address hidden> (Thomas Hood)
To: <email address hidden>
Subject: #256680

On Thu, 2004-07-01 at 11:35, Helge Hafting wrote:
> Thomas Hood wrote:
> >Did the "ifdown lo ; ifup lo" trick work?
> >
> You mean the "ifdown -a ; ifup lo" trick?
>
> It does not work. I was pretty sure of that, but I now
> tested it because you asked again, and it did not help.

No, I mean the trick wherein you do:

    ifdown lo
    ifup lo

just before you do

    ifdown -a

That is: after the change, /etc/init.d/networking contains the
following lines in the "stop" method:

    echo -n "Deconfiguring network interfaces..."
    ifdown lo
    ifup lo
    ifdown -a
    echo "done."

This was a second, different, suggestion from the first one I made.
If you didn't receive that message for some reason then please note
that you can review this whole conversation at
http://bugs.debian.org/256680. The message containing my second
suggestion had i.d. <1088495900.7371.561.camel@thanatos>.

There is a good chance that this second trick will work. If it
works then that provides us with a good reason to get off our
fannies and do something about the order in which "ifdown -a"
brings down interfaces.
--
Thomas

[Matt Zimmerman (mdz)]

Remove myself from all these CCs now that we have the warty-bugs mailing list

[Helge Hafting (helge-hafting)]

Thomas Hood wrote:

>On Thu, 2004-07-01 at 11:35, Helge Hafting wrote:
>
>
>>Thomas Hood wrote:
>>
>>
>>>Did the "ifdown lo ; ifup lo" trick work?
>>>
>>>
>>>
>>You mean the "ifdown -a ; ifup lo" trick?
>>
>>It does not work. I was pretty sure of that, but I now
>>tested it because you asked again, and it did not help.
>>
>>
>
>
>No, I mean the trick wherein you do:
>
> ifdown lo
> ifup lo
>
>just before you do
>
> ifdown -a
>
>That is: after the change, /etc/init.d/networking contains the
>following lines in the "stop" method:
>
> echo -n "Deconfiguring network interfaces..."
> ifdown lo
> ifup lo
> ifdown -a
> echo "done."
>
>
My misunderstanding then. I tried this, and put
"echo" statement between the others. I found that
the initial "ifdown lo" hangs, so the rest does not happen.

There is something strange going on that makes ifdown hang
during reboot, but not at other times. I will make another trace
that traces child processes too.

>This was a second, different, suggestion from the first one I made.
>If you didn't receive that message for some reason then please note
>that you can review this whole conversation at
>http://bugs.debian.org/256680. The message containing my second
>suggestion had i.d. <1088495900.7371.561.camel@thanatos>.
>
>
Thanks. I've had a little email problem, now fixed.

Helge Hafting

[Thomas Hood (jdthood-aglu)]

On Wed, 2004-07-07 at 12:09, Helge Hafting wrote:
> My misunderstanding then. I tried this, and put
> "echo" statement between the others. I found that
> the initial "ifdown lo" hangs, so the rest does not happen.

Please run ifdown with "-v" and send the output.
--
Thomas

[Helge Hafting (helge-hafting)]

Thomas Hood wrote:

>On Wed, 2004-07-07 at 12:09, Helge Hafting wrote:
>
>
>>My misunderstanding then. I tried this, and put
>>"echo" statement between the others. I found that
>>the initial "ifdown lo" hangs, so the rest does not happen.
>>
>>
>
>
>Please run ifdown with "-v" and send the output.
>--
>Thomas
>
>
# ifdown lo -v
Configuring interface lo=lo (inet)
run-parts /etc/network/if-down.d
ifconfig lo down
run-parts /etc/network/if-post-down.d

This was the no-hanging case when the system is up and running normally.
I did strace -f of ifdown -a and ifdown lo (-f to get traces of child
processes.)

This time it didn't get completely stuck, but merely hung for 45 seconds
before completing. I don't usually wait for 45 seconds, but I have
tried before.
When I tried a remote reboot I tried contacting the machine several hours
later without success, it still hung when I arrived at work the
following monday.

A compressed trace is attached. The following command was used:
strace -f ifdown lo 2> file
I don't know how interesting it is - it didn't hang this time. Still,
45 seconds is way too much for this job. The machine boots in
less time than that. :-(

I also noticed that a lot of other operations go slowly with "lo" down.
Both "ps aux" and "ls -l" tries to use a socket to 127.0.0.1, why "ls -l"
do that I have no idea.

I'll try ifdown -v the next time I shut the machine down.

[Helge Hafting (helge-hafting)]

Thomas Hood wrote:

>On Wed, 2004-07-07 at 12:09, Helge Hafting wrote:
>
>
>>My misunderstanding then. I tried this, and put
>>"echo" statement between the others. I found that
>>the initial "ifdown lo" hangs, so the rest does not happen.
>>
>>
>
>
>Please run ifdown with "-v" and send the output.
>--
>Thomas
>
>
Normal non-hanging run when the pc runs normally:
# ifdown lo -v
Configuring interface lo=lo (inet)
run-parts /etc/network/if-down.d
ifconfig lo down
run-parts /etc/network/if-post-down.d
#

A hanging run:
# ifdown lo -v
Configuring interface lo=lo (inet)
run-parts /etc/network/if-down.d
ifconfig lo down
run-parts /etc/network/if-post-down.d

I get the same output, but then it hangs. I broke it with ctrl+C
and issued the run-parts command manually. It completed
immediately, so there's something after that that hangs ifdown.

I'm doing a new run with strace -T -F -c to get timing information.

Helge Hafting

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 07 Jul 2004 12:09:46 +0200
From: Helge Hafting <email address hidden>
To: Thomas Hood <email address hidden>, <email address hidden>
Subject: Re: Bug#256680: #256680

Thomas Hood wrote:

>On Thu, 2004-07-01 at 11:35, Helge Hafting wrote:
>
>
>>Thomas Hood wrote:
>>
>>
>>>Did the "ifdown lo ; ifup lo" trick work?
>>>
>>>
>>>
>>You mean the "ifdown -a ; ifup lo" trick?
>>
>>It does not work. I was pretty sure of that, but I now
>>tested it because you asked again, and it did not help.
>>
>>
>
>
>No, I mean the trick wherein you do:
>
> ifdown lo
> ifup lo
>
>just before you do
>
> ifdown -a
>
>That is: after the change, /etc/init.d/networking contains the
>following lines in the "stop" method:
>
> echo -n "Deconfiguring network interfaces..."
> ifdown lo
> ifup lo
> ifdown -a
> echo "done."
>
>
My misunderstanding then. I tried this, and put
"echo" statement between the others. I found that
the initial "ifdown lo" hangs, so the rest does not happen.

There is something strange going on that makes ifdown hang
during reboot, but not at other times. I will make another trace
that traces child processes too.

>This was a second, different, suggestion from the first one I made.
>If you didn't receive that message for some reason then please note
>that you can review this whole conversation at
>http://bugs.debian.org/256680. The message containing my second
>suggestion had i.d. <1088495900.7371.561.camel@thanatos>.
>
>
Thanks. I've had a little email problem, now fixed.

Helge Hafting

[Debian Bug Importer (debzilla)]

Message-Id: <1089195841.24831.393.camel@localhost>
Date: Wed, 07 Jul 2004 12:24:01 +0200
From: Thomas Hood <email address hidden>
To: Helge Hafting <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#256680: #256680

On Wed, 2004-07-07 at 12:09, Helge Hafting wrote:
> My misunderstanding then. I tried this, and put
> "echo" statement between the others. I found that
> the initial "ifdown lo" hangs, so the rest does not happen.

Please run ifdown with "-v" and send the output.
--
Thomas

[Javier Fernández-Sanguino (jfs)]

On Wed, Jul 07, 2004 at 01:47:18PM +0200, Helge Hafting wrote:
> # ifdown lo -v
> Configuring interface lo=lo (inet)
> run-parts /etc/network/if-down.d
> ifconfig lo down
> run-parts /etc/network/if-post-down.d
>
> I get the same output, but then it hangs. I broke it with ctrl+C
> and issued the run-parts command manually. It completed
> immediately, so there's something after that that hangs ifdown.

What do your /etc/network/if-down.d and /etc/network/if-post-down.d
directories contain? Actually, it looks like your system tries to do LDAP
stuff while downing lo, which does not make sense to me, there's stuff like
this in your trace:

[pid 3697] connect(3, {sa_family=AF_INET, sin_port=htons(389),
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 3697] select(1024, NULL, [3], NULL, {30, 0}) = 1 (out [3], left {30,
0})
[pid 3697] getpeername(3, 0xbfffee18, [128]) = -1 ENOTCONN (Transport
endpointis not connected)
[pid 3697] read(3, 0xbfffee13, 1) = -1 ECONNREFUSED (Connection
refused)
[pid 3697] shutdown(3, 2 /* send and receive */) = -1 ENOTCONN (Transport
endpoint is not connected)

Which might be generating those timeouts or deadlocks you observer. I think
this is a configuration issue on your side (or on another package). Maybe
providing more information on your environment and on the scripts that are
getting run by run-parts would help in locating the problem.

Regards

Javier

[Helge Hafting (helge-hafting)]

Thomas Hood wrote:

>On Wed, 2004-07-07 at 12:09, Helge Hafting wrote:
>
>
>>My misunderstanding then. I tried this, and put
>>"echo" statement between the others. I found that
>>the initial "ifdown lo" hangs, so the rest does not happen.
>>
>>
>
>
>Please run ifdown with "-v" and send the output.
>--
>Thomas
>
>
 Timing for a bad strace ifdown lo:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
 67.44 0.017983 8992 2 waitpid
  5.00 0.001333 9 147 21 open
  4.29 0.001143 229 5 execve
  3.66 0.000976 8 118 read
  3.53 0.000942 5 174 old_mmap
  2.56 0.000683 3 208 brk
  1.80 0.000481 4 135 close
  1.64 0.000437 6 75 72 access
  1.53 0.000409 3 120 fstat64
  1.49 0.000397 7 54 munmap
  1.28 0.000341 7 51 33 stat64
  1.08 0.000288 26 11 11 connect
  0.90 0.000240 17 14 socket
  0.65 0.000173 58 3 clone
  0.62 0.000166 5 36 mmap2
  0.42 0.000111 3 33 rt_sigaction
  0.38 0.000100 4 28 fcntl64
  0.32 0.000084 4 20 rt_sigprocmask
  0.22 0.000058 4 13 uname
  0.17 0.000046 6 8 getdents64
  0.14 0.000036 4 9 getpid
  0.10 0.000026 5 5 time
  0.10 0.000026 5 5 _llseek
  0.09 0.000025 13 2 ioctl
  0.08 0.000021 4 6 set_thread_area
  0.08 0.000021 11 2 shutdown
  0.06 0.000017 3 6 geteuid32
  0.06 0.000017 6 3 setsockopt
  0.06 0.000015 5 3 gettimeofday
  0.06 0.000015 5 3 getcwd
  0.04 0.000010 3 3 getrlimit
  0.03 0.000009 3 3 getuid32
  0.03 0.000008 3 3 getppid
  0.03 0.000008 3 3 getgid32
  0.03 0.000008 3 3 getegid32
  0.02 0.000006 3 2 getpgrp
  0.02 0.000004 2 2 select
  0.01 0.000003 3 1 umask
------ ----------- ----------- --------- --------- ----------------
100.00 0.026666 1319 137 total

lots of time spent in waitpid?

Also attached a strace -T -f (not the same run)
with a slow-running "ifdown lo"
It eventually completed, but running "ifdown lo" in an xterm
(not runlevel 1) is much faster, it completes in less than a second.

Taking the machine down to runlevel 1 means ifdown
will be slow, using half a minute to comp...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 07 Jul 2004 13:15:13 +0200
From: Helge Hafting <email address hidden>
To: Thomas Hood <email address hidden>
CC: <email address hidden>
Subject: Re: Bug#256680: #256680

--------------070006090605030504010108
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thomas Hood wrote:

>On Wed, 2004-07-07 at 12:09, Helge Hafting wrote:
>
>
>>My misunderstanding then. I tried this, and put
>>"echo" statement between the others. I found that
>>the initial "ifdown lo" hangs, so the rest does not happen.
>>
>>
>
>
>Please run ifdown with "-v" and send the output.
>--
>Thomas
>
>
# ifdown lo -v
Configuring interface lo=lo (inet)
run-parts /etc/network/if-down.d
ifconfig lo down
run-parts /etc/network/if-post-down.d

This was the no-hanging case when the system is up and running normally.
I did strace -f of ifdown -a and ifdown lo (-f to get traces of child
processes.)

This time it didn't get completely stuck, but merely hung for 45 seconds
before completing. I don't usually wait for 45 seconds, but I have
tried before.
When I tried a remote reboot I tried contacting the machine several hours
later without success, it still hung when I arrived at work the
following monday.

A compressed trace is attached. The following command was used:
strace -f ifdown lo 2> file
I don't know how interesting it is - it didn't hang this time. Still,
45 seconds is way too much for this job. The machine boots in
less time than that. :-(

I also noticed that a lot of other operations go slowly with "lo" down.
Both "ps aux" and "ls -l" tries to use a socket to 127.0.0.1, why "ls -l"
do that I have no idea.

I'll try ifdown -v the next time I shut the machine down.

--------------070006090605030504010108
Content-Type: application/octet-stream;
 name="strace.ifdownlo.slow.bz2"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="strace.ifdownlo.slow.bz2"

QlpoOTFBWSZTWagR48oAkGN/gHv/+4V/9//3/+///r/v3/5gKh97pVKF9y6JsUvDuB0s2ea3
YudO2B1nvcO8AUt7wDF2p4Dd7x1yN2Oum7YRTswoeADvXUUqUpVKVV7HwAAA9jzbV6bRms6+
5o93OVpqgESQKooAU+G1J6oIT9U1PymhiRkZDTTQGgGgDQAAAAA0DQBhCAhSm9VNqenqnpoh
kABiaaAAAAAAAAyPU0EpP9VVSA0yMI0YmRgTIDIwI0yDQxNMmhkMmmgGQMEnqpJNTRlU9IwT
NEekYjGiNNDBGCGgMgwmno0mJkGhgTVJEAQTIFMNQxCIZD0nkJmpp6QNGgDTQ0NPKabU2o9T
QKUoImgJgpp6TJkTJoGp5CG0jBDRoyAGjEekDQAPiivKoy/OGlJ+a+X6/2NbahfatLfffiN/
Ct/E1fIBGeXNxrcayVjQa9RQgPWVeqwNI0UZWULhD2EwikKZOhCIaLjiWUbudeSvFd16XS2t
5KsbV2Em/kV262uNS9DhPOL08ri9W0EBKoXYBEIS2KRYCRCJwgAA6szCK26auAjO3NxrcayV
jQa7ukbK2WBlGijK4QuFwgwilTB2IRDSQa4llG7nVea8F6XTdK1vJVjauCTepu3W1xqXdwnl
F48ri9O1K7KhwwCIQls1DAgpEInKJJugcIgSkkjO3NxrcayVjQa8Fu7x9XK9TejN2ea9EvNy
YvDm3ldNcFxxLKN3OvJXoV6XFtbyVY2rxElXXNrjUu7hPKLx5XF6dqa8Lz5Wu67c5eAsBIhE
4RBS5K9UIDuQF0NJiWSLhXeMzxyvMgTgi/EyUjslEtotPsqD47S4X3J+SEfktfxHmvB+e/VD
81nPfeSjqqHCuy0Im9ic1o6zhKg+/Z/U/IuRRbWeLCtMJkSZMqoW1TSNlZZv+dy2uK3bNXM1
JjEqskqxiZOc9Wlq0pRpatSkaWrQqNpsVkrJhVMm7KqtUqz5GNJNmKsYDTKzNXx97ira3cJq
KLGk1VAmoo22oE1FFi21sZmYQNjLsSjquCIOVkqr3LBfvsh+iyld3804MRXq+v6/r5HCUmMC
rj8WqdK3OXLl6qlf08a9y4vjdFd2SfmVK7NVRdGz4trpXRxf0PV87aPz8pU0V4n+tqSn+lgo
8IRvH0Le2EbHm2vvtNn8TgDo2jT7jKam...

[Helge Hafting (helge-hafting)]

Javier Fernández-Sanguino Peña wrote:

>On Wed, Jul 07, 2004 at 01:47:18PM +0200, Helge Hafting wrote:
>
>
>># ifdown lo -v
>>Configuring interface lo=lo (inet)
>>run-parts /etc/network/if-down.d
>>ifconfig lo down
>>run-parts /etc/network/if-post-down.d
>>
>>I get the same output, but then it hangs. I broke it with ctrl+C
>>and issued the run-parts command manually. It completed
>>immediately, so there's something after that that hangs ifdown.
>>
>>
>
>What do your /etc/network/if-down.d and /etc/network/if-post-down.d
>directories contain?
>

Nothing! They are empty, except for "." and ".."

>Actually, it looks like your system tries to do LDAP
>stuff while downing lo, which does not make sense to me, there's stuff like
>this in your trace:
>
>
I use openldap for user authentication. (Experimental, there's
just a test user in the ldap database) This means that anything
that uses PAM might need to contact ldap.
It turns out that run-parts indeed tries to contact the ldap server
via 127.0.0.1, and of course that times out when "lo" is down.

>[pid 3697] connect(3, {sa_family=AF_INET, sin_port=htons(389),
>sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
>[pid 3697] select(1024, NULL, [3], NULL, {30, 0}) = 1 (out [3], left {30,
>0})
>[pid 3697] getpeername(3, 0xbfffee18, [128]) = -1 ENOTCONN (Transport
>endpointis not connected)
>[pid 3697] read(3, 0xbfffee13, 1) = -1 ECONNREFUSED (Connection
>refused)
>[pid 3697] shutdown(3, 2 /* send and receive */) = -1 ENOTCONN (Transport
>endpoint is not connected)
>
>Which might be generating those timeouts or deadlocks you observer. I think
>this is a configuration issue on your side (or on another package). Maybe
>providing more information on your environment and on the scripts that are
>getting run by run-parts would help in locating the problem.
>
>
There are no scripts run by run-parts - it invokes ldap even
when there is nothing at all to do. I can provide a guest
account for those interested in looking at the configuration.
There is nothing to see in /etc/network/if-down.d (or if-post-down.d)
though.

There are many possibilities for a bug here:
* should run-parts really invoke ldap? Isn't it supposed to work
   before ldap is up or after it is down?
* or is run-parts the wrong tool for "ifdown"?
* or am I not supposed to use ldap? It is advertised as a user database...

Keeping ldap running for a longer time (stopping it after the network)
won't help because the network script uses run-parts _after_ killing
the interfaces.

So in my opinion - either run-parts have a bug (should avoid PAM),
or ifdown is buggy for using run-parts. Pick one . . .

Helge Hafting

[Thomas Hood (jdthood-aglu)]

I found a duplicate of this bug: #158065. It says there:

> Digging around I managed to get rid of it by changing the order in
> nsswitch.conf to "passwd: files ldap" (same for shadow).

Maybe this will help in your case?

In my opinion, ifupdown -a should refrain from bringing down lo.
I can't think of any reason why lo should be deconfigured.

--
Thomas

[Helge Hafting (helge-hafting)]

Thomas Hood wrote:

>I found a duplicate of this bug: #158065. It says there:
>
>
>
>>Digging around I managed to get rid of it by changing the order in
>>nsswitch.conf to "passwd: files ldap" (same for shadow).
>>
>>
>
>Maybe this will help in your case?
>
>

It helps in my case, thanks!
Nothing needs to be looked
up in ldap because I have most info in the traditional files.
I don't think this solves the problem for anyone who actually
relies on ldap though. In extreme cases even root could be
authenticated through ldap exclusively.

I still wonder wether run-parts really needs to invoke PAM.
What purpose does it serve - particularly when there
isn't a single script to run?

>In my opinion, ifupdown -a should refrain from bringing down lo.
>I can't think of any reason why lo should be deconfigured.
>
>
I agree. I believe people who need to shutdown a loopback
interface are few - and they _can_ put a "ifconfig lo down" in
a post-down.d script if they really need that sort of thing.

Helge Hafting

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 07 Jul 2004 13:47:18 +0200
From: Helge Hafting <email address hidden>
To: Thomas Hood <email address hidden>
CC: <email address hidden>
Subject: Re: Bug#256680: #256680

Thomas Hood wrote:

>On Wed, 2004-07-07 at 12:09, Helge Hafting wrote:
>
>
>>My misunderstanding then. I tried this, and put
>>"echo" statement between the others. I found that
>>the initial "ifdown lo" hangs, so the rest does not happen.
>>
>>
>
>
>Please run ifdown with "-v" and send the output.
>--
>Thomas
>
>
Normal non-hanging run when the pc runs normally:
# ifdown lo -v
Configuring interface lo=lo (inet)
run-parts /etc/network/if-down.d
ifconfig lo down
run-parts /etc/network/if-post-down.d
#

A hanging run:
# ifdown lo -v
Configuring interface lo=lo (inet)
run-parts /etc/network/if-down.d
ifconfig lo down
run-parts /etc/network/if-post-down.d

I get the same output, but then it hangs. I broke it with ctrl+C
and issued the run-parts command manually. It completed
immediately, so there's something after that that hangs ifdown.

I'm doing a new run with strace -T -F -c to get timing information.

Helge Hafting

[Thomas Hood (jdthood-aglu)]

severity 256680 normal
thanks

I am glad that there is a workaround, at least.
--
Thomas

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 7 Jul 2004 14:20:54 +0200
From: Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?= <email address hidden>
To: Helge Hafting <email address hidden>, <email address hidden>
Cc: Thomas Hood <email address hidden>
Subject: Re: Bug#256680: #256680

--0ntfKIWw70PvrIHh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 07, 2004 at 01:47:18PM +0200, Helge Hafting wrote:
> # ifdown lo -v
> Configuring interface lo=3Dlo (inet)
> run-parts /etc/network/if-down.d
> ifconfig lo down
> run-parts /etc/network/if-post-down.d
>=20
> I get the same output, but then it hangs. I broke it with ctrl+C
> and issued the run-parts command manually. It completed
> immediately, so there's something after that that hangs ifdown.

What do your /etc/network/if-down.d and /etc/network/if-post-down.d=20
directories contain? Actually, it looks like your system tries to do LDAP=
=20
stuff while downing lo, which does not make sense to me, there's stuff like=
=20
this in your trace:

[pid 3697] connect(3, {sa_family=3DAF_INET, sin_port=3Dhtons(389),=20
sin_addr=3Dinet_addr("127.0.0.1")}, 16) =3D -1 EINPROGRESS (Operation now i=
n progress)
[pid 3697] select(1024, NULL, [3], NULL, {30, 0}) =3D 1 (out [3], left {30=
,=20
0})
[pid 3697] getpeername(3, 0xbfffee18, [128]) =3D -1 ENOTCONN (Transport=20
endpointis not connected)
[pid 3697] read(3, 0xbfffee13, 1) =3D -1 ECONNREFUSED (Connection=20
refused)
[pid 3697] shutdown(3, 2 /* send and receive */) =3D -1 ENOTCONN (Transpor=
t=20
endpoint is not connected)

Which might be generating those timeouts or deadlocks you observer. I think=
=20
this is a configuration issue on your side (or on another package). Maybe=
=20
providing more information on your environment and on the scripts that are=
=20
getting run by run-parts would help in locating the problem.

Regards

Javier

--0ntfKIWw70PvrIHh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA6+qli4sehJTrj0oRAuP4AKCO7v+9AfkVVqMxkV5kZ8MAb2RmggCg1XfK
/eY5/iJtWpYIV3vUgCwaO2Y=
=sndC
-----END PGP SIGNATURE-----

--0ntfKIWw70PvrIHh--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 07 Jul 2004 14:25:55 +0200
From: Helge Hafting <email address hidden>
To: Thomas Hood <email address hidden>
CC: <email address hidden>
Subject: Re: Bug#256680: #256680

--------------060805030301050708020704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thomas Hood wrote:

>On Wed, 2004-07-07 at 12:09, Helge Hafting wrote:
>
>
>>My misunderstanding then. I tried this, and put
>>"echo" statement between the others. I found that
>>the initial "ifdown lo" hangs, so the rest does not happen.
>>
>>
>
>
>Please run ifdown with "-v" and send the output.
>--
>Thomas
>
>
 Timing for a bad strace ifdown lo:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
 67.44 0.017983 8992 2 waitpid
  5.00 0.001333 9 147 21 open
  4.29 0.001143 229 5 execve
  3.66 0.000976 8 118 read
  3.53 0.000942 5 174 old_mmap
  2.56 0.000683 3 208 brk
  1.80 0.000481 4 135 close
  1.64 0.000437 6 75 72 access
  1.53 0.000409 3 120 fstat64
  1.49 0.000397 7 54 munmap
  1.28 0.000341 7 51 33 stat64
  1.08 0.000288 26 11 11 connect
  0.90 0.000240 17 14 socket
  0.65 0.000173 58 3 clone
  0.62 0.000166 5 36 mmap2
  0.42 0.000111 3 33 rt_sigaction
  0.38 0.000100 4 28 fcntl64
  0.32 0.000084 4 20 rt_sigprocmask
  0.22 0.000058 4 13 uname
  0.17 0.000046 6 8 getdents64
  0.14 0.000036 4 9 getpid
  0.10 0.000026 5 5 time
  0.10 0.000026 5 5 _llseek
  0.09 0.000025 13 2 ioctl
  0.08 0.000021 4 6 set_thread_area
  0.08 0.000021 11 2 shutdown
  0.06 0.000017 3 6 geteuid32
  0.06 0.000017 6 3 setsockopt
  0.06 0.000015 5 3 gettimeofday
  0.06 0.000015 5 3 getcwd
  0.04 0.000010 3 3 getrlimit
  0.03 0.000009 3 3 getuid32
  0.03 0.000008 3 3 getppid
  0.03 0.000008 3 3 getgid32
  0.03 0.000008 3 3 getegid32
  0.02 0.000006 3 2 getpgrp
  0.02 0.000004 2 2 select
  0.01 0.000003 3 1 umask
------ ----------- ----------- --------- --------- ----------------
100.00 0.026666 ...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 07 Jul 2004 14:40:28 +0200
From: Helge Hafting <email address hidden>
To: =?ISO-8859-1?Q?Javier_Fern=E1ndez-Sanguino_Pe=F1a?=
 <email address hidden>
CC: <email address hidden>, Thomas Hood <email address hidden>
Subject: Re: Bug#256680: #256680

Javier Fern�ez-Sanguino Pe�rote:

>On Wed, Jul 07, 2004 at 01:47:18PM +0200, Helge Hafting wrote:
>
>
>># ifdown lo -v
>>Configuring interface lo=lo (inet)
>>run-parts /etc/network/if-down.d
>>ifconfig lo down
>>run-parts /etc/network/if-post-down.d
>>
>>I get the same output, but then it hangs. I broke it with ctrl+C
>>and issued the run-parts command manually. It completed
>>immediately, so there's something after that that hangs ifdown.
>>
>>
>
>What do your /etc/network/if-down.d and /etc/network/if-post-down.d
>directories contain?
>

Nothing! They are empty, except for "." and ".."

>Actually, it looks like your system tries to do LDAP
>stuff while downing lo, which does not make sense to me, there's stuff like
>this in your trace:
>
>
I use openldap for user authentication. (Experimental, there's
just a test user in the ldap database) This means that anything
that uses PAM might need to contact ldap.
It turns out that run-parts indeed tries to contact the ldap server
via 127.0.0.1, and of course that times out when "lo" is down.

>[pid 3697] connect(3, {sa_family=AF_INET, sin_port=htons(389),
>sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
>[pid 3697] select(1024, NULL, [3], NULL, {30, 0}) = 1 (out [3], left {30,
>0})
>[pid 3697] getpeername(3, 0xbfffee18, [128]) = -1 ENOTCONN (Transport
>endpointis not connected)
>[pid 3697] read(3, 0xbfffee13, 1) = -1 ECONNREFUSED (Connection
>refused)
>[pid 3697] shutdown(3, 2 /* send and receive */) = -1 ENOTCONN (Transport
>endpoint is not connected)
>
>Which might be generating those timeouts or deadlocks you observer. I think
>this is a configuration issue on your side (or on another package). Maybe
>providing more information on your environment and on the scripts that are
>getting run by run-parts would help in locating the problem.
>
>
There are no scripts run by run-parts - it invokes ldap even
when there is nothing at all to do. I can provide a guest
account for those interested in looking at the configuration.
There is nothing to see in /etc/network/if-down.d (or if-post-down.d)
though.

There are many possibilities for a bug here:
* should run-parts really invoke ldap? Isn't it supposed to work
   before ldap is up or after it is down?
* or is run-parts the wrong tool for "ifdown"?
* or am I not supposed to use ldap? It is advertised as a user database...

Keeping ldap running for a longer time (stopping it after the network)
won't help because the network script uses run-parts _after_ killing
the interfaces.

So in my opinion - either run-parts have a bug (should avoid PAM),
or ifdown is buggy for using run-parts. Pick one . . .

Helge Hafting

[Debian Bug Importer (debzilla)]

Message-Id: <1089204361.24841.416.camel@localhost>
Date: Wed, 07 Jul 2004 14:46:02 +0200
From: Thomas Hood <email address hidden>
To: Helge Hafting <email address hidden>
Cc: Javier =?ISO-8859-1?Q?Fern=E1ndez-Sanguino_?= =?ISO-8859-1?Q?Pe=F1a?= <email address hidden>,
 <email address hidden>
Subject: Re: Bug#256680: #256680

I found a duplicate of this bug: #158065. It says there:

> Digging around I managed to get rid of it by changing the order in
> nsswitch.conf to "passwd: files ldap" (same for shadow).

Maybe this will help in your case?

In my opinion, ifupdown -a should refrain from bringing down lo.
I can't think of any reason why lo should be deconfigured.

--
Thomas

[Debian Bug Importer (debzilla)]

Message-Id: <1089206112.24841.451.camel@localhost>
Date: Wed, 07 Jul 2004 15:15:12 +0200
From: Thomas Hood <email address hidden>
To: Helge Hafting <email address hidden>
Cc: Javier =?ISO-8859-1?Q?Fern=E1ndez-Sanguino_?= =?ISO-8859-1?Q?Pe=F1a?= <email address hidden>,
 <email address hidden>
Subject: Re: Bug#256680: #256680

severity 256680 normal
thanks

I am glad that there is a workaround, at least.
--
Thomas

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 07 Jul 2004 15:04:02 +0200
From: Helge Hafting <email address hidden>
To: Thomas Hood <email address hidden>
CC: =?ISO-8859-1?Q?Javier_Fern=E1ndez-Sanguino_Pe=F1a?=
 <email address hidden>, <email address hidden>
Subject: Re: Bug#256680: #256680

Thomas Hood wrote:

>I found a duplicate of this bug: #158065. It says there:
>
>
>
>>Digging around I managed to get rid of it by changing the order in
>>nsswitch.conf to "passwd: files ldap" (same for shadow).
>>
>>
>
>Maybe this will help in your case?
>
>

It helps in my case, thanks!
Nothing needs to be looked
up in ldap because I have most info in the traditional files.
I don't think this solves the problem for anyone who actually
relies on ldap though. In extreme cases even root could be
authenticated through ldap exclusively.

I still wonder wether run-parts really needs to invoke PAM.
What purpose does it serve - particularly when there
isn't a single script to run?

>In my opinion, ifupdown -a should refrain from bringing down lo.
>I can't think of any reason why lo should be deconfigured.
>
>
I agree. I believe people who need to shutdown a loopback
interface are few - and they _can_ put a "ifconfig lo down" in
a post-down.d script if they really need that sort of thing.

Helge Hafting

[Matt Zimmerman (mdz)]

This bug is downgraded in Debian, so marking NOTWARTY to shut it up

[Javier Fernández-Sanguino (jfs)]

unmerge 208700
clone 208700 -1
reassign -1 netbase
retitle -1 Introduce workarounds in networking to avoid ifupdown's bugs
tags -1 patch
merge 208700 256680 254705
thanks

There are two possible workarounds to avoid #208700 and other bugs
(#256680, #254705) that could be introduced in netbase's networking init
script:

#1 Make 'lo' be the last interface to be unconfigured when calling ifdown:
Rationale: some bug reports are fixed by this, interfaces' dependancies
might require that lo is unconfigured at the end, doing 'ifup lo; ifdown
lo' guarantees that 'lo' is the last interface in the ifstate file.
-------------------------------------------------------------------
--- networking.orig 2004-07-30 02:45:39.000000000 +0200
+++ networking 2004-07-30 02:45:56.000000000 +0200
@@ -82,6 +82,8 @@
             echo "NOT deconfiguring network interfaces: network shares
still mounted."
         else
             echo -n "Deconfiguring network interfaces..."
+ ifup lo
+ ifdown lo
             ifdown -a
            echo "done."
         fi
-------------------------------------------------------------------

#2 Don't let ifdown remove 'lo'
Rationale: some stuff might need to have 'lo' available before shutting
down, if it isn't there the system might not go down at all (needs a hard
reset). This happens with systems configured using LDAP and NIS.
-------------------------------------------------------------------
--- networking.orig 2004-07-30 02:45:39.000000000 +0200
+++ networking 2004-07-30 02:47:37.000000000 +0200
@@ -83,6 +83,7 @@
         else
             echo -n "Deconfiguring network interfaces..."
             ifdown -a
+ ifup lo
            echo "done."
         fi
        ;;
-------------------------------------------------------------------

Maybe even both workarounds should be applied in order to avoid these bugs
until 'ifupdown' is modified in order to avoid downing lo so that the
'ifdown -a' call in networking could be substituted with something like
'ifdown --except lo -a'.

If this was to be introduced before the base freeze it would greatly help
users avoid this bugs. Ifupdown will probably not have this bug fixed on
its own before the freeze.

Regards

Javier

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 30 Jul 2004 03:12:06 +0200
From: Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?= <email address hidden>
To: <email address hidden>
Subject: Maybe the workarounds should be introduced in /etc/init.d/networking as long as ifupdown is
 not fixed

unmerge 208700
clone 208700 -1
reassign -1 netbase
retitle -1 Introduce workarounds in networking to avoid ifupdown's bugs
tags -1 patch
merge 208700 256680 254705
thanks

There are two possible workarounds to avoid #208700 and other bugs
(#256680, #254705) that could be introduced in netbase's networking init
script:

#1 Make 'lo' be the last interface to be unconfigured when calling ifdown:
Rationale: some bug reports are fixed by this, interfaces' dependancies
might require that lo is unconfigured at the end, doing 'ifup lo; ifdown
lo' guarantees that 'lo' is the last interface in the ifstate file.
-------------------------------------------------------------------
--- networking.orig 2004-07-30 02:45:39.000000000 +0200
+++ networking 2004-07-30 02:45:56.000000000 +0200
@@ -82,6 +82,8 @@
             echo "NOT deconfiguring network interfaces: network shares
still mounted."
         else
             echo -n "Deconfiguring network interfaces..."
+ ifup lo
+ ifdown lo
             ifdown -a
            echo "done."
         fi
-------------------------------------------------------------------

#2 Don't let ifdown remove 'lo'
Rationale: some stuff might need to have 'lo' available before shutting
down, if it isn't there the system might not go down at all (needs a hard
reset). This happens with systems configured using LDAP and NIS.
-------------------------------------------------------------------
--- networking.orig 2004-07-30 02:45:39.000000000 +0200
+++ networking 2004-07-30 02:47:37.000000000 +0200
@@ -83,6 +83,7 @@
         else
             echo -n "Deconfiguring network interfaces..."
             ifdown -a
+ ifup lo
            echo "done."
         fi
        ;;
-------------------------------------------------------------------

Maybe even both workarounds should be applied in order to avoid these bugs
until 'ifupdown' is modified in order to avoid downing lo so that the
'ifdown -a' call in networking could be substituted with something like
'ifdown --except lo -a'.

If this was to be introduced before the base freeze it would greatly help
users avoid this bugs. Ifupdown will probably not have this bug fixed on
its own before the freeze.

Regards

Javier

[Thomas Hood (jdthood-aglu)]

tags 254705 fixed
thanks

This is fixed in both the (currently) unstable and experimental
versions of ifupdown by means of the --exclude option, recently
implemented by Javier Fernandez-Sanguino Pena. To eliminate hangups
on shutdown, replace

    ifdown -a

in /etc/init.d/networking (in the "stop" method) with

    ifdown --exclude=lo -a

Once this feature makes it into testing we can ask that this change
be made to the default /etc/init.d/networking in the netbase package.
--
Thomas Hood

[Debian Bug Importer (debzilla)]

Message-Id: <1094389105.11462.595.camel@thanatos>
Date: Sun, 05 Sep 2004 14:58:25 +0200
From: Thomas Hood <email address hidden>
Cc: Vincent Lefevre <email address hidden>, Chip Salzenberg <email address hidden>,
 Helge Hafting <email address hidden>
Subject: #254705, #208700, #256680 fixed

tags 254705 fixed
thanks

This is fixed in both the (currently) unstable and experimental
versions of ifupdown by means of the --exclude option, recently
implemented by Javier Fernandez-Sanguino Pena. To eliminate hangups
on shutdown, replace

    ifdown -a

in /etc/init.d/networking (in the "stop" method) with

    ifdown --exclude=lo -a

Once this feature makes it into testing we can ask that this change
be made to the default /etc/init.d/networking in the netbase package.
--
Thomas Hood

[Thomas Hood (jdthood-aglu)]

severity 273543 normal
tags 273543 fixed
merge 273543 208700
tags 273543 fixed-in-experimental
thanks

On Sun, 2004-09-26 at 22:44, Dj-Death wrote:
> When halting/rebooting my box, the /etc/init.d/networking script
> stops just after he printed "Deconfiguring network interfaces".

This may be occurring because /etc/init.d/networking is trying to
deconfigure the loopback interface. You may be able to cure this
problem with the help of the "--exclude" option which was added to
ifupdown in 0.6.4-4.9.

Edit /etc/init.d/networking and change the "ifdown -a" line to
"ifdown --exclude=lo -a".

Please let me know whether this fixes the problem.
--
Thomas

[Javier Fernández-Sanguino (jfs)]

tags 273543 - fixed
tags 273543 - fixed-in-experimental
thanks

> This may be occurring because /etc/init.d/networking is trying to
> deconfigure the loopback interface. You may be able to cure this
> problem with the help of the "--exclude" option which was added to
> ifupdown in 0.6.4-4.9.

Thomas, why do you merge this bug if you have not received confirmation of
it being fixed with the workaround above?

>
> Edit /etc/init.d/networking and change the "ifdown -a" line to
> "ifdown --exclude=lo -a".
>
> Please let me know whether this fixes the problem.

You should wait for the submitter's answer before merging, and, actually,
these bugs should now be reassigned to netbase since the workaround should
be added there (along with a dependency on newer ifupdown version). In any
case, I'm removing the 'fixed' and 'fixed in experimental' tag since they
are not being used correctly.

Regards

Javier

[Javier Fernández-Sanguino (jfs)]

reassign 208700 netbase
retitle 208700 netbase: Please add --exclude=lo to /etc/init.d/networking
tags 208700 patch
thanks

Bugs #256680, #208700, #254705 and #273543 all relate to the use of 'ifdown
-a' in /etc/init.d/networking. In order to avoid this issue netbase's
networking script should be changed as shown in the patch attached so that
'lo' is always excluded when running ifdown.

If this patch is applied netbase should Depends: ifupdown ( >=0.6.4-4.9 )

Thanks

Javier

[Debian Bug Importer (debzilla)]

Message-Id: <1096264546.3358.140.camel@thanatos>
Date: Mon, 27 Sep 2004 07:55:48 +0200
From: Thomas Hood <email address hidden>
To: <email address hidden>
Cc: <email address hidden>, <email address hidden>,
 <email address hidden>
Subject: Re: Bug#273543: ifupdown: ifdown -a problems when shutdown/reboot

severity 273543 normal
tags 273543 fixed
merge 273543 208700
tags 273543 fixed-in-experimental
thanks

On Sun, 2004-09-26 at 22:44, Dj-Death wrote:
> When halting/rebooting my box, the /etc/init.d/networking script
> stops just after he printed "Deconfiguring network interfaces".

This may be occurring because /etc/init.d/networking is trying to
deconfigure the loopback interface. You may be able to cure this
problem with the help of the "--exclude" option which was added to
ifupdown in 0.6.4-4.9.

Edit /etc/init.d/networking and change the "ifdown -a" line to
"ifdown --exclude=lo -a".

Please let me know whether this fixes the problem.
--
Thomas

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 27 Sep 2004 08:47:13 +0200
From: Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?= <email address hidden>
To: Thomas Hood <email address hidden>, <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#254705: Bug#273543: ifupdown: ifdown -a problems when shutdown/reboot

tags 273543 - fixed
tags 273543 - fixed-in-experimental
thanks

> This may be occurring because /etc/init.d/networking is trying to
> deconfigure the loopback interface. You may be able to cure this
> problem with the help of the "--exclude" option which was added to
> ifupdown in 0.6.4-4.9.

Thomas, why do you merge this bug if you have not received confirmation of
it being fixed with the workaround above?

>
> Edit /etc/init.d/networking and change the "ifdown -a" line to
> "ifdown --exclude=lo -a".
>
> Please let me know whether this fixes the problem.

You should wait for the submitter's answer before merging, and, actually,
these bugs should now be reassigned to netbase since the workaround should
be added there (along with a dependency on newer ifupdown version). In any
case, I'm removing the 'fixed' and 'fixed in experimental' tag since they
are not being used correctly.

Regards

Javier

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 27 Sep 2004 09:22:17 +0200
From: Javier =?iso-8859-1?Q?Fern=E1ndez-Sanguino_Pe=F1a?= <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: Reassigning this bugs to netbase

--FkmkrVfFsRoUs1wW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

reassign 208700 netbase
retitle 208700 netbase: Please add --exclude=lo to /etc/init.d/networking
tags 208700 patch
thanks

Bugs #256680, #208700, #254705 and #273543 all relate to the use of 'ifdown
-a' in /etc/init.d/networking. In order to avoid this issue netbase's
networking script should be changed as shown in the patch attached so that
'lo' is always excluded when running ifdown.

If this patch is applied netbase should Depends: ifupdown ( >=0.6.4-4.9 )

Thanks

Javier

--FkmkrVfFsRoUs1wW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="ifdownexclude.diff"

--- networking.orig 2004-09-27 09:19:18.000000000 +0200
+++ networking 2004-09-27 09:19:53.000000000 +0200
@@ -82,7 +82,7 @@
             echo "NOT deconfiguring network interfaces: network shares still mounted."
         else
             echo -n "Deconfiguring network interfaces..."
- ifdown -a
+ ifdown --exclude=lo -a
      echo "done."
         fi
  ;;
@@ -91,7 +91,7 @@
         doopt syncookies no
         doopt ip_forward no
         echo -n "Reconfiguring network interfaces..."
- ifdown -a
+ ifdown --exclude=lo -a
         ifup -a
  echo "done."
  ;;

--FkmkrVfFsRoUs1wW--

[Marco d'Itri (md)]

# Automatically generated email from bts, devscripts version 2.8.1
merge 262180 208700

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 31 Oct 2004 16:56:09 +0100
From: Marco d'Itri <email address hidden>
To: <email address hidden>
Subject: merging 262180 208700

# Automatically generated email from bts, devscripts version 2.8.1
merge 262180 208700

[Marco d'Itri (md)]

Source: netbase
Source-Version: 4.20

We believe that the bug you reported is fixed in the latest version of
netbase, which is due to be installed in the Debian FTP archive:

netbase_4.20.dsc
  to pool/main/n/netbase/netbase_4.20.dsc
netbase_4.20.tar.gz
  to pool/main/n/netbase/netbase_4.20.tar.gz
netbase_4.20_all.deb
  to pool/main/n/netbase/netbase_4.20_all.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Marco d'Itri <email address hidden> (supplier of updated netbase package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 27 Jan 2005 01:16:00 +0100
Source: netbase
Binary: netbase
Architecture: source all
Version: 4.20
Distribution: unstable
Urgency: medium
Maintainer: Anthony Towns <email address hidden>
Changed-By: Marco d'Itri <email address hidden>
Description:
 netbase - Basic TCP/IP networking system
Closes: 208700 284317 284527 286389
Changes:
 netbase (4.20) unstable; urgency=medium
 .
   * Do not ifdown lo. (Closes: #208700)
   * etc-services: added acr-nema (104), gpsd (2947), l2f (1701).
     (Closes: #284527, #286389)
   * etc-services: sane renamed to sane-port. (Closes: #284317)
Files:
 23a0e500f31330812fc1228f3e001650 594 base important netbase_4.20.dsc
 6195aee11dc3740b5dc1bf0e8b93a4bc 57967 base important netbase_4.20.tar.gz
 1cf170b2b12e81ff79fd83f3fc0a8989 40388 base important netbase_4.20_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFB+DmxFGfw2OHuP7ERAmZ5AKCIBrHFogbG3mt4uqe2YpUiGZHbRACfeVu4
E/GiwPQfy7PJSc7I/gPwDAY=
=F8DY
-----END PGP SIGNATURE-----

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Thu, 27 Jan 2005 15:33:14 -0500
From: Marco d'Itri <email address hidden>
To: <email address hidden>
Subject: Bug#208700: fixed in netbase 4.20

Source: netbase
Source-Version: 4.20

We believe that the bug you reported is fixed in the latest version of
netbase, which is due to be installed in the Debian FTP archive:

netbase_4.20.dsc
  to pool/main/n/netbase/netbase_4.20.dsc
netbase_4.20.tar.gz
  to pool/main/n/netbase/netbase_4.20.tar.gz
netbase_4.20_all.deb
  to pool/main/n/netbase/netbase_4.20_all.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Marco d'Itri <email address hidden> (supplier of updated netbase package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 27 Jan 2005 01:16:00 +0100
Source: netbase
Binary: netbase
Architecture: source all
Version: 4.20
Distribution: unstable
Urgency: medium
Maintainer: Anthony Towns <email address hidden>
Changed-By: Marco d'Itri <email address hidden>
Description:
 netbase - Basic TCP/IP networking system
Closes: 208700 284317 284527 286389
Changes:
 netbase (4.20) unstable; urgency=medium
 .
   * Do not ifdown lo. (Closes: #208700)
   * etc-services: added acr-nema (104), gpsd (2947), l2f (1701).
     (Closes: #284527, #286389)
   * etc-services: sane renamed to sane-port. (Closes: #284317)
Files:
 23a0e500f31330812fc1228f3e001650 594 base important netbase_4.20.dsc
 6195aee11dc3740b5dc1bf0e8b93a4bc 57967 base important netbase_4.20.tar.gz
 1cf170b2b12e81ff79fd83f3fc0a8989 40388 base important netbase_4.20_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFB+DmxFGfw2OHuP7ERAmZ5AKCIBrHFogbG3mt4uqe2YpUiGZHbRACfeVu4
E/GiwPQfy7PJSc7I/gPwDAY=
=F8DY
-----END PGP SIGNATURE-----