dhcpcd 5.0.1 and segfault

em · 2009-05-10 15:03:58

Unfortunately new version of dhcpcd not working for me.

# dhcpcd eth0
dhcpcd: open_control: Connection refused
dhcpcd: version 5.0.1 starting
Segmentation fault

/var/log/messages.log:

May 10 16:45:58 shell dhcpcd: version 5.0.1 starting
May 10 16:45:58 shell kernel: dhcpcd[22564] segfault at 0 ip 08053cad sp bf9fe470 error 4 in dhcpcd[8048000+11000]

Of course there is no problem with dhcpcd 4.0.12.
Any clue ?

em · 2009-05-10 20:31:12

OK, Roy just fixed this problem: http://roy.marples.name/projects/dhcpcd … 42d26fc5f6 !

ckristi · 2009-05-11 05:06:37

Why in the world this happened? The package was in testing (as I saw it was) and noone noticed? Pf.. I almost had to connect the monitor and a keyboard to my headless gateway because of this. Seriously now, this is an important package for a computer directly facing an ISP that gives IP only by DHCP and it's not a thing very easy tolerable (not having a dhcp client working). Luckily I had the old package in cache, otherwise the problem would have been BIG.

Allan · 2009-05-11 05:20:21

File a bug report asking for it to be patched. It seems the patch is a big hack...

ckristi · 2009-05-11 06:33:50

I filed a bug report here. I think, meanwhile, the package should be moved back to testing and downgraded to the latest 4.x version.

The bug report may be found here:
http://bugs.archlinux.org/task/14675?project=1

Last edited by ckristi (2009-05-11 06:34:41)

pressh · 2009-05-11 06:50:05

Just uploaded 5.0.2-1 with the above indicated patch to testing.

ckristi · 2009-05-11 07:56:37

But still 5.0.1 should be replaced with the previous version while 5.0.2 is in testing. Otherwise the problem isn't solved yet, and more people would have troubles before 5.0.2 hits extra.

Oh, I forgot (my manners flew)... thanks for being so quick in solving this issue.

Last edited by ckristi (2009-05-11 07:57:54)

pressh · 2009-05-11 08:04:56

I can't bring 4.* back in. It would need a rebuild with the force flag (or modification of the original pkg.tar.gz). Both would require a signoff thread just like the 5.0.2 package so it doesn't improve things.
I asked for a quick signoff so let's hope it will be.

em · 2009-05-11 09:26:48

dhcpcd 5.0.3 released, so patch is no more needed.

rsmarples · 2009-05-12 15:01:50

ckristi wrote:

Why in the world this happened?

None of my dhcpcd testers use dhcpcd + Linux + PPP/TUN at the same time.
But to be fair, only the last experimental release had the code causing the error.

For the technically minded, this issue was caused by moving OS specific calls to work out what interfaces are present with what hardware addresses to getifaddrs(3) and I did the bulk of my PPP interaction testing on Linux pre that change and then testing PPP interaction on NetBSD after that change.

Seriously now, this is an important package for a computer directly facing an ISP that gives IP only by DHCP and it's not a thing very easy tolerable (not having a dhcp client working). Luckily I had the old package in cache, otherwise the problem would have been BIG.

Always have a working boot CD handy just for this reason. But there are many more critical packages than dhcpcd .....

ckristi · 2009-05-13 02:36:10

