# dhcpcd takes 1%-3% constant cpu resources out of my system

## MiXi-IL

Hi,

I used top today and found out that dhcpcd is using my cpu constantly, between 1%-3% utilization.

Is it normal for such a process to consume such amounts of cpu time (constantly...)?

What can I do to return to normal state where I get to see 100% idle once in a while (or at least 99...   :Very Happy:  )

Thanks.

----------

## UberLord

What version of dhcpcd?

----------

## mliesenf

I'm noticing something very similar. /sbin/dhcpcd seems to use more CPU time when I'm actively scp'ing a large set of files. I can't explain why, but that's just something I'm noticing.

dhcpcd version: net-misc/dhcpcd-2.0.3

----------

## MiXi-IL

It seems that I missed something when I diagnosed the situation. Now when this thread has woke up again, I should correct it.

When I executed "top", I didn't notice that on another tty I had ethereal running. After I terminated ethereal (a few days later) dhcpcd has returned to normal cpu usage.

----------

## gregp01

mliesenf / anyone: Have you had any luck figuring out what the problem was?

I'm experiencing the same issue with dhcpcd using a constant 1% - 3% CPU. Mine seems to be related to Samba (smbd) activity rather than scp, though. Regardless, it seems to me that this should *never* happen - dhcpcd should take much less than a second of CPU time every few hours, when it renews the DHCP lease. On my server with an uptime of several days, top reports over 4 hours of CPU time! I too am using dhcpcd-2.0.3. It seems like this could be a bug, as I never saw this behavior before. I'm going to try reverting to the previous version and see what happens...

----------

## gregp01

Well, I've now tried versions 2.0.4, 2.0.5, and reverting to 2.0.0. The issue is still present in 2.0.4, and to a lesser degree in 2.0.5 (occasional jumps to a few fractions of a percent of CPU), and is completely absent from 2.0.0. I'm going to stick with 2.0.0 for now, and I've submitted a bug report. Hopefully someone will be able to track this down.

----------

## UberLord

Care to profile each version so we can find out where it starts to go wrong?

Thanks

----------

## no_hope

 *UberLord wrote:*   

> Care to profile each version so we can find out where it starts to go wrong?

 

how would I go about doing that?

Below is a taste of what strace -f dhcpcd eth0 gives me. The select on the first line is where the child sits and waits after it a lease has been acquired. The rest of the snippet is what happens continuously as I run my scripts on a Samba mount. During that time dhcpcd eats ~5% of CPU time on my Samba server and 10-20% of CPU time on the client. I am using dhcpcd 2.0.3 on both ends, strace was run on the client.

