This bug was fixed in the package systemd - 222-2ubuntu1
---
systemd (222-2ubuntu1) wily; urgency=medium
* Merge with Debian unstable. Remaining Ubuntu changes:
- Hack to support system-image read-only /etc, and modify files in
/etc/writable/ instead.
- Keep our much s
** Changed in: systemd (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1466790
Title:
dhclient does not remain running on boot
To manage notificat
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: systemd (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1466790
Title:
dh
** Package changed: ifupdown (Ubuntu) => systemd (Ubuntu)
** Changed in: systemd (Ubuntu)
Status: New => In Progress
** Changed in: systemd (Ubuntu)
Importance: Undecided => High
** Changed in: systemd (Ubuntu)
Assignee: (unassigned) => Martin Pitt (pitti)
--
You received this b
I think I may have a clue now what the problem is. Incidentally on my
bare-metal servers the network interface seems to be brought up by
something else than the ifup@.service. The status there reports it
already up when the service runs. The same seems to be happening to MAAS
instances after initia
Comparing to output of a vivid VM, the sysctl status differs in one
important detail. The initial dhclient again is gone but under the
system-ifup.slice there is the new pid...
● ifup@eth0.service - ifup for eth0
Loaded: loaded (/lib/systemd/system/ifup@.service; static; vendor preset:
enabled
Changed the disk from virtio to IDE without change. Added debug to the
kernel options and got a bit more info in journal but it looks odd.
There is a dhclient with PID 496 early on. Which does not seem to exit.
But then later on there is a 699 getting killed which matches the pid
file but never see
** Changed in: ifupdown (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1466790
Title:
dhclient does not remain running on boot
To manage notifications about
Seems on bare-metal servers I have, I do not see this. The VM as well as
well as bare-metal server of the team mate I asked are booting rather
quickly. That as side note. I upgraded the VM today and now run on
systemd/udev 221-1ubuntu2.
Still the same. One observation that looks odd: There is a pi
> Could it be that something about keeping daemons started during ifup
running be accidentally dropped?
Not that I know of, and in my wily VMs dhclient runs happily.
I don't know whether ifupdown has some useful debugging facilities. I
tried adding /usr/bin/strace -fvvs1024 -o /run/ifup.trace to
Addition to above statement. The ntpdate lock error happens when I
manually down and up eth to get dhclient running.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1466790
Title:
dhclient does not re
One thing that I noticed on the Wily VM but did not happen on a server
of someone else I asked: somehow ntpdate seems to get disrupted in some
way that leaves the lockfile in /var/lock around. Which then causes the
ominous "exceeded maximum number of lock attempts".
--
You received this bug notif
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: ubuntu
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1466790
Title:
dhclient doe
13 matches
Mail list logo