@rsmarples
1. Who said anything about PPP/TUN. My gateway simply gets IPs by DHCP from my providers (that's their chosing, not mine) and nothing more.
2. Arch being a rolling release you may have a working boot CD from 2006/2007 which might not have an older package that's still compatible with the rest of the packages installed at this moment (dependency hell). And I was never an adept to install lots of older packages on my gateway... it might get to a point that you're feeling you're downgrading the whole beast.
3. What if the service would really be a mission critical one (where mission critical=your boss is goin' to kill you if it doesn't work for more than 5 seconds)?

dschauer · 2009-05-13 02:55:28

@ckristi

Well, I don't use PPP/TUN and I ran into this problem as well. In fact, dhcpcd segfaulted on my Dell workstatiion where I work and caused me some downtime as I'd updated and rebooted it from home which I often do.

Since I don't clear my package cache I just rolled back when I went into the office today. I've had issues now and then with other package uprades on arch so I don't delete my package cache any more.

Overall Arch has been very stable for me despite being a rolling release.

As far as mission critical, Archlinux is your choice. If it fails on you in your workplace during a critical time, the Archlinux devs are not to blame, you are for choosing Archlinux.

That being said, I use Archlinux in critical systems in my workplace and take full responsibility for my choice to use it.

In the interim you can enable testing, sync pacman, upgrade dhcpcd, disable pacman, and sync pacman again.

Last edited by dschauer (2009-05-13 04:04:46)

pressh · 2009-05-13 07:26:58

@ckristi
dhcpcd5 had been in testing for ~5 days if I remember correctly. None of the devs who tested it had any problems with getting an ip via dhcpcd. Also no of the useres using the testing repo as there had not been any bug report. As Roy indicated it is just not possible to test every situation/use case/hardware combination one may have.

About the age of your live cd, it shouldn't matter if you are still able to connect to the internet with it. Download what you have, either an old package from some repo or just the source and PKGBUILD so you can compile your own, chroot into your arch installation, and get it downgraded. Did I mention you always should test upgrades on a machine which are not mission critical for your company, and never ever update a mission critical machine when it is about to perform an important task.

ckristi · 2009-05-13 09:14:21

@pressh
I didn't blame any of the developers in my posting. I was just arguing with rsmarples point of view. My home gateway is nothing but an ordinary machine, with ordinary hardware (2x100Mbit Realteks + 1Gigabit from Marvell). Obviously I've managed to solve my problems and know ways around them. Also.. my workstations have different configurations, and usually different type of hardware (more modern). So a test that would work on a non critical machine would possibly fail me on the gateway. At the moment I'll keep using the 4.x release from my cache, until 5.0.2/3 hits extra. But in case I didn't have the cached package the problem would have been quiet big (leaving me without Internet connections). Anyway, my point is that I did not want to argue with the developers, just with rsmarples ideea of using such an old package from the installation CD. Again, I'm pleased with the Arch developers work and in the past 6 months (since this distro gained acces to my gateway) I never had such a great problem. I really like Arch. Of course, this does not mean there's no room for improvement. ;-)

@dschauer: well... I hope noone misunderstood me... when I say "your boss is goin' to kill you..", I really meant "your boss is goin' to kill me..". I am fully capable of assuming responsability.

Last edited by ckristi (2009-05-13 09:15:41)

iphitus · 2009-05-13 09:41:30

ckristi: The package for Arch was tested before being moved to core.

- I signed it off
- Ronald signed it off
- Eric signed it off

I know I certainly don't have anything fancy. A Realtek/Ralink (I forget) ethernet card and ipw2100 wireless. I'm sure the others dont have anything exotic. It worked for all of us, and additionally, no bugs were reported during its stay in [testing]. Hence it was moved. It happens sometimes, bugs slip through, it's just part of how Arch works.

Given how often dhcpcd is released, the last version was _probably_ still in your package cache, unless you clear it completely and frequently. Further, if you're rolling out updates live on a mission critical system without testing yourself beforehand, you deserve whatever the boss dishes out.

James

ckristi · 2009-05-13 10:08:13

) You're right iphitus about the boss part. I prefer Slackware for systems I remotely manage, it rarely failed me because of updates. Arch I love precisely for the ease of keep certain programs (like postfix) up to date. That's why it managed to be installed on my gateway. I understand your hard work, and I do understand you cannot possibly test every situation. But Arch has a great community and it can help test those unpredictable situations. But for these, a testing team should be formed. It's obvious some dozens of testing persons would be more thorough than 5-6 developers.
I really would like to volunteer for such a testing team.

P.S.: I know there's a testing repo... but people may choose or not to use it. Being part of a test team would motivate the people to be a little more proactive.

Last edited by ckristi (2009-05-13 10:10:42)

b9anders · 2009-05-13 22:21:33

It didn't work for me with core or testing packages either. I just http://arm.nrk.cc/ the package to the 4.*.* version. No need for rebuilding or forcing the upgrade. Just adding the package to the ignore group in pacman.conf and things are working smoothly again.

rsmarples · 2009-05-14 00:55:01

ckristi wrote:

@rsmarples
1. Who said anything about PPP/TUN. My gateway simply gets IPs by DHCP from my providers (that's their chosing, not mine) and nothing more.

OK. I have 6 computers here. I run various OS's and CPU types. Since I made the code change in question none of these picked up an error during development. The only machine that was able to reproduce the error was running Gentoo Linux i386, and then only when I initiated a PPP or TUN device. TAP worked fine as did bridging, bonding etc. So that's a very specific case from my perspective.

I'm very sorry that I with my various testing platforms and the various NetBSD, FreeBSD, Linux embedded and Gentoo users who have been testing dhcpcd-5 over the past few months didn't pick this up either.

But at the end of the day, this is a volunteer project. Looking at other core open source software that's around, I think you will find I fix bugs promptly and addess feature requests in a timely fashion.
Heck, I don't even use Arch - mainly because the users are very prompt reporting errors or other constructive feedback.
I only posted to this forum because Google indexed an Arch dhcpcd user who had an issue with a design feature of dhcpcd-5 [1] (which will be toggleable in the next version) and I like to keep people happy.

The turnaround time from bug report to fix to new release was a matter of hours. Now I think that's quite good.
Do you want to waste more time bickering over this or do something ..... shall we say ...... constructive?

[1] http://bbs.archlinux.org/viewtopic.php?id=71933

rsmarples · 2009-05-14 01:05:23

b9anders wrote:

It didn't work for me with core or testing packages either.

I have this broken thingumybob. Can you fix it for me?

Tell you what .... you tell me exactly what is broken in detail, maybe even provide a backtrace if it's a crasher, and I'll try and fix it for you.
Until then, keep my thingumybob and fix it for me.
Thanks!

ckristi · 2009-05-14 04:05:48

@rsmarples: Well... Sorry, Roy. Now I figured out your the main developer of the package. It didn't come to me in the first posts, and I never targeted you in any of my postings. Really, just point me where I said the developer of the dhcpcd package is not doing a good job. It's not your responsability to test any possible configuration variant. But distribution communities are large. That's why I was keeping this talk up. Persons from this community should have catched the bug, not you... not the distro developers. I was crying out for the lack of a testing community. I never said a developer is not doing his/her job. Now, if I'm excused... I'm going to prepare myself for doing something productive (like going to work, which work is not related to Linux in any ways... That was just for pointing out that everything I do here is not for me). You know what, I'm really wondering if everything I try to do for this distro is worth it. Too much wasted time (out of my FREE time) in small talks everytime I try to change something.

Last edited by ckristi (2009-05-14 04:09:30)

Allan · 2009-05-14 05:28:37

ckristi wrote:

But Arch has a great community and it can help test those unpredictable situations. But for these, a testing team should be formed. It's obvious some dozens of testing persons would be more thorough than 5-6 developers.
I really would like to volunteer for such a testing team.
P.S.: I know there's a testing repo... but people may choose or not to use it. Being part of a test team would motivate the people to be a little more proactive.

Well, enable [testing] or keep an eye on the arch-dev-public mailing list for updates to packages you want to test and just install those and file bug reports as necessary... A testing team would just be another layer of bureaucracy for everybody to negotiate.

ckristi · 2009-05-18 10:36:01

@rsmarples (if you're gettin by): Thank for the 5.x release. Now, by managing to set both my default routes as default gateway using dhcpcd (with the 4.x version it didn't work... the second link was not allowed, I guess, to set another default route) I can easily set up my router for being failover (yeah, I have two uplinks at home, and yes... both with dhcp), not just splitting traffic. Now I'm a happy user of a splitting and also failover router.

Arch Linux

#1 2009-05-10 15:03:58

dhcpcd 5.0.1 and segfault

#2 2009-05-10 20:31:12

Re: dhcpcd 5.0.1 and segfault

#3 2009-05-11 05:06:37

Re: dhcpcd 5.0.1 and segfault

#4 2009-05-11 05:20:21

Re: dhcpcd 5.0.1 and segfault

#5 2009-05-11 06:33:50

Re: dhcpcd 5.0.1 and segfault

#6 2009-05-11 06:50:05

Re: dhcpcd 5.0.1 and segfault

#7 2009-05-11 07:56:37

Re: dhcpcd 5.0.1 and segfault

#8 2009-05-11 08:04:56

Re: dhcpcd 5.0.1 and segfault

#9 2009-05-11 09:26:48

Re: dhcpcd 5.0.1 and segfault

#10 2009-05-12 15:01:50

Re: dhcpcd 5.0.1 and segfault

#11 2009-05-13 02:36:10

Re: dhcpcd 5.0.1 and segfault

#12 2009-05-13 02:55:28

Re: dhcpcd 5.0.1 and segfault

#13 2009-05-13 07:26:58

Re: dhcpcd 5.0.1 and segfault

#14 2009-05-13 09:14:21

Re: dhcpcd 5.0.1 and segfault

#15 2009-05-13 09:41:30

Re: dhcpcd 5.0.1 and segfault

#16 2009-05-13 10:08:13

Re: dhcpcd 5.0.1 and segfault

#17 2009-05-13 22:21:33

Re: dhcpcd 5.0.1 and segfault

#18 2009-05-14 00:55:01

Re: dhcpcd 5.0.1 and segfault

#19 2009-05-14 01:05:23

Re: dhcpcd 5.0.1 and segfault

#20 2009-05-14 04:05:48

Re: dhcpcd 5.0.1 and segfault

#21 2009-05-14 05:28:37

Re: dhcpcd 5.0.1 and segfault

#22 2009-05-18 10:36:01

Re: dhcpcd 5.0.1 and segfault

Board footer