```

select(5, [3 4], NULL, NULL, NULL)      = 1 (in [3])

recvfrom(3, "\0\260\320\222Un\0\f)\2y\27\10\0E\0\0\263H\6@\0@\6\334"..., 512, 0, NULL, NULL) = 193

recvfrom(3, "\0\f)\2y\27\0\260\320\222Un\10\0E\0\0\331\5\374@\0@\6\36"..., 512, 0, NULL, NULL) = 231

recvfrom(3, "\0\260\320\222Un\0\f)\2y\27\10\0E\0\0004H\7@\0@\6\334\260"..., 512, 0, NULL, NULL) = 66

recvfrom(3, 0xbfb2614c, 512, 0, 0, 0)   = -1 EAGAIN (Resource temporarily unavailable)

select(5, [3 4], NULL, NULL, NULL)      = 1 (in [3])

recvfrom(3, "\0\260\320\222Un\0\f)\2y\27\10\0E\0\0\221H\10@\0@\6\334"..., 512, 0, NULL, NULL) = 159

recvfrom(3, "\0\f)\2y\27\0\260\320\222Un\10\0E\0\0i\5\376@\0@\6\36\205"..., 512, 0, NULL, NULL) = 119

recvfrom(3, 0xbfb2614c, 512, 0, 0, 0)   = -1 EAGAIN (Resource temporarily unavailable)

select(5, [3 4], NULL, NULL, NULL)      = 1 (in [3])

recvfrom(3, "\0\260\320\222Un\0\f)\2y\27\10\0E\0\0aH\t@\0@\6\334\201"..., 512, 0, NULL, NULL) = 111

recvfrom(3, "\0\f)\2y\27\0\260\320\222Un\10\0E\0\0[\6\0@\0@\6\36\221"..., 512, 0, NULL, NULL) = 105

recvfrom(3, 0xbfb2614c, 512, 0, 0, 0)   = -1 EAGAIN (Resource temporarily unavailable)

select(5, [3 4], NULL, NULL, NULL)      = 1 (in [3])

recvfrom(3, "\0\260\320\222Un\0\f)\2y\27\10\0E\0\0\243H\n@\0@\6\334"..., 512, 0, NULL, NULL) = 177

recvfrom(3, "\0\f)\2y\27\0\260\320\222Un\10\0E\0\0\331\6\2@\0@\6\36"..., 512, 0, NULL, NULL) = 231

recvfrom(3, 0xbfb2614c, 512, 0, 0, 0)   = -1 EAGAIN (Resource temporarily unavailable)

select(5, [3 4], NULL, NULL, NULL)      = 1 (in [3])

recvfrom(3, "\0\260\320\222Un\0\f)\2y\27\10\0E\0\0\221H\v@\0@\6\334"..., 512, 0, NULL, NULL) = 159

recvfrom(3, "\0\f)\2y\27\0\260\320\222Un\10\0E\0\0i\6\4@\0@\6\36\177"..., 512, 0, NULL, NULL) = 119

recvfrom(3, 0xbfb2614c, 512, 0, 0, 0)   = -1 EAGAIN (Resource temporarily unavailable)

select(5, [3 4], NULL, NULL, NULL)      = 1 (in [3])

recvfrom(3, "\0\260\320\222Un\0\f)\2y\27\10\0E\0\0\247H\f@\0@\6\334"..., 512, 0, NULL, NULL) = 181

recvfrom(3, "\0\f)\2y\27\0\260\320\222Un\10\0E\0\0\331\6\6@\0@\6\36"..., 512, 0, NULL, NULL) = 231

recvfrom(3, 0xbfb2614c, 512, 0, 0, 0)   = -1 EAGAIN (Resource temporarily unavailable)

select(5, [3 4], NULL, NULL, NULL)      = 1 (in [3])

recvfrom(3, "\0\260\320\222Un\0\f)\2y\27\10\0E\0\0\257H\r@\0@\6\334"..., 512, 0, NULL, NULL) = 189

recvfrom(3, 0xbfb2614c, 512, 0, 0, 0)   = -1 EAGAIN (Resource temporarily unavailable)

select(5, [3 4], NULL, NULL, NULL)      = 1 (in [3])

recvfrom(3, "\0\f)\2y\27\0\260\320\222Un\10\0E\0\5\334\6\10@\0@\6\31"..., 512, 0, NULL, NULL) = 512

recvfrom(3, "\0\f)\2y\27\0\260\320\222Un\10\0E\0\5\334\6\n@\0@\6\31"..., 512, 0, NULL, NULL) = 512

recvfrom(3, "\0\260\320\222Un\0\f)\2y\27\10\0E\0\0004H\16@\0@\6\334"..., 512, 0, NULL, NULL) = 66

recvfrom(3, "\0\f)\2y\27\0\260\320\222Un\10\0E\0\5\334\6\f@\0@\6\31"..., 512, 0, NULL, NULL) = 512

recvfrom(3, "\0\f)\2y\27\0\260\320\222Un\10\0E\0\5\334\6\16@\0@\6\31"..., 512, 0, NULL, NULL) = 512

recvfrom(3, "\0\260\320\222Un\0\f)\2y\27\10\0E\0\0004H\17@\0@\6\334"..., 512, 0, NULL, NULL) = 66

recvfrom(3, "\0\f)\2y\27\0\260\320\222Un\10\0E\0\5\334\6\20@\0@\6\31"..., 512, 0, NULL, NULL) = 512

recvfrom(3, "\0\f)\2y\27\0\260\320\222Un\10\0E\0\5\334\6\22@\0@\6\30"..., 512, 0, NULL, NULL) = 512

recvfrom(3, "\0\260\320\222Un\0\f)\2y\27\10\0E\0\0004H\20@\0@\6\334"..., 512, 0, NULL, NULL) = 66

recvfrom(3, "\0\f)\2y\27\0\260\320\222Un\10\0E\0\5\334\6\24@\0@\6\30"..., 512, 0, NULL, NULL) = 512

recvfrom(3, "\0\f)\2y\27\0\260\320\222Un\10\0E\0\5\334\6\26@\0@\6\30"..., 512, 0, NULL, NULL) = 512

recvfrom(3, "\0\260\320\222Un\0\f)\2y\27\10\0E\0\0004H\21@\0@\6\334"..., 512, 0, NULL, NULL) = 66

recvfrom(3, "\0\f)\2y\27\0\260\320\222Un\10\0E\0\5\304\6\30@\0@\6\31"..., 512, 0, NULL, NULL) = 512

recvfrom(3, 0xbfb2614c, 512, 0, 0, 0)   = -1 EAGAIN (Resource temporarily unavailable)

```

----------

## bobwarlock

Just in case people miss/ignore the bug report mentioned above, this has been resolved in version 2.0.6 and up.

I was getting ~15-20% cpu usage while doing a large scp on my system, and upgrading to 2.0.8 solved it.

----------

## turtles

side note: scp starts a process for each file, might try using tar and or sync for lots of files.

----------

## gregp01

It took me forever to get another chance to look into this, but it definitely looks to have been fixed. Thanks a lot, everyone!

----------

