Debian Bug report logs - #754218
boot hangs forever on LSB job "raise network interfaces"

serious

[Message part 1 (text/plain, inline)]
Package: systemd
Version: 204-14
Severity: serious

I've rebooted today my laptop (Debian testing) and it failed to boot, hanging
forever on the message:

  [ ***  ] A start job is running for LSB: Raise network interfaces.

with the 3 asterisks moving back and forth.

I've been using systemd-sysv since several months now, and this is the first
time I've stumbled upon this (even though I do not boot that often, on average
every 2 weeks or so).

I've tried various workarounds (including /etc/network/interfaces) but the only
actual "solution" I've found it to manually remove systemd-sysv, install back
systemd-shim and sysvinit{,-core}; with that the laptop boots again. If I now
manually try to boot using systemd (passing init=/bin/systemd directly to the
kernel command line), the boot hangs again.

Note that I went through #746358 ("boot hangs if /etc/fstab contains an NFS
mount") and it does *not* appear to be the same issue. For one thing I do not
have any NFS entry in /etc/fstab (the closest I have is an autofs entry);
additionally, the fix discussed on the bug report *is* present on my laptop, to
no avail.

I attach both /etc/fstab and /etc/network/interfaces, hoping they are useful.

Thanks for maintaining systemd in Debian, "systemctl status" is so cool that I
can't wait to get it back on my laptop :)

Cheers.

-- Package-specific info:

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd depends on:
ii  acl                  2.2.52-1
ii  adduser              3.113+nmu3
ii  initscripts          2.88dsf-53.2
ii  libacl1              2.2.52-1
ii  libaudit1            1:2.3.7-1
ii  libc6                2.19-4
ii  libcap2              1:2.22-1.2
ii  libcap2-bin          1:2.22-1.2
ii  libcryptsetup4       2:1.6.4-4
ii  libdbus-1-3          1.8.6-1
ii  libgcrypt11          1.5.3-4
ii  libkmod2             16-2
ii  liblzma5             5.1.1alpha+20120614-2
ii  libpam0g             1.1.8-3
ii  libselinux1          2.3-1
ii  libsystemd-daemon0   204-14
ii  libsystemd-journal0  204-14
ii  libsystemd-login0    204-14
ii  libudev1             204-14
ii  libwrap0             7.6.q-25
ii  sysv-rc              2.88dsf-53.2
ii  udev                 204-14
ii  util-linux           2.20.1-5.8

Versions of packages systemd recommends:
ii  libpam-systemd  204-14

Versions of packages systemd suggests:
pn  systemd-ui  <none>

-- no debconf information

[systemd-delta.txt (text/plain, attachment)]
[dsh-enabled.txt (text/plain, attachment)]
[fstab (text/plain, attachment)]
[Message part 1 (text/plain, inline)]
Am 08.07.2014 21:20, schrieb Stefano Zacchiroli:
> Package: systemd
> Version: 204-14
> Severity: serious
> 
> I've rebooted today my laptop (Debian testing) and it failed to boot, hanging
> forever on the message:
> 
>   [ ***  ] A start job is running for LSB: Raise network interfaces.

Did you actually wait forever, i.e. at least 90 seconds which is the
usual timeout for devices to appear or services to start?

Can you please try the following:
systemctl enable debug-shell.service

This allows you to switch to tty9 very early during boot and inspect the
system.

A systemctl list-jobs and ps aux output might be helpful in this case.

Booting with systemd.log_level=debug and the journalctl -alb output
would be great as well.

