# [SOLVED] Who is starting dhcpcd at boot?

## quanta

I'm still pulling my hair with `wicd`. After updating the world, not only must I restart `wicd` after booting as described here (https://forums.gentoo.org/viewtopic-p-6970234.html#6970234), I also have to stop the `dhcpcd` first. 

The strange thing is it is already removed from the all runlevels:

```
# rc-update -v show | grep dhcpcd

               dhcpcd |                         
```

`wpa_supplicant`, `net.eth0` are removed too:

```
# rc-update -v show | egrep 'wpa|eth0'

             net.eth0 |                                                       

       wpa_supplicant |                
```

```
# grep hotplug /etc/rc.conf | grep -v '^#'

rc_hotplug="!net*"
```

but `dhcpcd` is still started at boot:

```
$ ps -ef | grep dhcpcd

root      2383     1  0 13:02 ?        00:00:00 /sbin/dhcpcd -q
```

at the boot screen, I see the exact message from dhcpcd init script:

```
Starting DHCP Client Daemon...
```

```
cat /etc/init.d/dhcpcd

#!/sbin/runscript

# Copyright 1999-2011 Roy Marples <roy@marples.name>

# All rights reserved. Released under the 2-clause BSD license.

command=/sbin/dhcpcd

pidfile=/var/run/dhcpcd.pid

command_args=-q

name="DHCP Client Daemon"

depend()

{

   if [ "${RC_VERSION:-0}" != "0" ]; then

      provide net

      need localmount

      use logger network

      after bootmisc modules

      before dns

   fi

}

if [ "${RC_VERSION:-0}" = "0" ]; then

   start()

   {

      eerror "This script cannot be used for baselayout-1."

      return 1

   }

fi
```

I'm wondering whether I need `/etc/conf.d/net` if I'm using `wicd`:

```
# cat /etc/conf.d/net

dns_domain_lo="homenetwork"

config_eth0="dhcp"

dhcpcd_eth0="-t 3"

iwconfig_wlan0="power on"

dns_servers_wlan0=("8.8.8.8","8.8.4.4")

modules=( "!plug" )

modules_eth0=( "ifplugd" ) 

```

In summary, the main question is: how do I make the wicd connect to wired or wireless network automatically at boot?Last edited by quanta on Tue Mar 20, 2012 2:36 pm; edited 2 times in total

----------

## Kaso_da_Zmok

maybe is this:

https://forums.gentoo.org/viewtopic-t-913964-highlight-.html

you have got your openrc updated and now it behaves like this:

after the openrc 9.9.0 the netmount or sshd or any other "need net" service is trigerring services which "provide net" 

fix is to add "provide net" to wicd if not done by etc-update

```
# nano -w /etc/init.d/wicd 

depend() { 

        provide net 

        need dbus 

        after hald 

}
```

----------

## quanta

@Kaso_da_Zmok: thank you very much!

`dhcpcd` doesn't start anymore at boot after adding `provide net` to the wicd init script but my original problem is still there.

Here's the logs after boot:

```
2012/03/16 15:03:17 :: DHCP connection successful

2012/03/16 15:03:17 :: not verifying

2012/03/16 15:03:17 :: Connecting thread exiting.

2012/03/16 15:03:20 :: Sending connection attempt result success

2012/03/16 15:04:44 :: Daemon going down, killing wicd-monitor...

2012/03/16 15:04:44 :: Removing PID file...

2012/03/16 15:04:44 :: Shutting down...

2012/03/16 15:04:44 :: Exception KeyError: KeyError(-1220397376,) in <module 'threading' from '/usr/lib/python2.7/threading.py

o'> ignored

```

It looks like a bug: https://bugs.launchpad.net/wicd/+bug/677304, but I'm using kde-misc/wicd-client-kde not wicd-gtk.

----------

## cach0rr0

just to be clear, you are aware that wicd uses both dhcpcd and wpa_supplicant yes? 

I would expect wicd to fire off a dhcpcd process

the init service for dhcpcd should not need to start, no, but seeing a dhcpcd process spawned from wicd is normal and expected unless you specifically configure wicd not to use dhcp for whichever interface.

----------

## quanta

 *cach0rr0 wrote:*   

> just to be clear, you are aware that wicd uses both dhcpcd and wpa_supplicant yes? 
> 
> I would expect wicd to fire off a dhcpcd process
> 
> the init service for dhcpcd should not need to start, no, but seeing a dhcpcd process spawned from wicd is normal and expected unless you specifically configure wicd not to use dhcp for whichever interface.

 

