This is my network configuration: # cat /etc/conf.d/net dns_domain="mydomain.org" dns_search="mydomain.org" dns_servers="10.215.144.31 10.215.144.35" config_lan="10.215.145.240/16" routes_lan=" default via 10.215.144.91 " sys-apps/openrc-0.42.1::gentoo was built with the following: USE="ncurses netifrc pam (split-usr) unicode -audit -bash -debug -newnet (-prefix) (-selinux) -static-libs -sysv-utils" ABI_X86="(64)" Expected results after /etc/init.d/net.lan start: /etc/resolv.conf: domain mydomain.org nameserver 10.215.144.31 nameserver 10.215.144.35 "lan" interface should have just one static IP address (10.215.145.240). Instead, these are the results: /etc/resolv.conf: # Generated by dhcpcd # /etc/resolv.conf.head can replace this line nameserver 8.8.8.8 # /etc/resolv.conf.tail can replace this line # ip a s lan 6: lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:17:31:83:79:7c brd ff:ff:ff:ff:ff:ff inet 10.215.145.240/16 brd 10.215.255.255 scope global lan valid_lft forever preferred_lft forever inet 10.215.144.163/16 brd 10.215.255.255 scope global secondary noprefixroute lan valid_lft forever preferred_lft forever where 10.215.144.163 is an IP address handed out by a DHCP server on the LAN. It's true that: # ps aux | grep dhcp root 4466 0.0 0.0 3396 2688 ? Ss 12:28 0:00 /sbin/dhcpcd -q # grep dhcpc /etc/init.d/* /etc/init.d/dhcpcd:command=/sbin/dhcpcd /etc/init.d/dhcpcd:pidfile=/var/run/dhcpcd.pid # /etc/init.d/dhcpcd status * status: started However, I am not explicitly launching it: # rc-update show binfmt | boot bootmisc | boot devfs | sysinit dmesg | sysinit fsck | boot hostname | boot hwclock | boot keymaps | boot killprocs | shutdown kmod-static-nodes | sysinit local | default nonetwork localmount | boot loopback | boot mdadm | boot modules | boot mount-ro | shutdown mtab | boot netmount | default procfs | boot root | boot savecache | shutdown swap | boot sysctl | boot sysfs | sysinit syslog-ng | default termencoding | boot udev | sysinit udev-trigger | sysinit urandom | boot Adding any one of these does not change anything: modules="!dhcpcd !dhcp" modules_lan="!dhcpcd !dhcp" I require to have dhcpcd as I may need a client for another interface on this system. I simply do not want it for specific interfaces. I have older Gentoo systems with similar configurations, and they work just fine. Could this be a bug? Maybe a dhcpcd bug? Basically, why doesn't modules_lan="!dhcpcd" work?
You are not actually using netifrc (net.lan) right now-- you haven't added any net providers to the default runlevel, so it's picking the first one it sees, dhcpcd (not net.*). Check "rc-status -a" to confirm, I think you'll see no mention of net.lan, but see dhcpcd in "runlevel: wanted"
To clarify-- I believe that if you actually add net.lan to default runlevel, everything will start working as you expect
net.lan is there and started. So is dhcpcd. # rc-status -a Runlevel: default netmount [ started ] syslog-ng [ started ] local [ started ] Runlevel: nonetwork local [ started ] Runlevel: sysinit sysfs [ started ] cgroups [ started ] devfs [ started ] udev [ started ] kmod-static-nodes [ started ] opentmpfiles-dev [ started ] dmesg [ started ] udev-trigger [ started ] Runlevel: shutdown killprocs [ stopped ] savecache [ stopped ] mount-ro [ stopped ] Runlevel: boot termencoding [ started ] hwclock [ started ] modules [ started ] fsck [ started ] root [ started ] mtab [ started ] swap [ started ] localmount [ started ] sysctl [ started ] bootmisc [ started ] keymaps [ started ] save-keymaps [ started ] urandom [ started ] procfs [ started ] hostname [ started ] mdadm [ started ] save-termencoding [ started ] opentmpfiles-setup [ started ] loopback [ started ] binfmt [ started ] Dynamic Runlevel: hotplugged Dynamic Runlevel: needed/wanted Dynamic Runlevel: manual postgrey [ started ] clamd [ started ] mimedefang [ started ] mysql [ started ] postgresql-12 [ started ] sshd [ started ] apache2 [ started ] autofs [ started ] proftpd [ started ] postfix [ started ] net.lan [ started ] samba [ started ] dhcpcd [ started ] cronie [ started ] ntpd [ started ] suricata [ started ] I do not want to add net.lan to the default runlevel, and never did in the past. That's because I have a custom init script that handles which interfaces to configure and to start or stop (it's a multi-purpose router).
I see that it's in Dynamic Runlevel: manual, but what's the difference?
(In reply to Vieri from comment #4) > I see that it's in Dynamic Runlevel: manual, but what's the difference? That means *you* started it instead of the runlevel. If you add it to the default runlevel with rc-update, then you won't have this issue
(In reply to Brian Evans from comment #5) > (In reply to Vieri from comment #4) > > I see that it's in Dynamic Runlevel: manual, but what's the difference? > > That means *you* started it instead of the runlevel. If you add it to the > default runlevel with rc-update, then you won't have this issue Why? Why is dhcpc used if a static IP address is configured in /etc/conf.d/net? This static address IS applied, but seconds later the dhcp-assigned address also comes up.
(In reply to Vieri from comment #3) > I do not want to add net.lan to the default runlevel, and never did in the > past. That's because I have a custom init script that handles which > interfaces to configure and to start or stop (it's a multi-purpose router). In order to satisfy init dependencies, some sort of script that 'provides net' must be in a runlevel or OpenRC will start the first one it finds. (This is a common thing to 'want net' or 'need net'.) If you really want to be the master of startup through your own script, your choices here are to remove the dhcpcd init script (and every time it is upgraded), or provide a dummy script that does nothing but satisfy the dep and include it with default runlevel. Not really a problem so I'm marking this as Invalid.
I did as you suggested, but it didn't work. # rc-update add net.lan default * service net.lan added to runlevel default # rc-status -a | grep --context=10 net.lan Runlevel: default net.lan [ started ] netmount [ started ] syslog-ng [ started ] local [ started ] Runlevel: nonetwork local [ started ] Runlevel: sysinit sysfs [ started ] cgroups [ started ] devfs [ started ] udev [ started ] # /etc/init.d/net.lan restart * Stopping suricata ... [ ok ] * samba -> stop: smbd ... [ ok ] * samba -> stop: nmbd ... [ ok ] * samba -> stop: winbind ... [ ok ] * Stopping ProFTPD ... [ ok ] * Stopping Postgrey ... [ ok ] * Unmounting network filesystems ... [ ok ] * Stopping apache2 ... ok ] * Bringing down interface lan * Bringing up interface lan * 10.215.145.240/16 ... [ ok ] * Adding routes * default via 10.215.144.91 ... [ ok ] * Call to flock failed: Resource temporarily unavailable * samba -> start: smbd ... * Mounting network filesystems ... * Starting Postgrey ... [ ok ] * suricata will run as user suricata:suricata. * Starting suricata ... [ ok ] * samba -> start: nmbd ... * Starting ProFTPD ... [ ok ] * samba -> start: winbind ... * Starting apache2 ... [ ok ] # ip a s lan 6: lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:17:31:83:79:7c brd ff:ff:ff:ff:ff:ff inet 10.215.145.240/16 brd 10.215.255.255 scope global lan valid_lft forever preferred_lft forever inet 10.215.144.163/16 brd 10.215.255.255 scope global secondary noprefixroute lan valid_lft forever preferred_lft forever The DHCP IP address is still coming back (10.215.144.163).
Do you mind re-opening this bug because we commented almost at the same time... See comment 8, please.
(In reply to Vieri from comment #9) > Do you mind re-opening this bug because we commented almost at the same > time... See comment 8, please. When you restart the machine, or stop the dhcpcd script, this will no longer happen. The dhcpcd init does not look at conf.d/net so it won't know. netifrc won't know about the dhcpcd init either.
OK, I can confirm that it works now (after stopping dhcpcd -- haven't rebooted yet). So, this is a change in openrc because I have several other older Gentoo systems without this behavior. I guess I'll have to review the way I start the machine. Thanks