Could you also please tar up /etc/network/interfaces, /etc/network/*,
/etc/dhcp*, /etc/rc?.d/ and /etc/init.d.

This might give us further clues.

Thanks and sorry for the inconvenience.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
Ooops, forgot /etc/network/interfaces (although there isn't much to be
seen in there).

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[interfaces (text/plain, attachment)]
[Message part 1 (text/plain, inline)]
On Tue, Jul 08, 2014 at 09:32:43PM +0200, Michael Biebl wrote:
> Did you actually wait forever, i.e. at least 90 seconds which is the
> usual timeout for devices to appear or services to start?

Obviously I didn't wait *forever* :), but yes, I did wait past usual
network timeouts. To be sure, I've just tried again, and after 10+
minutes the boot was still hanging.

The good news is...

> Can you please try the following:
> systemctl enable debug-shell.service

...thanks to this, which I didn't know about, I've tracked down the
culprit to my /etc/network/if-up.d/local-firewall script, which reads:

------------------------------------------------------------------------
#!/bin/sh
# This file is managed by Puppet, local modifications will be overwritten

FIREWALL=shorewall
FIREWALL6=shorewall6

service $FIREWALL restart
service $FIREWALL6 restart
------------------------------------------------------------------------

After a couple of killall local-firewall (one for each service
invocation, evidently) the boot continued and reached completion
properly.

> A systemctl list-jobs and ps aux output might be helpful in this case.

Both attached, just in case, but the cause seems to be clear.

Now the questions/comments:

- I've had that script since ever, basically, and it used to work fine
  in the past, both before and after switching to systemd as init. I'm
  not sure why/when it stopped working.

- As a mere user, the above script is perfectly reasonable, I *do* want
  to restart my firewall every time my network interface is brought up,
  and AFAICT I'm using the right "API" to do so.

HTH,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[systemd-bug-list-jobs.txt (text/plain, attachment)]
[systemd-bug-ps-auxw.txt (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
On Tue, Jul 08, 2014 at 10:50:27PM +0200, Stefano Zacchiroli wrote:
> #!/bin/sh
[...]
> service $FIREWALL restart
> service $FIREWALL6 restart
> ------------------------------------------------------------------------
> 
> After a couple of killall local-firewall (one for each service
> invocation, evidently) the boot continued and reached completion
> properly.

Actually, that doesn't make sense. Because of course either the first
killall has killed the script and the second service is not executed; or
it didn't, but then why the second did?  So I'm still unsure about why
the killall(s) made the boot complete successfully.

If this detail is important, please let me know; I can debug it more
thoroughly (e.g., by noting down PIDs).

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
Am 08.07.2014 22:50, schrieb Stefano Zacchiroli:
> Now the questions/comments:
> 
> - I've had that script since ever, basically, and it used to work fine
>   in the past, both before and after switching to systemd as init. I'm
>   not sure why/when it stopped working.
> 
> - As a mere user, the above script is perfectly reasonable, I *do* want
>   to restart my firewall every time my network interface is brought up,
>   and AFAICT I'm using the right "API" to do so.

I had a look at the shorewall(6) init script. It has

# Required-Start:    $network $remote_fs

Now, $network is provided by the networking init script. As long as this
init script is not fully started, $network (or network.target) is not
yet available.

You've started shorewall as part of the if-up up, when $network is not
yet available, thus there is a dead lock.

So, it's actually exactly the same problem as with the NFS hook.

sysvinit doesn't bother, as it doesn't consider such dynamic
dependencies during runtime whereas systemd does.

What has changed is, that systemd_204-9 gained support for LSB system
facilities, i.e. now it understands that /etc/init.d/networking provides
$network.

This is most likely the reason you didn't see it in the past.

So, what to do about this: I'd say it's a bug to (re)start a SysV init
script from an if-up.d hook without actually checking if the service is
actually already runnig.
Because you simply disregard any dependencies which have been specified
in the LSB header.

It's problematic in general to (re)start SysV init scripts from any hook
(if-up.d, dhcp etc), since you can't ensure at that point that its
dependencies are actually all available.

I personally would consider this a local (mis)configuration which simply
didn't show up with sysvinit which only computes dependencies at install
time and only between init scripts in /etc/rc?.d/

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
Am 09.07.2014 01:14, schrieb Michael Biebl:
> So, what to do about this: I'd say it's a bug to (re)start a SysV init
> script from an if-up.d hook without actually checking if the service is
> actually already runnig.
> Because you simply disregard any dependencies which have been specified
> in the LSB header.

You'd need something like systemd's try-restart, i.e. only restart a
service if already running.

Something like
service shorewall status && service shorewall restart

should have a similar effect.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
Am 09.07.2014 01:14, schrieb Michael Biebl:
> Am 08.07.2014 22:50, schrieb Stefano Zacchiroli:
>> Now the questions/comments:
>>
>> - I've had that script since ever, basically, and it used to work fine
>>   in the past, both before and after switching to systemd as init. I'm
>>   not sure why/when it stopped working.
>>
>> - As a mere user, the above script is perfectly reasonable, I *do* want
>>   to restart my firewall every time my network interface is brought up,
>>   and AFAICT I'm using the right "API" to do so.

Running within the context of an if-up.d hook you make an explicit
assumption that $network is already provided, which is probably reasonable.

Strictly speaking though, the LSB $network facility is defined in
/etc/insserv.conf when the networking (or the old ifupdown) SysV init
script has been fully started, which is not the case during the inital
start of that script.

I'm not sure how to address this. Either the hooks are fixed to not make
this assumption, or the "bring network up" phase proving $network and
"run if-up.d hooks" are split into two different SysV init scripts.

The latter is probably not feasable.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
Am 09.07.2014 01:28, schrieb Michael Biebl:

> Running within the context of an if-up.d hook you make an explicit
> assumption that $network is already provided, which is probably reasonable.
> 
> Strictly speaking though, the LSB $network facility is defined in
> /etc/insserv.conf when the networking (or the old ifupdown) SysV init
> script has been fully started, which is not the case during the inital
> start of that script.
> 
> I'm not sure how to address this. Either the hooks are fixed to not make
> this assumption, or the "bring network up" phase proving $network and
> "run if-up.d hooks" are split into two different SysV init scripts.
> 
> The latter is probably not feasable.

And it doesn't address the issue that the service which is (re)started
from the hook has other dependencies.

Say the shorewall service has other dependencies like e.g. mysql,
because it stores its rules there (yeah, I made that up :-) ). If you
now restart shorewall from the if-up.d hook it will be started during
rcS (i.e. early boot) completely disregarding the dependency on mysql.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
Thanks for your analysis, it explains what's happening.

On Wed, Jul 09, 2014 at 01:18:33AM +0200, Michael Biebl wrote:
> Am 09.07.2014 01:14, schrieb Michael Biebl:
> > So, what to do about this: I'd say it's a bug to (re)start a SysV init
> > script from an if-up.d hook without actually checking if the service is
> > actually already runnig.
> > Because you simply disregard any dependencies which have been specified
> > in the LSB header.
> 
> You'd need something like systemd's try-restart, i.e. only restart a
> service if already running.
> 
> Something like
> service shorewall status && service shorewall restart
> 
> should have a similar effect.

I've tried this, and it does make the boot complete successfully.
However, as a consequence, the shorewall service is not running after
boot (because for some reason it fails to properly start the first
time), and will never be running again unless I explicitly "start" it
manually (because the test on the left hand side of && will always be
false).

Arguably, this might be a bug in shorewall's init script (that shouldn't
fail at boot) or, more likely, due to the fact that shorewall lacks a
service description that tells systemd to retry running it later on,
when the network is available.  If you've any idea/tip about this, I'd
appreciate.

In the meantime, feel free to deal as you please with this bug.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
Am 09.07.2014 13:51, schrieb Stefano Zacchiroli:

> I've tried this, and it does make the boot complete successfully.
> However, as a consequence, the shorewall service is not running after
> boot (because for some reason it fails to properly start the first
> time), and will never be running again unless I explicitly "start" it
> manually (because the test on the left hand side of && will always be
> false).
> 
> Arguably, this might be a bug in shorewall's init script (that shouldn't
> fail at boot) or, more likely, due to the fact that shorewall lacks a
> service description that tells systemd to retry running it later on,
> when the network is available.  If you've any idea/tip about this, I'd
> appreciate.

What's the output of
 ls -la /etc/rc?.d/???shorewall
and
 ls -la /etc/rc?.d/???shorewall6

And the output of
 systemctl status shorewall.service shorewall6.service

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
On Wed, Jul 09, 2014 at 02:04:49PM +0200, Michael Biebl wrote:
> What's the output of
>  ls -la /etc/rc?.d/???shorewall
> and
>  ls -la /etc/rc?.d/???shorewall6

  $ ls -la /etc/rc?.d/???shorewall
  lrwxrwxrwx 1 root root 19 apr 27 15:43 /etc/rc0.d/K01shorewall -> ../init.d/shorewall
  lrwxrwxrwx 1 root root 19 apr 27 15:43 /etc/rc6.d/K01shorewall -> ../init.d/shorewall
  lrwxrwxrwx 1 root root 19 apr 27 15:43 /etc/rcS.d/S21shorewall -> ../init.d/shorewall

  $ ls -la /etc/rc?.d/???shorewall6
  lrwxrwxrwx 1 root root 20 apr 27 15:44 /etc/rc0.d/K01shorewall6 -> ../init.d/shorewall6
  lrwxrwxrwx 1 root root 20 apr 27 15:44 /etc/rc6.d/K01shorewall6 -> ../init.d/shorewall6
  lrwxrwxrwx 1 root root 20 apr 27 15:44 /etc/rcS.d/S21shorewall6 -> ../init.d/shorewall6

> And the output of
>  systemctl status shorewall.service shorewall6.service

  $ systemctl status shorewall.service shorewall6.service

  shorewall.service - LSB: Configure the firewall at boot time
     Loaded: loaded (/etc/init.d/shorewall)
     Active: failed (Result: exit-code) since mer 2014-07-09 16:42:17 CEST; 1min 26s ago
    Process: 1255 ExecStart=/etc/init.d/shorewall start (code=exited, status=1/FAILURE)

  shorewall6.service - LSB: Configure the firewall at boot time
     Loaded: loaded (/etc/init.d/shorewall6)
     Active: active (exited) since mer 2014-07-09 16:43:28 CEST; 15s ago
    Process: 6089 ExecStop=/etc/init.d/shorewall6 stop (code=exited, status=0/SUCCESS)
    Process: 6160 ExecStart=/etc/init.d/shorewall6 start (code=exited, status=0/SUCCESS)

Note: I'm fine with the fact that shorewall(s) might return a non-0 exit
code at boot time, due to the lack of connectivity, but I'd like for the
service not to be put in a state where it does not start later on, ever.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
Am 09.07.2014 16:45, schrieb Stefano Zacchiroli:
> On Wed, Jul 09, 2014 at 02:04:49PM +0200, Michael Biebl wrote:
>> What's the output of
>>  ls -la /etc/rc?.d/???shorewall
>> and
>>  ls -la /etc/rc?.d/???shorewall6
> 
>   $ ls -la /etc/rc?.d/???shorewall
>   lrwxrwxrwx 1 root root 19 apr 27 15:43 /etc/rc0.d/K01shorewall -> ../init.d/shorewall
>   lrwxrwxrwx 1 root root 19 apr 27 15:43 /etc/rc6.d/K01shorewall -> ../init.d/shorewall
>   lrwxrwxrwx 1 root root 19 apr 27 15:43 /etc/rcS.d/S21shorewall -> ../init.d/shorewall
> 
>   $ ls -la /etc/rc?.d/???shorewall6
>   lrwxrwxrwx 1 root root 20 apr 27 15:44 /etc/rc0.d/K01shorewall6 -> ../init.d/shorewall6
>   lrwxrwxrwx 1 root root 20 apr 27 15:44 /etc/rc6.d/K01shorewall6 -> ../init.d/shorewall6
>   lrwxrwxrwx 1 root root 20 apr 27 15:44 /etc/rcS.d/S21shorewall6 -> ../init.d/shorewall6
> 
>> And the output of
>>  systemctl status shorewall.service shorewall6.service
> 
>   $ systemctl status shorewall.service shorewall6.service
> 
>   shorewall.service - LSB: Configure the firewall at boot time
>      Loaded: loaded (/etc/init.d/shorewall)
>      Active: failed (Result: exit-code) since mer 2014-07-09 16:42:17 CEST; 1min 26s ago
>     Process: 1255 ExecStart=/etc/init.d/shorewall start (code=exited, status=1/FAILURE)
> 
>   shorewall6.service - LSB: Configure the firewall at boot time
>      Loaded: loaded (/etc/init.d/shorewall6)
>      Active: active (exited) since mer 2014-07-09 16:43:28 CEST; 15s ago
>     Process: 6089 ExecStop=/etc/init.d/shorewall6 stop (code=exited, status=0/SUCCESS)
>     Process: 6160 ExecStart=/etc/init.d/shorewall6 start (code=exited, status=0/SUCCESS)
> 
> Note: I'm fine with the fact that shorewall(s) might return a non-0 exit
> code at boot time, due to the lack of connectivity, but I'd like for the
> service not to be put in a state where it does not start later on, ever.

That is a bit odd. The SysV should only be run once the networking
service init script has started.

The problem most likely here is, that you use allow-hotplug. You'd need
something like [1] which actively blocks until you actually have a
network connection.

Anyway, since apparently your shorewall.service is *not* successfully
started during boot, the "service shorewall status && service shorewall
restart" workaround will indeed not work.

In that case you could apply the same workaround that was done for the
mountnfs hook, i.e. do not trigger a restart of the shorewall service
while the networking init script is still being started, i.e.
network.target job is currently being scheduled and not yet running.

So, try to guard your restarts like this:

===
if [ -d /run/systemd/system ]; then
       systemctl list-jobs | grep -q network.target && exit 0
fi
service shorewall restart
service shorewall6 restart
===

[1] http://people.debian.org/~biebl/ifupdown-wait-online.tar.gz
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
On Wed, Jul 09, 2014 at 05:31:57PM +0200, Michael Biebl wrote:
> So, try to guard your restarts like this:
> 
> ===
> if [ -d /run/systemd/system ]; then
>        systemctl list-jobs | grep -q network.target && exit 0
> fi
> service shorewall restart
> service shorewall6 restart
> ===

This did the trick! (and I quite like the fact that it will work
properly both with and without systemd running)

Thanks a lot for your guidance,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[signature.asc (application/pgp-signature, inline)]
Hello!

i don't use shorewall (only a little script in /usr/local for firewall,
run from rc.local)

updated system a few days ago and today restart.
wait....reboot, wait, reboot and so...
Press CTRL-C, no affect
"ctrl+alt+del" or "right alt + sysrq + b" works

no timeout or affect to CTRL-C

and reboot from system rescue cd and write to
/etc/init.d/networking first line:
exit 0

It's working but not too good....

(After boot comment out the line and
/etc/init.d/networking restart is working

It's okay now, but next restart will wrong again :(

-- 
http://www.micros~1

[Message part 1 (text/plain, inline)]
Am 10.07.2014 17:05, schrieb Stefano Zacchiroli:
> On Wed, Jul 09, 2014 at 05:31:57PM +0200, Michael Biebl wrote:
>> So, try to guard your restarts like this:
>>
>> ===
>> if [ -d /run/systemd/system ]; then
>>        systemctl list-jobs | grep -q network.target && exit 0
>> fi
>> service shorewall restart
>> service shorewall6 restart
>> ===
> 
> This did the trick! (and I quite like the fact that it will work
> properly both with and without systemd running)

I thought about this issue a bit.

It is arguably a bug / configuration error to (re)start a service from a
hook at a point where the dependencies of the service are not yet satisfied.

The resulting dependency loop is silently ignored  by sysvinit, which
isn't great.
The failure mode of systemd to simply "dead lock" isn't great either.

I think we should do two things:

1/ document in the release notes / systemd FAQ that restarting services
from hooks script (ifupdown, dhclient, etc) is problematic.

2/ change invoke-rc.d/service//lib/lsb/init-functions.d/40-systemd to
special case (re)start requests while sysinit.target/network.target is
scheduled (i.e. during early boot), i.e. use --no-block.
This will make systemctl non-blocking and simply enqueue the job.

A sample patch for the lsb init hook is attached

Comments/feedback most welcome.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[lsb-init-hook.diff (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
On Sat, Jul 26, 2014 at 11:43:51PM +0200, Michael Biebl wrote:
> I think we should do two things:
> 
> 1/ document in the release notes / systemd FAQ that restarting services
> from hooks script (ifupdown, dhclient, etc) is problematic.
> 
> 2/ change invoke-rc.d/service//lib/lsb/init-functions.d/40-systemd to
> special case (re)start requests while sysinit.target/network.target is
> scheduled (i.e. during early boot), i.e. use --no-block.
> This will make systemctl non-blocking and simply enqueue the job.

I'm not familiar enough with systemd to comment on your patch. But as a
mere user I think such a failsafe might save the day for quite a few
people. Bonus point would be to raise some warning about the avoided
deadlock, so that users can fix their hooks when needed.

With many thanks for your work on this,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
Today, after upgrading kde, sysvinit-core was replaced with systemd-sysv
208-8. Reboot gives the same error.
Boot becomes normal after "auto" entries were committed out in
/etc/network/interfaces (except lo). Not workable file is attached.

-- 
sergio.

[interfaces (text/plain, attachment)]
[Message part 1 (text/plain, inline)]
Am 04.09.2014 um 01:43 schrieb sergio:
> 
> Today, after upgrading kde, sysvinit-core was replaced with systemd-sysv
> 208-8. Reboot gives the same error.
> Boot becomes normal after "auto" entries were committed out in
> /etc/network/interfaces (except lo). Not workable file is attached.

Could you please send me all files from /etc/network/ and /etc/dhcp/ (as
tarball).

Thanks

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]
On 09/04/2014 04:29 AM, Michael Biebl wrote:

> Could you please send me all files from /etc/network/ and
> /etc/dhcp/ (as tarball).

There are no custom files in /etc/network, do you really need them?

% ls -R /etc/network
/etc/network:
if-down.d/  if-post-down.d/  if-pre-up.d/  if-up.d/  interfaces.d/
interfaces  run@

/etc/network/if-down.d:
openvpn*  upstart*  wpasupplicant@

/etc/network/if-post-down.d:
hostapd@  wpasupplicant@

/etc/network/if-pre-up.d:
ethtool*  hostapd@  wpasupplicant@

/etc/network/if-up.d:
ethtool*  mountnfs*  openssh-server*  openvpn*  upstart*  wpasupplicant@

/etc/network/interfaces.d:
%

And only dhcpd.conf is modified in /etc/dhcp :
% ls -R /etc/dhcp
/etc/dhcp:
dhclient-exit-hooks.d/  dhcpd.conf  dhcpd.conf.orig

/etc/dhcp/dhclient-exit-hooks.d:
ntp

% cat /etc/dhcp/dhcpd.conf | grep -v '^#' | grep -v '^$'
authoritative;
log-facility local7;
default-lease-time 600;
max-lease-time 7200;
deny bootp;
ddns-update-style none;
option pcode code 100 = text;
option tcode code 101 = text;
subnet 192.168.9.0 netmask 255.255.255.0 {
        range 192.168.9.64 192.168.9.127;
        option routers 192.168.9.1;
        option domain-name "foo";
        option domain-name-servers 192.168.5.1;
        option ntp-servers 192.168.9.1;
        option tcode "Europe/Moscow";
}

-- 
sergio.

I stumbled over this bug while investigating the same symptoms on my
laptop with testing.
After a loss of power I rebooted and it seemingly hung on fsck (last
visible line was something with systemd-fsck), but on rebooting in
recovery I got the
  [ ***  ] A start job is running for LSB: Raise network interfaces.

as well.

I "fixed" it by booting single user mode and removing firestarter, which
I suspected, as it was the only result of

grep -r restart /etc/network

I have systemd 208-8.

Greetings,
Florian

[Message part 1 (text/plain, inline)]
Dear all,

same happening here:

Debian Jessie/Unstable amd64 up-to-date.

systemd: Version : 215-7

shorewall installed and configured

NO nfs mount of any kind

NO network mount of any kind

NetworkManager NOT installed (/etc/network/interfaces used)

NO local custom init script

Additionally this machine as two wired network interfaces (configured) 
and one wireless (not configured), when the "hang" occurs it sometimes 
(rarely, twice in a dozen try, some left to hang for 30minutes) proceeds 
to boot. When this happens the second interface eth1 (Intel Corporation 
82541PI Gigabit Ethernet Controller (rev 05) ) is not appearing in 
ifconfig. When this occurs I can not modprobe the driver (e1000) 
manually, nor bring the interface by any mean ! I suspected a 
hardware/bios initialization bug but the same interface works flawlessly 
with sysvinit-core and systemd-shim, as with rescue system System Rescue CD.

/etc/network and /etc/dhcp attached.

Only workaround was to chroot from rescue system and switch back to 
sysvinit manually.

I can reinstall systemd as init and make the system fail again (outside 
of office hours ;-) ) if provided with direction as to how collect 
additional information.

Thank you for your work and attention,

All the best.

[dhcp_network.tar.gz (application/gzip, attachment)]
[Message part 1 (text/plain, inline)]
On Lu, 01 dec 14, 14:12:01, tv.debian@googlemail.com wrote:
> 
> I can reinstall systemd as init and make the system fail again (outside of
> office hours ;-) ) if provided with direction as to how collect additional
> information.

Please enable the debug console on VT9 (boot with 'systemd.debug-shell' 
as kernel parameter) and attach the output of

    journalctl -alb

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt

[signature.asc (application/pgp-signature, inline)]
On Mon, 1 Dec 2014 13:35:04 +0200 Andrei POPESCU 
<andreimpopescu@gmail.com> wrote:
> On Lu, 01 dec 14, 14:12:01, tv.debian@googlemail.com wrote:
> >
> > I can reinstall systemd as init and make the system fail again 
(outside of
> > office hours ;-) ) if provided with direction as to how collect 
additional
> > information.
>
> Please enable the debug console on VT9 (boot with 'systemd.debug-shell'
> as kernel parameter) and attach the output of
>
> journalctl -alb
>
> Kind regards,
> Andrei

I did so, when switching to VT 9 the screen is spamed with the systemd 
message about "starting LSB". I typed blindly " journalctl -alb"  and 
noticed that a shell session was indeed active behind the spam wall !

I can see that the driver "e1000" for the network card is loaded early 
without problem.

I have very few errors, I get:

"failed to find module 'lp'" and same for 'ppdev' , which in turn 
generates several fail warnings later on for "systemd load kernel modules".

"Failed at step EXEC spawning /usr/lib/systemd/scripts/mdadm_env.sh"

There is no /usr/lib/systemd/scripts directory on my system (system is 
mdadm raid + LUKS). "apt-file search" didn't tell me what package is 
supposed to provide this "mdadm_env.sh" script, and "find" didn't show 
it on my system either.

"ERROR : Duplicate address 192.168.1.2 assigned in the network where 
eth1 is connected to"

The last one puzzles me as at the time I booted I was the only machine 
on the network, and address is assigned from the DHCP server (openwrt) 
through MAC address reservation.
grepping through /etc for string "192.168.1.2" show one occurrence in 
/etc/hosts, one in /etc/samba/lmhosts, and one in backuppc configuration.

arp shows no address or MAC conflict on the network, and my router 
doesn't either.

Finally I did "pgrep network" and killed the corresponding PID to get 
the boot process to resume. It did successfully and the system is fully 
functional, including networking, raid and all, which makes me think 
some of the failure reports may be bogus ?

What makes me really skeptic of systemd behavior here is the 
impossibility to kill a stalled process and resume boot without first 
rebooting in systemd debug mode, or at least get a sane timeout (and 
advertise it so that users can wait).

Thank you for your assistance.

Package: systemd
Version: 215-7

I can't help, don't even know if this is systemd related,
but I've noticed about 15 seconds delay while looking at:

 [ ***  ] A start job is running for LSB: Raise network interfaces.

since recent ifupdown 0.7.50 upgrade.

 apt-get --reinstall install ifupdown=0.7.49

and hold, solved this for now.

[Message part 1 (text/plain, inline)]
Am 01.12.2014 um 16:57 schrieb Alex Mayer:
> Package: systemd
> Version: 215-7
> 
> I can't help, don't even know if this is systemd related,
> but I've noticed about 15 seconds delay while looking at:
> 
>  [ ***  ] A start job is running for LSB: Raise network interfaces.
> 
> since recent ifupdown 0.7.50 upgrade.

Does the system itself boot correctly?

How does your /etc/network/interfaces look like?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
I'm having the same issue,... so maybe it comes from #766943?
I've only checked the fix for that on the server nodes (where that delay
of 1-2 mins doesn't really get noticed) - not on my desktop node.

Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]
[Message part 1 (text/plain, inline)]
Am 01.12.2014 um 17:48 schrieb Christoph Anton Mitterer:
> I'm having the same issue,... so maybe it comes from #766943?

Very likely, yes. If you use DHCP, it can easily take a few seconds for
your network to be configured.
And now that /etc/init.d/networking both handles allow-hotplug and auto
interfaces and blocks for ifup to complete for those interfaces, the
delay during boot is kinda expected.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
On Mon, 2014-12-01 at 18:00 +0100, Michael Biebl wrote: 
> Very likely, yes. If you use DHCP, it can easily take a few seconds for
> your network to be configured.
> And now that /etc/init.d/networking both handles allow-hotplug and auto
> interfaces and blocks for ifup to complete for those interfaces, the
> delay during boot is kinda expected.

So can we keep the other fix as it is? I mean this will just cause
another stupid systemd-is-responsible-and-it-sucks hatred storm by
people... :(

[smime.p7s (application/x-pkcs7-signature, attachment)]
[Message part 1 (text/plain, inline)]
Am 01.12.2014 um 18:08 schrieb Christoph Anton Mitterer:
> On Mon, 2014-12-01 at 18:00 +0100, Michael Biebl wrote: 
>> Very likely, yes. If you use DHCP, it can easily take a few seconds for
>> your network to be configured.
>> And now that /etc/init.d/networking both handles allow-hotplug and auto
>> interfaces and blocks for ifup to complete for those interfaces, the
>> delay during boot is kinda expected.
> 
> So can we keep the other fix as it is? I mean this will just cause
> another stupid systemd-is-responsible-and-it-sucks hatred storm by
> people... :(

Not quite sure what you mean with "other fix"? Can you elaborate?

You can't eat a cake and have it too.
Either we wait blockingly (and wait actually means, well, delaying your
boot process and making it slower) for ifup to complete during boot as
workaround for broken software which doesn't deal with dynamic network
changes and requires $network, or we don't blockingly wait and cause
that other software to break.

For jessie we decided to take that boot delay hit in exchange for
supporting $network requiring software.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]
[Message part 1 (text/plain, inline)]
On Mon, 2014-12-01 at 18:55 +0100, Michael Biebl wrote: 
> Not quite sure what you mean with "other fix"? Can you elaborate?
I mean the udevsettle, which apparently causes this delay now...

I just see it coming that gazillions of people cause to whine about that
delay :(

> For jessie we decided to take that boot delay hit in exchange for
> supporting $network requiring software.
Okay.. I'm fine with it :)

[smime.p7s (application/x-pkcs7-signature, attachment)]
On 2014-12-01 16:32, Michael Biebl wrote:
> Does the system itself boot correctly?
Yes.

> How does your /etc/network/interfaces look like?
Default configuration. Like Stefano Zacchiroli's, without last two IPv6 
lines:

https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=interfaces;att=1;bug=754218

After reading further explanations, I understand this workaround for 
broken software
is unpleasant but necessary for Jessie release.

[Message part 1 (text/plain, inline)]
Control: tag -1 moreinfo

On Lu, 01 dec 14, 18:15:22, tv.debian@googlemail.com wrote:
> 
> I did so, when switching to VT 9 the screen is spamed with the systemd
> message about "starting LSB". I typed blindly " journalctl -alb"  and
> noticed that a shell session was indeed active behind the spam wall !

Could you also attach the output to this bug?

> I can see that the driver "e1000" for the network card is loaded early
> without problem.
> 
> I have very few errors, I get:
> 
> "failed to find module 'lp'" and same for 'ppdev' , which in turn generates
> several fail warnings later on for "systemd load kernel modules".

You probably have some modules in /etc/modules or /etc/modprobe.d/ that 
fail to load. 

> "Failed at step EXEC spawning /usr/lib/systemd/scripts/mdadm_env.sh"
> 
> There is no /usr/lib/systemd/scripts directory on my system (system is mdadm
> raid + LUKS). "apt-file search" didn't tell me what package is supposed to
> provide this "mdadm_env.sh" script, and "find" didn't show it on my system
> either.

This might be bogus, but a little more details about your setup wouldn't 
hurt.

> "ERROR : Duplicate address 192.168.1.2 assigned in the network where eth1 is
> connected to"
> 
> The last one puzzles me as at the time I booted I was the only machine on
> the network, and address is assigned from the DHCP server (openwrt) through
> MAC address reservation.
> grepping through /etc for string "192.168.1.2" show one occurrence in
> /etc/hosts, one in /etc/samba/lmhosts, and one in backuppc configuration.
> 
> arp shows no address or MAC conflict on the network, and my router doesn't
> either.
> 
> Finally I did "pgrep network" and killed the corresponding PID to get the
> boot process to resume. It did successfully and the system is fully
> functional, including networking, raid and all, which makes me think some of
> the failure reports may be bogus ?

Please attach also your /etc/network/interfaces.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt

[signature.asc (application/pgp-signature, inline)]
On Wed, 10 Dec 2014 12:23:15 +0200 Andrei POPESCU 
<andreimpopescu@gmail.com> wrote:
> Control: tag -1 moreinfo
>
> On Lu, 01 dec 14, 18:15:22, tv.debian@googlemail.com wrote:
> >
> > I did so, when switching to VT 9 the screen is spamed with the systemd
> > message about "starting LSB". I typed blindly " journalctl -alb" and
> > noticed that a shell session was indeed active behind the spam wall !
>
> Could you also attach the output to this bug?
>
> > I can see that the driver "e1000" for the network card is loaded early
> > without problem.
> >
> > I have very few errors, I get:
> >
> > "failed to find module 'lp'" and same for 'ppdev' , which in turn 
generates
> > several fail warnings later on for "systemd load kernel modules".
>
> You probably have some modules in /etc/modules or /etc/modprobe.d/ that
> fail to load.
>
> > "Failed at step EXEC spawning /usr/lib/systemd/scripts/mdadm_env.sh"
> >
> > There is no /usr/lib/systemd/scripts directory on my system (system 
is mdadm
> > raid + LUKS). "apt-file search" didn't tell me what package is 
supposed to
> > provide this "mdadm_env.sh" script, and "find" didn't show it on my 
system
> > either.
>
> This might be bogus, but a little more details about your setup wouldn't
> hurt.
>
> > "ERROR : Duplicate address 192.168.1.2 assigned in the network 
where eth1 is
> > connected to"
> >
> > The last one puzzles me as at the time I booted I was the only 
machine on
> > the network, and address is assigned from the DHCP server (openwrt) 
through
> > MAC address reservation.
> > grepping through /etc for string "192.168.1.2" show one occurrence in
> > /etc/hosts, one in /etc/samba/lmhosts, and one in backuppc 
configuration.
> >
> > arp shows no address or MAC conflict on the network, and my router 
doesn't
> > either.
> >
> > Finally I did "pgrep network" and killed the corresponding PID to 
get the
> > boot process to resume. It did successfully and the system is fully
> > functional, including networking, raid and all, which makes me 
think some of
> > the failure reports may be bogus ?
>
> Please attach also your /etc/network/interfaces.
>
> Kind regards,
> Andrei
> --
> http://wiki.debian.org/FAQsFromDebianUser
> Offtopic discussions among Debian users and developers:
> http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
> http://nuvreauspam.ro/gpg-transition.txt

Hi, thank you for your attention but since I am not the original 
submitter of this bug and was under the impression that it was "solved" 
(a workaround has been found) I didn't want to add more noise. I will 
open a new bug if I switch back to systemd and still experience the issue.

My "interfaces" file is attached to my first message, together with dhcp 
conf.
I am looking into the modules error, I do have quite a few ones in 
modules.conf, historical heritage and probably unnecessary now, but not 
the ones mentioned in the logs.
I will generate and attach a new boot log when I get a chance to run 
this system with systemd again, maybe this week-end.
This system is LUKS over RAID1 (mdadm), no lvm. /boot, /root and /home 
separate, plus other data and backup arrays that get mounted with a 
combination of pam_mount, key-file and decrypt_derived . /root is 
encrypted too, I get to install plymouth whenever I want to test systemd 
to be able to see the various password prompts. This plymouth thing 
should be a "suggest" for systemd with a comment about Luks encrypted 
partitions, that's another story.

Regarding /usr/lib/systemd/scripts, I don't find it with "apt-file 
search", I don't know what package is supposed to create it. Do you have 
this directory on your (Testing/Sid) systems, I don't have it on any !

Thank you again, you can disregard this reply if this is considered 
irrelevant to the bug, I will open a new one when I can test this again.

Cheers.

Hi *,

I ran into the same problem. The boot time has increased almost by one
minute since an upgrade recently.

$ sudo systemd-analyze blame
     1min 1.970s networking.service
          1.158s systemd-udev-settle.service
          1.145s uml-utilities.service
           409ms tor.service
...

After having a look at the log files I found out that the DHCP client
tries to get an address on eth0. But I'm on WLAN (wlan0) and there isn't
even a cable plugged in on eth0.

As soon as I comment the eth0 lines in /etc/network/interfaces out, the
problem is gone. But I guess that's not a proper solution.

My /etc/network/interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

$ systemd  sudo systemctl status networking.service
  networking.service - LSB: Raise network interfaces.
   Loaded: loaded (/etc/init.d/networking)
  Drop-In: /run/systemd/generator/networking.service.d
           └─50-insserv.conf-$network.conf
   Active: active (running) since Mon 2014-12-15 12:57:02 CET; 20min ago
  Process: 1951 ExecStart=/etc/init.d/networking start (code=exited,
status=0/SUCCESS)
   CGroup: /system.slice/networking.service
           └─2176 dhclient -v -pf /run/dhclient.eth0.pid -lf
/var/lib/dhcp/dhclient.eth0.leases eth0

$ sudo journalctl _SYSTEMD_UNIT=networking.service
-- Logs begin at Mon 2014-12-15 12:55:59 CET, end at Mon 2014-12-15
13:19:21 CET. --
Dec 15 12:56:01 k0ld dhclient[2156]: Internet Systems Consortium DHCP
Client 4.3.1
Dec 15 12:56:01 k0ld dhclient[2156]: Copyright 2004-2014 Internet
Systems Consortium.
Dec 15 12:56:01 k0ld dhclient[2156]: All rights reserved.
Dec 15 12:56:01 k0ld dhclient[2156]: For info, please visit
https://www.isc.org/software/dhcp/
Dec 15 12:56:01 k0ld dhclient[2156]:
Dec 15 12:56:01 k0ld networking[1951]: Configuring network
interfaces...Internet Systems Consortium DHCP Client 4.3.1
Dec 15 12:56:01 k0ld networking[1951]: Copyright 2004-2014 Internet
Systems Consortium.
Dec 15 12:56:01 k0ld networking[1951]: All rights reserved.
Dec 15 12:56:01 k0ld networking[1951]: For info, please visit
https://www.isc.org/software/dhcp/
Dec 15 12:56:01 k0ld dhclient[2156]: Listening on LPF/eth0/f0:de:f1:90:28:7f
Dec 15 12:56:01 k0ld dhclient[2156]: Sending on   LPF/eth0/f0:de:f1:90:28:7f
Dec 15 12:56:01 k0ld dhclient[2156]: Sending on   Socket/fallback
Dec 15 12:56:01 k0ld dhclient[2156]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 7
Dec 15 12:56:01 k0ld networking[1951]: Listening on
LPF/eth0/f0:de:f1:90:28:7f
Dec 15 12:56:01 k0ld networking[1951]: Sending on
LPF/eth0/f0:de:f1:90:28:7f
Dec 15 12:56:01 k0ld networking[1951]: Sending on   Socket/fallback
Dec 15 12:56:01 k0ld networking[1951]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 7
Dec 15 12:56:08 k0ld dhclient[2156]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 13
Dec 15 12:56:08 k0ld networking[1951]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 13
Dec 15 12:56:21 k0ld dhclient[2156]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 16
Dec 15 12:56:21 k0ld networking[1951]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 16
Dec 15 12:56:37 k0ld dhclient[2156]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 16
Dec 15 12:56:37 k0ld networking[1951]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 16
Dec 15 12:56:53 k0ld dhclient[2156]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 9
Dec 15 12:56:53 k0ld networking[1951]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 9
Dec 15 12:57:02 k0ld dhclient[2156]: No DHCPOFFERS received.
Dec 15 12:57:02 k0ld dhclient[2156]: No working leases in persistent
database - sleeping.
Dec 15 12:57:02 k0ld networking[1951]: No DHCPOFFERS received.
Dec 15 12:57:02 k0ld networking[1951]: No working leases in persistent
database - sleeping.
Dec 15 12:57:02 k0ld networking[1951]: done.
Dec 15 13:00:20 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 8
Dec 15 13:00:28 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 13
Dec 15 13:00:41 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 18
Dec 15 13:00:59 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 20
Dec 15 13:01:19 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 2
Dec 15 13:01:21 k0ld dhclient[2176]: No DHCPOFFERS received.
Dec 15 13:01:21 k0ld dhclient[2176]: No working leases in persistent
database - sleeping.
Dec 15 13:04:11 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 6
Dec 15 13:04:17 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 12
Dec 15 13:04:29 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 20
Dec 15 13:04:49 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 10
Dec 15 13:04:59 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 11
Dec 15 13:05:10 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 2
Dec 15 13:05:12 k0ld dhclient[2176]: No DHCPOFFERS received.
Dec 15 13:05:12 k0ld dhclient[2176]: No working leases in persistent
database - sleeping.
Dec 15 13:10:52 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 6
Dec 15 13:10:58 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 7
Dec 15 13:11:05 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 9
Dec 15 13:11:14 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 14
Dec 15 13:11:28 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 17
Dec 15 13:11:45 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 8
Dec 15 13:11:53 k0ld dhclient[2176]: No DHCPOFFERS received.
Dec 15 13:11:53 k0ld dhclient[2176]: No working leases in persistent
database - sleeping.
Dec 15 13:15:50 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 7
Dec 15 13:15:57 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 14
Dec 15 13:16:11 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 17
Dec 15 13:16:28 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 7
Dec 15 13:16:35 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 14
Dec 15 13:16:49 k0ld dhclient[2176]: DHCPDISCOVER on eth0 to
255.255.255.255 port 67 interval 2
Dec 15 13:16:51 k0ld dhclient[2176]: No DHCPOFFERS received.
Dec 15 13:16:51 k0ld dhclient[2176]: No working leases in persistent
database - sleeping.

As you can see here, eth0 is down and it should be, since no cable is
plugged in.

$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel
state DOWN mode DEFAULT group default qlen 1000
    link/ether f0:de:f1:90:28:7f brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
mode DORMANT group default qlen 1000
    link/ether 9c:b7:0d:e7:48:1b brd ff:ff:ff:ff:ff:ff
4: wwan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT group default qlen 1000
    link/ether 02:80:37:ec:02:00 brd ff:ff:ff:ff:ff:ff

Just let me know if you want me to do some other tests.

Best regards,

Jochen

On Mon, Dec 15, 2014 at 13:34:28 +0100, Jochen Bartl wrote:

> Hi *,
> 
> I ran into the same problem. The boot time has increased almost by one
> minute since an upgrade recently.
> 
> $ sudo systemd-analyze blame
>      1min 1.970s networking.service
>           1.158s systemd-udev-settle.service
>           1.145s uml-utilities.service
>            409ms tor.service
> ...
> 
> 
> After having a look at the log files I found out that the DHCP client
> tries to get an address on eth0. But I'm on WLAN (wlan0) and there isn't
> even a cable plugged in on eth0.
> 
> As soon as I comment the eth0 lines in /etc/network/interfaces out, the
> problem is gone. But I guess that's not a proper solution.
> 
I'm pretty sure what you ran into is a different issue, see
https://bugs.debian.org/771943.

Cheers,
Julien
-- 
Julien Cristau          <julien.cristau@logilab.fr>
Logilab		        http://www.logilab.fr/
Informatique scientifique & gestion de connaissances

On 12/16/2014 06:13 PM, Julien Cristau wrote:
> I'm pretty sure what you ran into is a different issue, see
> https://bugs.debian.org/771943.
> 
> Cheers,
> Julien
> 

You're right. It looks more like the bug you mentioned.

Best regards,

Jochen

Debian Bug report logs - #754218 boot hangs forever on LSB job "raise network interfaces"

Debian Bug report logs - #754218
boot hangs forever on LSB job "raise network interfaces"