Before updating, if `dhcpcd` is already removed from all runlevels, there is no such `dhcpcd` process after booting (either by the init script ifself or spawned from wicd).

It doesn't matter if `wicd` still works but I must stop it first and restart wicd to get the networking. Do you have any idea about this: https://forums.gentoo.org/viewtopic-p-6970234.html#6970234?

----------

## UberLord

 *cach0rr0 wrote:*   

> I would expect wicd to fire off a dhcpcd process

 

dhcpcd listens to the kernel for the correct events, so there is no need for wicd to trigger any dhcpcd actions. dhcpcd just needs to be started as a service without any interfaces specified.

----------

## cach0rr0

 *UberLord wrote:*   

> 
> 
> dhcpcd listens to the kernel for the correct events, so there is no need for wicd to trigger any dhcpcd actions. dhcpcd just needs to be started as a service without any interfaces specified.

 

Noted. As it is now, wicd is firing off a:

```

root      7358     1  0 Mar20 ?        00:00:00 /sbin/dhcpcd wlan0 -h hostnameconfiguredinwicd.tld

```

Seems it's superfluous (?) in some setups (i.e. managing this all through init scripts rather than a graphical tool).

rather, wicd may not need it, but it seems it's designed to need it (when maybe it shouldn't be? Then again it supports dhcp clients other than dhcpcd)

That's my vague understanding at least. As far as the design of dhcpcd itself, well...I think I'll listen to the guy that wrote it  :Laughing: 

----------

## rogerx

This disables dhcpcd from being started when the network service is called during boot.

/etc/rc.conf

rc_hotplug="!dhcpcd"

Seems dhcpcd has a gentoo services script installed to automatically start dhcpcd if there's a network service starting.

I think dhcpcd should only be called to start (due to the long startup delay), upon /etc/init.d/net* (or network) failing to start with the static configured network values, and then falls back to dhcp.  Upon fallback to dhcp, then start the dhcp background daemon!  (ie. Start network, If network fails, then start dhcpcd && restart network.  Upon second fail give-up on network.)

----------

## khayyam

 *rogerx wrote:*   

> This disables dhcpcd from being started when the network service is called during boot.
> 
> /etc/rc.conf
> 
> ```
> ...

 

... hmmm ... but "[b]y default we do not allow hotplugging", anyhow, I generally use the following ...

```
rc_dhcpcd_provide="!net"
```

 *rogerx wrote:*   

> Seems dhcpcd has a gentoo services script installed to automatically start dhcpcd if there's a network service starting.

 

well, it 'provide[s] net', also if /etc/conf.d/net has 'config_${IFACE}="dhcp", or is empty then dhcpcd has preference (it will use udhcpc from busybox if no other client is available).

 *rogerx wrote:*   

> I think dhcpcd should only be called to start (due to the long startup delay), upon /etc/init.d/net* (or network) failing to start with the static configured network values, and then falls back to dhcp. Upon fallback to dhcp, then start the dhcp background daemon!  (ie. Start network, If network fails, then start dhcpcd && restart network.  Upon second fail give-up on network.)

 

I think if nothing is explicitly provided and something 'need[s] net' then whatever needs it should fail. Anyhow, when you say "/etc/init.d/net*" that would only match net.lo, netifrc (and previously openrc) no longer installs symlinks to net.lo. So, if a symlink is created and added to the runlevel then it should 'provide net'. That's why dhcpcd became a provider of 'net' ... because net.${IFACE} isn't guaranteed to be there ... and everyone must be protected from computers doing only what you tell them to :)

best ... khay

----------

## rogerx

"That's why dhcpcd became a provider of 'net' ... because net.${IFACE} isn't guaranteed to be there "

This is exactly the problem I was trying to solve, with my previous ramblings.

The solution you just stated could be easily considered a very broad solution which is currently implemented within OpenRC/dhcpcd packages, which I think can be slightly refined.  Most experts are likely going to have static configurations, rarely falling back on dhcpcd when using desktops, unless they're using mobile computing.  New users, or new computer systems, will likely default to dhcpcd.

As such, I just blocked the dhcpcd daemon (ie. !dhcpcd) from running.  Simple solution, but again still too broad and will likely need to unblock if I do need dhcpcd again.  My previous ramblings were an effort to graph or create a flow chart for programming a solution. ;-)

----------

