Attached is an archive containing the output of:
# strace -ff -F -o /tmp/dhclient.strace dhclient eth0:0
There is already a pid file /var/run/dhclient.pid with pid 134519072
Internet Systems Consortium DHCP Client V3.0.6
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
SIOCSIFADDR: Permission denied
SIOCSIFFLAGS: Permission denied
SIOCSIFFLAGS: Permission denied
Bind socket to interface: No such device
Some interesting bits include:
>From dhclient.strace.9271-avahi-autoipd:
execve("/usr/sbin/avahi-autoipd", ["/usr/sbin/avahi-autoipd", "-k", "eth0:0"],
[/* 7 vars */]) = 0
[...]
open("/var/run//avahi-autoipd.eth0:0.pid", O_RDWR) = -1 ENOENT (No such file or
directory)
write(2, "Failed to kill daemon: No such f"..., 48) = 48
write(2, "\n", 1) = 1
exit_group(1) = ?
That avahi-autoipd is trying to access /var/run/avahi-autoipd.eth0:0.pid may be
by design, or may be a bug. I don't know enough about avahi to know whether it
normally has a separate daemon running for each interface, and if so, whether
that should apply to virtual interfaces.
I saw a similar error in some of the messages output by dhclient, where
it was trying to create a PID file for itself that incorporated the
virtual device name. Again, should it be running a separate instance of
the daemon for each virtual interface?
And from dhclient.strace.9272-ifconfig:
execve("/sbin/ifconfig", ["ifconfig", "eth0:0", "inet", "0", "up"], [/* 7 vars
*/]) = 0
[...]
socket(PF_FILE, SOCK_DGRAM, 0) = 3
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
access("/proc/net/if_inet6", R_OK) = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 6
[...]
ioctl(4, SIOCSIFADDR, 0xbfdbeb00) = -1 EACCES (Permission denied)
dup(2) = 7
fcntl64(7, F_GETFL) = 0x2 (flags O_RDWR)
fstat64(7, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 10), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f0b000
_llseek(7, 0, 0xbfdbe498, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(7, "SIOCSIFADDR: Permission denied\n", 31) = 31
close(7) = 0
munmap(0xb7f0b000, 4096) = 0
ioctl(4, SIOCGIFFLAGS, {ifr_name="eth0:0",
ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
ioctl(4, SIOCSIFFLAGS, 0xbfdbe9e8) = -1 EACCES (Permission denied)
dup(2) = 7
fcntl64(7, F_GETFL) = 0x2 (flags O_RDWR)
fstat64(7, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 10), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f0b000
_llseek(7, 0, 0xbfdbe438, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(7, "SIOCSIFFLAGS: Permission denied\n", 32) = 32
close(7) = 0
munmap(0xb7f0b000, 4096) = 0
ioctl(4, SIOCGIFFLAGS, {ifr_name="eth0:0",
ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
ioctl(4, SIOCSIFFLAGS, 0xbfdbe9e8) = -1 EACCES (Permission denied)
dup(2) = 7
fcntl64(7, F_GETFL) = 0x2 (flags O_RDWR)
fstat64(7, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 10), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f0b000
_llseek(7, 0, 0xbfdbe438, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(7, "SIOCSIFFLAGS: Permission denied\n", 32) = 32
close(7) = 0
munmap(0xb7f0b000, 4096) = 0
exit_group(-1) = ?
This call to ifconfig seems to be the source of the errors. I'm puzzled how you
can get an EACCES error on a newly created socket while running as root, if
SELinux or AppArmor isn't involved (as far as I'm aware).
If I run the above command directly:
# /sbin/ifconfig eth0:0 inet 0 up
SIOCSIFFLAGS: Cannot assign requested address
SIOCSIFFLAGS: Cannot assign requested address
Sure enough, same results. Using 0.0.0.0 also fails, but substitute a
real IP address for the zero placeholder and we get:
# /sbin/ifconfig eth0:0 inet 192.168.0.210 up
# ifconfig
[...]
eth0:0 Link encap:Ethernet HWaddr 00:04:61:4b:d1:33
inet addr:192.168.0.210 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:16
[...]
It seems the EACCES error is incorrect and misleading, and the call should
instead return an error indicating that the address is invalid.
I'm assuming dhclient is calling ifconfig in this fashion in order to
create the virtual device, and if successful, is going to go back after
obtaining an IP address via DHCP and update the interface.
I gather some internals in ifconfig or the kernel changed.
-Tom
** Attachment added: "strace -ff -F -o /tmp/dhclient.strace dhclient eth0:0"
http://launchpadlibrarian.net/24607967/dhclient.strace.zip
--
dhclient fails for virtual interfaces (IP aliases)
https://bugs.launchpad.net/bugs/351378
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
