[Bug 732910] New: dhclient does not work with "ifup"
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c0 Summary: dhclient does not work with "ifup" Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: x86-64 OS/Version: SuSE Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: nrickert@ameritech.net QAContact: qa@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0 On reboot, there was no network (other than 127.0.0.1) I had set DHCLIENT_BIN to "dhclient Switching to NetworkManager got me a network. Then, switching DHCLIENT_BIN back to the default (empty string, implies dhcpcd), restored correct behavior. Here are some log messages from an unsuccessful boot: Nov 26 23:48:25 nwr2 dhclient: execve (/sbin/dhclient-script, ...): Exec format error Nov 26 23:48:26 nwr2 avahi-daemon[1284]: Registering new address record for fe80 ::21a:a0ff:fe20:4cdd on eth0.*. Nov 26 23:48:26 nwr2 ifup-dhcp: . The first of those probably points to the problem. Indeed, /sbin/dhclient-script is not appropriate for use with exec Reproducible: Always Steps to Reproduce: 1. 2. 3. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c1 Eduard Goiu <egoiu@fum.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |egoiu@fum.de --- Comment #1 from Eduard Goiu <egoiu@fum.de> 2011-12-05 09:38:16 UTC --- I confirm this bug too: Dec 5 10:32:08 911 dhclient: execve (/sbin/dhclient-script, ...): Exec format error Dec 5 10:33:47 911 dhclient: execve (/sbin/dhclient-script, ...): Exec format error Dec 5 10:35:32 911 dhclient: execve (/sbin/dhclient-script, ...): Exec format error -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c2 Martin Tessun <martin.tessun@die-tessuns.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.tessun@die-tessuns.d | |e --- Comment #2 from Martin Tessun <martin.tessun@die-tessuns.de> 2011-12-05 21:54:35 UTC --- I can confirm this. What happens is, that with systemd the file dhclient-script gets overwritten somehow with this content: tessun@uhura:~> sudo cat /sbin/dhclient-script redirecting to systemctl Reinstalling dhcp-client gets the original script back: tessun@uhura:~> sudo zypper in -f dhcp-client .. tessun@uhura:~> sudo cat /sbin/dhclient-script #!/bin/bash # .. It then works one time; after that it gets overwritten again. I just tried to set the file Read-only even for root. I will repotr, whether this works as a workaround. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c Andreas Jaeger <aj@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fcrozat@suse.com AssignedTo|bnc-team-screening@forge.pr |mt@suse.com |ovo.novell.com | Severity|Normal |Major -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c3 Marius Tomaschewski <mt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #3 from Marius Tomaschewski <mt@suse.com> 2011-12-07 19:35:15 UTC --- Huh? It gets overwritten? I'm usually using it dhclient+dhclient6 on my notebook (==12.1) and there it worked fine when I'm not wrong... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c4 --- Comment #4 from Martin Tessun <martin.tessun@die-tessuns.de> 2011-12-07 20:26:55 UTC --- Exactly. When using systemd and dhcp + dhcp6. It happens at every reboot. Don't know exactly whether this happens on startup or shutdown, but I will have a look at the timestamp the next time. Setting the file to read-only doesn't help. What I will try next is the following: 1. Restart the network (no booting) and check whether the file gets overwritten 2. Boot the system to check the timestamp, when exactly the file gets overwritten. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c5 --- Comment #5 from Frederic Crozat <fcrozat@suse.com> 2011-12-08 09:46:22 UTC --- and it doesn't happen with sysvinit ? looks strange, since systemd doesn't touch any file.. please try to boot with systemd.log_level=debug systemd.log_target=kmsg and attach dmesg output after the "replacement" occurs. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c6 --- Comment #6 from Neil Rickert <nrickert@ameritech.net> 2011-12-08 17:14:07 UTC --- This morning, I copied back a correct version of "/sbin/dhclient-script" (from another 12.1 system). I reconfigured the system to use "dhclient". I rebooted twice with sysvinit. No problem at all. Then I rebooted twice with systemd. No problem at all. Exactly what causes this is a puzzle. I tried changing some network settings in Yast, so that Yast would restart the network. No problem noticed. Based on file dates in "/etc/sysconfig/network", I think I began to notice the problem after I configured a USB wifi adapter for starting on hotplug. I rarely use that adapter, so most of the time it isn't plugged in. I was unable to recreate the dhclient problem. I'll leave my system configured for "dhclient", since I prefer that anyway. And I'll check on each reboot (typically twice a week) to see if "/sbin/dhclient-script" has been corrupted. Perhaps Martin Tessun will be able to track this down, since it seems to happen more frequently for him. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c7 --- Comment #7 from Martin Tessun <martin.tessun@die-tessuns.de> 2011-12-08 21:21:11 UTC --- Ok, here the first results of my investigation: 1. The file /sbin/dhclient-script gets corrupted during shutdown only. 2. It never gets overwritten again, when it was overwritten with this content. 3. If I hard-reset the machin (so not executing any shutdown-script) /sbin/dhclient-script stays intact. I'l try to figure out, what exactly is causing this behaviour. I have at least two systems with this error. (One with Wireless, the other with a "standard" 1GB-ethernet-interface. As the text in the file is "redirecting to systemctl", I am sure, that this only happens with systemd, not with sysvinit. As I upgraded from 11.4 via zypper, it may be related to the update itself, as Neil states, that it doesn't happen again after "reconfiguration" of the network. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c8 --- Comment #8 from Martin Tessun <martin.tessun@die-tessuns.de> 2011-12-08 23:36:35 UTC --- OK. Inspired by the Statement of Neil I did the following: Reconfiguration of the Network Interface using yast: 1. Delete Config for eth0. 2. Save 3. Reconfigure eth0 4. Save ==> /sbin/dhclient-script got overwritten during this phase 5. Copy back original dhclient-script 6. Repeat 1. to 4. 7. Reboot (init 6) ==> All works fine now. I looked at the files that got changed during this process in /etc: 35740659 4 -rw-r--r-- 1 root root 714 Dec 9 00:24 /etc/sysctl.conf 100800138 4 -rw-r--r-- 1 root root 666 Dec 9 00:24 /etc/init.d/.depend.stop 100800139 4 -rw-r--r-- 1 root root 878 Dec 9 00:24 /etc/init.d/.depend.start 100800176 4 -rw-r--r-- 1 root root 461 Dec 9 00:24 /etc/init.d/.depend.halt 100800177 4 -rw-r--r-- 1 root root 639 Dec 9 00:24 /etc/init.d/.depend.boot 67175257 4 -rw-r--r-- 1 root root 990 Dec 9 00:24 /etc/udev/rules.d/70-persistent-net.rules 33555123 4 -rw-r--r-- 1 root root 938 Dec 9 00:24 /etc/resolv.conf 67170629 4 drwxr-xr-x 6 root root 4096 Dec 9 00:24 /etc/sysconfig/network 68356172 12 -rw-r--r-- 1 root root 9805 Dec 9 00:24 /etc/sysconfig/network/dhcp 67170803 4 -rw-r--r-- 1 root root 201 Dec 9 00:24 /etc/sysconfig/network/ifcfg-eth0 33555167 36 -rw-r--r-- 1 root root 36548 Dec 9 00:24 /etc/sysconfig/SuSEfirewall2 34574389 4 -rw-r--r-- 1 root root 1259 Dec 9 00:24 /etc/sysconfig/windowmanager 35639763 4 -rw-r--r-- 1 root root 198 Dec 9 00:24 /etc/samba/dhcp.conf I will do mor investigation tomorrow. Today it is too late for me... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c9 --- Comment #9 from Martin Tessun <martin.tessun@die-tessuns.de> 2011-12-09 20:16:09 UTC --- OK interestingly it happend again today. But this time it happend during the boot process itself. To me it looks like a racing condition somehow. I will investigate with default debug outputs (unfortunately I hadn't enabled them today) and will report back. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c10 --- Comment #10 from Martin Tessun <martin.tessun@die-tessuns.de> 2011-12-09 22:29:41 UTC --- Created an attachment (id=466831) --> (http://bugzilla.novell.com/attachment.cgi?id=466831) systemd-Debug-Output from boot while overwriting /sbin/dhclinet-script Finally I got it. I booted the machine, with debugging enabled and the file got overwritten during boot. I attached the dmesg-output from that boot, although I didn't find anythin really interesting in there. Regards, Martin -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c11 --- Comment #11 from Marius Tomaschewski <mt@suse.com> 2011-12-15 13:05:33 UTC --- Ahm... the order in which systemd starts the services (network before boot.local [well, ok...] and network-remotefs before network finished, ..) is interessting... But I don't see anything special too... Do you have also an ifcfg-file for the wireless interface? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c12 --- Comment #12 from Marius Tomaschewski <mt@suse.com> 2011-12-15 14:19:23 UTC --- More questions: Is one of you using NetworkManager? When yes, how is the ESSID? Can you attach the corrupted dhclient-script (review with hexdump first, so there are no passwords, ... attach it with private flag set)? Perhaps the "new" content says something about the reason... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c13 Ludwig Nussel <lnussel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |nrickert@ameritech.net --- Comment #13 from Ludwig Nussel <lnussel@suse.com> 2011-12-15 16:11:59 CET --- To find out who is overwriting the file, install auditd and append the following two lines to /etc/audit/audit.rules. -e 1 -w /sbin/dhclient-script -p rwxa enable and start auditd, then try again to reproduce. Watch /var/log/audit/audit.log -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c14 Neil Rickert <nrickert@ameritech.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|nrickert@ameritech.net | --- Comment #14 from Neil Rickert <nrickert@ameritech.net> 2011-12-15 16:29:09 UTC --- Created an attachment (id=467706) --> (http://bugzilla.novell.com/attachment.cgi?id=467706) The file "/sbin/dhclient-script" after being corrupted. Here's the "ls" output on the file: -rwxr-x--- 1 root root 25 Dec 15 05:33 /sbin/dhclient-script Here's an entry from my logs (remote logging from my router: Dec 15 05:33:33 NBG334W msg="DHCP server assigns 192.168.254.101 to nwr2" devID="897778" cat="System Maintenance" I last booted this system on Dec 13th, at 20:05 (I'm looking at the date of "/proc/1" to get that time. It booted fine, so dhclient-script was fine at that point. So that log entry should have been from using dhclient to renew the lease. It seems pretty likely that dhclient-script is being corrupted during lease renewal. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c15 --- Comment #15 from Martin Tessun <martin.tessun@die-tessuns.de> 2011-12-15 20:18:25 UTC --- So first of all: I don't use Wireless. I only have "standard" Ethernet. Interestingly it does not happen on every computer I upgraded. I will install auditd and try to monitor, what gets this file overwritten. Currently I really have no clue. Regards, Martin -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c16 --- Comment #16 from Neil Rickert <nrickert@ameritech.net> 2011-12-16 23:02:48 UTC --- Another instance of the same thing: % ls -l /sbin/dhclient-script -rwxr-x--- 1 root root 25 Dec 16 12:44 /sbin/dhclient-script and the log entry for DHCP lease renewal: Dec 16 12:43:59 NBG334W msg="DHCP server assigns 192.168.254.101 to nwr2" devID="897778" cat="System Maintenance" On that slight time difference, note that the log time comes from the router, which is adjusting its time once per day. The file time comes from the computer, where I adjust the time when I remember to. It was 7 seconds fast. So it looks as if the file is being overwritten on every lease renewal here. (I won't report future instances, unless there's a change in pattern). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c17 --- Comment #17 from Martin Tessun <martin.tessun@die-tessuns.de> 2011-12-16 23:04:23 UTC --- Very strange. Since I enabled the auditing it never happend again (till now). I will of course report back, as soon as it happens again (and I have the audit.log) Regards, Martin -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c18 --- Comment #18 from Martin Tessun <martin.tessun@die-tessuns.de> 2011-12-18 21:13:48 UTC --- Created an attachment (id=467977) --> (http://bugzilla.novell.com/attachment.cgi?id=467977) audit.log from a corruption (happend on Dec. 16th 00:04) Now I have a corruption. I added the audit.log from that period. Hope this helps to track it down somehow. If it happens again I will upload more audit.log-Files as necessary. Regards, Martin -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c19 Marius Tomaschewski <mt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |werner@suse.com --- Comment #19 from Marius Tomaschewski <mt@suse.com> 2011-12-19 16:27:07 UTC --- Martin, Neil, thanks for your comments! Nothing new so far, just some summary comments: The content of the dhclient-script after corruption is "redirecting to systemctl". This string is from the systemd redirection code used in /etc/rc.status: echo "redirecting to systemctl" >/dev/stderr that is used (sourced) by any /etc/init.d script. The dhclient itself executes "/etc/init.d/syslog reload" when the hostname were changed. It also executes netconfig to update system settings and netconfig restarts ntp (named & ypbind in some cases too). Further, it executes ifup foo0 -o dhcp that executes e.g. the if-up.d scripts, where further services may get restarted (e,g. nmb). Last but not least, it seems to happen while lease renew... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c20 --- Comment #20 from Neil Rickert <nrickert@ameritech.net> 2011-12-19 23:25:43 UTC --- Thanks, Marius, for that run down. All along this has looked to me like a typo somewhere causing output to accidentally be redirect to "/sbin/dhclient-script". From your comments, it should presumably be an inappropriate redirection of stderr. Looking through your description of events, and checking the appropriate scripts, I was unable to find anything. What invokes "dhclient-script"? I haven't managed to find from where that is called. I have temporarily set DHCLIENT_DEBUG to "yes" in "/etc/sysconfig//network/dhcp" to see if that gives any useful information on the next lease renewal. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c21 --- Comment #21 from Neil Rickert <nrickert@ameritech.net> 2011-12-20 00:30:17 UTC --- Here's an interesting data point. I have had a dhcp lease renewal after setting DHCLIENT_DEBUG="yes" and that went fine. The dhclient-script file was not corrupted. The first conclusion - turning on DHCLIENT_DEBUG is a workaround for this problem. Second observation - the first line logged in the debug log /var/log/dhclient-script.eth0.log is the line "redirecting to systemctl" The way the debugging works, is that it redirects stderr to the log file. This tells me that stderr is redirected to "/sbin/dhclient-script" before "dhclient-script" is called. I checked the script, and I could not find any redirection occuring in that script itself before the debug action. So turning on debug protects the script by redirecting stderr to somewhere that won't cause the file to be corrupted. I still have not found what invokes "dhclient-script". Perhaps "dhclient" itself does that, in which case somebody needs to check the source code for dhclient. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c22 --- Comment #22 from Marius Tomaschewski <mt@suse.com> 2011-12-20 13:57:28 UTC --- The dhclient binary executes the dhclient-script. This means, we have to search in the dhcp sources and I guess more, in the patches for the binary. Maybe there is a collision between dhcp-4.2.2-close-on-exec.diff and dhcp-4.1.1-dhclient-exec-filedes.diff? I'm currently reinstalling my workstation -- I'll look into this tomorrow... [when I get 12.1 running properly ;-)] -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c23 --- Comment #23 from Neil Rickert <nrickert@ameritech.net> 2011-12-20 19:22:30 UTC --- As an additional check, I edited "/sbin/dhclient-script", making the following change: @@ -17,6 +17,9 @@ ## test "x$reason" = x -o "x$interface" = x && exit 1 +#### debugging lines added for testing #### +( date ; lsof -p $$ ) >> /var/log/dhclient-script.eth0.log 2>&1 +#### end of debugging lines #### # # source sysconfig functions # The aim is to show the file descriptors. I'll post back (or attach) the results if they look useful. I recently rebooted, so I don't expect a lease renewal until tomorrow evening. On checking my laptop, which uses NetworkManager, I see that "dhclient" is called with the "-sf" option to specify a different script file. That's probably why NetworkManager is not affected by this bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c24 Phil Bertin <philippe.bertin@telenet.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |philippe.bertin@telenet.be Platform|x86-64 |i586 --- Comment #24 from Phil Bertin <philippe.bertin@telenet.be> 2011-12-21 20:57:42 UTC --- I am also, like apparently most (if not all) of us, NOT using NetworkManager. My dhclient-script file was also corrupted. Based on the previous post, I then thought to be smart by specifying "another" script (being : a copy of the good original) dhclient-script but then specifying that other script on the command-line, like apparently done by NetworkManager. So with that original dhclient-script file copied (preserving file mode flags) onto the filename dhclient-script.copy, I killed the original dhclient process, and modified the commandline command into /sbin/dhclient6 -6 -cf /var/lib/dhcp6/dhclient6.eth1.conf -lf /var/lib/dhcp6/dhclient6.eth1.lease -pf /var/run/dhclient6.eth1.pid -sf /sbin/dhclient-script.copy -q eth1 (notice my option "-sf"). In no time, dhclient-script.copy was corrupt too. The culprit so HAS to be the /sbin/dhclient6. What puzzles me, is that once the IPv6 (in my case) address is given by my dhcp6 server, even with this corrupt script, the IPv6 address is still renewed ! (I have short lifetimes, so I'd notice the IPv6 address being lost within a minute). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c25 --- Comment #25 from Martin Tessun <martin.tessun@die-tessuns.de> 2011-12-21 22:01:55 UTC --- What I think might work as a workaround, is setting the file read-only: chattr +i /sbin/dhclient-script Now even root might not change the file any more. You can remove this lock with chattr -i /sbin/dhclient-script If someone wants it, I have more audit.logs monitoring access to /sbin/dhclient-script even during corruption. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c26 --- Comment #26 from Neil Rickert <nrickert@ameritech.net> 2011-12-22 00:19:28 UTC --- said by Phil Bertin:
The culprit so HAS to be the /sbin/dhclient6.
We cannot rule out a kernel bug. Unless I am misreading, there is a kernel bug there somewhere. I added some debugging, as mentioned in comment 23. So when the lease renewed this afternoon, I check for the debug data. It was nowhere to be seen. As I read dhclient-script: my debugging data should be appended to the end of the log file. then some asterisks and a timestamp should be appended (around line 40 of dhclient-script). And then stderr from running the script should be appended to the log file (the "exec >>2" statement a few lines down). But when I look at the logfile, the first thing I see is that "redirected to systemctl" line. So the output from the last of those steps has truncated the log file, instead of appending to the end. I have not yet tested. I am guessing that: echo string > /dev/stderr is what is truncating the log file. I would think that is a kernel bug. "/dev/stderr" is a symlink to "/dev/fd/2, and file descriptor 2 is open for append. I admittedly am not certain of the definition of "/dev/fd/n" but it seems strange for that to be able to truncate a file when the file descriptor is open for append. If that's not a kernel bug, then the line in "/etc/rc.status" that writes to "/dev/stderr" should be using ">>" rather than ">". I'm not ruling out a bug in dhclient. There seems be room here for multiple bugs. It's possible that there's a bug in "dhclient" that has been there for a long time, but not actually triggered until that "/etc/rc.status" line wrote to stderr with the move to systemd. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c27 --- Comment #27 from Neil Rickert <nrickert@ameritech.net> 2011-12-22 05:37:43 UTC --- Created an attachment (id=468604) --> (http://bugzilla.novell.com/attachment.cgi?id=468604) A shell script for testing redirect to "/dev/stderr According to the documentation that I could find (with google search), opening "/dev/fd/n" is supposed to be equivalent to dup() of file descriptor n. If file descriptor n is opened for append, then a dup would still be appending. The behavior I am seeing for /dev/stderr (which is a symlink to /dev/fd/2 ) does not act that way. Running the "xtest" script on a solaris 8 system gives the expected results. Running on openSUSE 12.1 gives what I believe to be the wrong results, in that it truncates the file instead of appending. I also tested on a debian system Linux turing 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011 x86_64 GNU/Linux and that also gave the wrong results (the same results as I am seeing on 12.1) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c28 --- Comment #28 from Neil Rickert <nrickert@ameritech.net> 2011-12-22 05:44:19 UTC --- Created an attachment (id=468605) --> (http://bugzilla.novell.com/attachment.cgi?id=468605) suggested patch (/usr/bin/patch) for "/etc/rc.status". I'm attaching a suggested patch to "/etc/rc.status" Note that this does not fix the "dhclient" bug, though it might ameliorate it (not tested). As discussed in comments #26 and #27, I believe the implementation of "/dev/stderr" is broken. The suggested patch changes "rc.status" so that it does not depend on "/dev/stderr". -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c29 Marius Tomaschewski <mt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |werner@suse.com --- Comment #29 from Marius Tomaschewski <mt@suse.com> 2011-12-22 09:23:27 UTC --- Werner, see above comments -- what do you say about? (In reply to comment #25) Martin, yes, please attach the audit logs where the corruption happens. (In reply to comment #26)
I'm not ruling out a bug in dhclient. There seems be room here for multiple bugs. It's possible that there's a bug in "dhclient" that has been there for a long time, but not actually triggered until that "/etc/rc.status" line wrote to stderr with the move to systemd.
Yes, I do not rule out any bug in whatever, kernel, dhclient or one of its patches. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c30 --- Comment #30 from Phil Bertin <philippe.bertin@telenet.be> 2011-12-22 12:46:08 UTC --- I think I found the error. And it's not in dhclient itself, but in dhclient-script. This can explain why using NetworkManager (i.e. using some other script) doesn't show this behaviour, and using the "traditional" method using dhclient-script does. It also explains why the DEBUG workaround works... If one looks into line 37 of dhclient-script, there's the check if [ "$DEBUG" = yes ]; then In that check, right before the fi, I inserted else exec 2>>/tmp/test Guess what : the file showed the "redirecting to systemctl" message. And moreover, the dhclient-script file remained untouched. So one could just as well set there exec 2>>/dev/null If now someone can confirm the fix works for him, I think the fix is found :) Ph B -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c31 --- Comment #31 from Ludwig Nussel <lnussel@suse.com> 2011-12-22 13:57:21 CET --- that's still not a fix though. I guess something closes fd 2 and then dhclient-script is opened on that fd. Whatever program closes fd2 must make sure to dup it to /dev/null to avoid this kind of error. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c32 --- Comment #32 from Neil Rickert <nrickert@ameritech.net> 2011-12-22 13:32:37 UTC ---
I think I found the error. (from comment 30) No, that's not the error. It is a temporary workaround.
Sorry, but it will be another day before I get the "lsof" output mentioned in comment 23. My first attempt at that failed, as reported in comment 26. Since then, I have rebooted (for entirely unrelated reasons). I do have the "lsof" output from the initial run of dhclient (acquiring the lease), but I don't yet have it for a lease renewal. For aquiring a lease, fd 2 is open to "/dev/null", which ought to be fine. But then I was never having dhclient problems on the initial lease. They only showed up for me on renewals. When I do get the "lsof" output, here is what I am expecting to see: Either: fd 2 is open for read only to the script file, or: fd 2 is not open at all (was inadvertantly closed). If my guess is right, then this is all related to what I have been calling a kernel bug in comments 26-28. The reason for this expectation: It is inconceivable to me that the "dhclient" binary would open "dhclient-script" for append - that's not the kind of mistake that programmers would make. It cannot be opening it for write, as that would truncate the file even if nothing is written to stderr. So it looks to me as if there is something funky about the implementation of "/dev/fd/n" which allows echo string > /dev/stderr to write to the file even when the stderr file descriptor is not open for output. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c33 --- Comment #33 from Phil Bertin <philippe.bertin@telenet.be> 2011-12-22 18:09:15 UTC --- Created an attachment (id=468726) --> (http://bugzilla.novell.com/attachment.cgi?id=468726) lsof outputs of a startup on my system --> erroneous situation Have a look between the action BOUND6 and DEPREF6. At DEPREF6, the error occured. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c34 --- Comment #34 from Phil Bertin <philippe.bertin@telenet.be> 2011-12-22 18:19:26 UTC --- (Sorry for this extra entry, I struggled with the web page). So I hereby attached the output of my system's startup. It seems to confirm Neil's expectations : as far as I understand it's output, dhclient-script's lsof in the beginning indeed is open for reading on fd 2. More precisely : have a look at DEPREF6, where it seems to happen. I notice that at renewal time dhclient-script isn't called any more, but the IPv6 address keeps being valid... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c35 --- Comment #35 from Neil Rickert <nrickert@ameritech.net> 2011-12-22 23:04:05 UTC --- I'm not using IPv6 here, so I'm not quite familiar with what is there. But it is showing the sort of thing that I expected. fd=2 is open for read to dhclient-script. the echo to "/dev/stderr" somehow manages to write to it, even though it is only supposed to be open for read. The effect is that dhclient-script becomes corrupted. The bug in dhclient, as suggested by Ludwig and Marius, is that fd=2 is probably being closed inappropriately. So the next thing opened becomes connected to fd=2. That's compounded by the funky implementation of "/dev/fd/2" (same thing as "/dev/stderr"). The implementation is apparently finding the file connected with that file descriptor and reopening it with write. My understanding is that it should only do a dup() of the file descriptor which would have left it read-only. In my opinion, that one is a kernel bug. And then we have "/etc/rc.status" doing echo string >/dev/stderr instead of echo string >&2 and that triggers the kernel bug. Turning on DEBUG for dhcp reassigns fd=2, and thus avoids the whole problem. It is possible that the bug in dhclient is an old one, that has never been triggered before, because the other complicating factors also have to be present before it causes problems. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c36 --- Comment #36 from Neil Rickert <nrickert@ameritech.net> 2011-12-23 16:38:34 UTC --- Created an attachment (id=468864) --> (http://bugzilla.novell.com/attachment.cgi?id=468864) "lsof" output from dhclient-script This is the file where I log "lsof" output from dhclient-script. The first two entries, dated a few seconds apart, are from the initial acquiring of a lease. They look fine. The third (last) entry, dated "Fri Dec 23 09:22:38 CST 2011", is from a lease renewal. As you can see, fd=2 is open for read to "/sbin/dhclient-script". This is consistent with the "lsof" output provided by Phil. What I wrote in comment 35 still applies. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c37 --- Comment #37 from Phil Bertin <philippe.bertin@telenet.be> 2011-12-24 14:54:04 UTC --- from dhclient.c (lines 3280 and following) pid = fork (); if (pid < 0) { log_error ("fork: %m"); wstatus = 0; } else if (pid) { --> parent do { wpid = wait (&wstatus); } while (wpid != pid && wpid > 0); if (wpid < 0) { log_error ("wait: %m"); wstatus = 0; } } else { /* We don't want to pass an open file descriptor for * dhclient.leases when executing dhclient-script. */ --> child if (leaseFile != NULL) fclose(leaseFile); execve (scriptName, argv, envp); log_error ("execve (%s, ...): %m", scriptName); exit (0); } There is "an" error in the execve- call, as the "execve ..." message wouldn't otherwise be reflected in the logs. This means that something has gone wrong in that call, as it wouldn't otherwise return. Regardless of the lsof- outputs we've seen, aren't the open files in this returned child process possibly differently setup (again) ? In any case, the call to log_error writes to fd 2 ! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c38 --- Comment #38 from Neil Rickert <nrickert@ameritech.net> 2011-12-24 17:29:40 UTC ---
There is "an" error in the execve- call, as the "execve ..." message wouldn't otherwise be reflected in the logs.
The only logs I am seeing of execve problems, are after dhclient-script has been corrupted. Here's my most recent such message: Dec 18 08:30:24 nwr2 dhclient: execve (/sbin/dhclient-script, ...): Exec format error I have rebooted and had lease renewals since then, with no such messages. But that's DEBUG turned on, which acts as a workaround to prevent corruption. Hmm, there's a thought. I expect the next lease renewal this evening. So I will deliberately sabotage dhclient-script to force that "log_error" call. If the error is logged, then stderr is still open at that point in the child process, so we are looking for a "close on exec" problem. If the error is not logged, then stderr has already been inappropriately closed. Looking at the main dhclient process with "lsof", the lease file is open with fd=4 Hmm, maybe it's just me. But that "fclose(leaseFile)" looks like poor logic to me. I think it is better to use close(fileno(leaseFile)); If there is unwritten buffered data, and you fclose() in the child process it will be written then and later written again in the parent process. Just closing the file descriptor should avoid that. Perhaps an fflush() was already done, so it won't matter. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c39 --- Comment #39 from Martin Tessun <martin.tessun@die-tessuns.de> 2011-12-24 22:51:20 UTC --- Created an attachment (id=468908) --> (http://bugzilla.novell.com/attachment.cgi?id=468908) Again an audit.log from the corruption I've attached the relevant audit.log. The corruption happens between the two "cp"s. Regards, Martin -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c40 --- Comment #40 from Phil Bertin <philippe.bertin@telenet.be> 2011-12-26 13:38:14 UTC --- I discovered an interesting pattern from the 2 audit logs that were attached before by Martin (see comments 18 and 39). Unfortunately, even if the patterns are interesting, and even if (to my near-conviction) they must be related to the bug we're tracking, I don't understand all of audit's output. But here are my observations : Have a look at the - the first trail's lines 357 till 365 inclusive == events 458 till 460 inclusive (1) - the second trails's lines 68 till 79 inclusive == events 147 till 150 inclusive (2) My observations : - in BOTH cases the process has /dev/stderr pointing at the same inode as ... dhclient-script (--> !!!) - BOTH occurrences result in failing dhclient- calls afterwards (see the lines containing "success=no"- lines thereafter), - those /dev/stderr- lines NEVER occur elsewhere I'm not familiar enough to fully understand these logs and what's happening and why it is happening (even though following this bug's tracking is a very interesting and learning experience !), but I'm sure there must be people around who do understand (and who can explain). Kind regards, Phil -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c41 --- Comment #41 from Neil Rickert <nrickert@ameritech.net> 2011-12-26 16:49:46 UTC --- Responding to Phil Berlin in comment 40: That those inodes are the same is a symptom of the underlying problem. Let me repeat what I see as the probable bug(s) here: 1: It seems that "dhclient" is inappropriately closing file descriptor 2. If you are examing the source code, this would be happening in the child process after the fork(), since the parent process continues to have fd=2 open to "/dev/null" (based on "lsof" output). When the bash interpreter opens "/sbin/dhclient-script" to run the commands, it is presumably getting file descriptor 2 for that, so that stderr is now a read-only file descriptor to "dhclient-script". This is compounded by what I see as a kernel bug. And that is, writing to "/dev/stderr" (which is really "/dev/fd/2") does actually write to the file, even though fd=2 was a read-only file descriptor. I would have expected that either the attempt to open "/dev/stderr" for writing would fail, or the attempt to actually write to "/dev/stderr" would fail in these circumstances. I don't know enough about how "/dev/fd/n" was supposed to be implemented to be certain that this is a bug, but it sure looks wrong to me. I'll add another comment with my suggestions on what the opensuse team should do with this bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c42 --- Comment #42 from Neil Rickert <nrickert@ameritech.net> 2011-12-26 16:55:07 UTC --- My suggestions on handling this bug: 1: Send out a patch to "dhclient-bin" which adds exec 2>/dev/null near the top. This should be documented as a temporary workaround for a bug in "dhclient". Perhaps a similar change should be made for the script used when "dhclient" is invoked from NetworkManager. 2: Report the dhclient bug upstream to ISC, for them to fix. 3: Report the kernel behavior upstream as a possible kernel bug. 4: As suggested in comment 28, stop using "/dev/stderr" in places such as "/etc/rc.status", as long as the implementation of "/dev/fd/n" is as at present. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c43 Marius Tomaschewski <mt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|werner@suse.com | --- Comment #43 from Marius Tomaschewski <mt@suse.com> 2012-01-04 10:08:49 UTC --- I think I've found the problem -- it were caused by the close-on-exec patch setting it also on stderr. As soon as rebuilt, you'll find the test package at: http://download.opensuse.org/repositories/home:/mtomaschewski:/branches:/ope... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c44 Marius Tomaschewski <mt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |nrickert@ameritech.net --- Comment #44 from Marius Tomaschewski <mt@suse.com> 2012-01-04 17:55:29 UTC --- Neil, could you test the dhclient from above repo? There is also a systemd update (already relased) and a sysconfig package (in the above repo), that contains a corresponding change. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c45 --- Comment #45 from Neil Rickert <nrickert@ameritech.net> 2012-01-04 19:28:02 UTC --- Testing is underway. I installed the test version from your repo. I removed the debug option which served as workaround. I also modified the dhclient-script as before, so that I can log "lsof" output. I then rebooted, to make sure that I am running the updated version. So far, so good. But the lease renewal is not till tomorrow afternoon some time, and that's the important test. I'll report back after that time. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c46 Neil Rickert <nrickert@ameritech.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|nrickert@ameritech.net | --- Comment #46 from Neil Rickert <nrickert@ameritech.net> 2012-01-05 22:56:44 UTC --- Created an attachment (id=469982) --> (http://bugzilla.novell.com/attachment.cgi?id=469982) "lsof" output from the new test dhclient I have now seen a lease renewal. Everthing looks good. The attachment includes "lsof" from the script, both for the initial start of "dhclient" on the recent reboot and for the lease renewal. file descriptor assignments look good. The script "dhclient-script" remains intact, no corruption seen. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c47 --- Comment #47 from Neil Rickert <nrickert@ameritech.net> 2012-01-10 05:23:03 UTC --- Running "apper" updated that test dhclient. My last reboot and lease renewal were with the updated test version. It is still working fine. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c48 Marius Tomaschewski <mt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |maintenance@opensuse.org --- Comment #48 from Marius Tomaschewski <mt@suse.com> 2012-01-10 09:27:24 UTC --- OK, thanks for all your hard work on this issue! Mr. Maintenance, can I get a SWAMPID for this and bug 739696? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c50 --- Comment #50 from Bernhard Wiedemann <bwiedemann@suse.com> 2012-01-10 11:00:37 CET --- This is an autogenerated message for OBS integration: This bug (732910) was mentioned in https://build.opensuse.org/request/show/99573 12.1 / dhcp -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=732910 https://bugzilla.novell.com/show_bug.cgi?id=732910#c51 Marius Tomaschewski <mt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED InfoProvider|maintenance@opensuse.org | Resolution| |FIXED --- Comment #51 from Marius Tomaschewski <mt@suse.com> 2012-01-10 14:08:10 UTC --- I've been told, there are no SWAMPIDs for 12.1 any more.... Submit request is there (comment 50) and contains also fixes for lease file parsing issues (bug 739696) I've noticed during the tests of this bug. Closing it as this bug is a 12.1 only issue. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com