[SOLVED] Network daemon starting slowly

Hello guys,
It seems like the network daemon is starting rather slowly (maybe due to the fact that it has to obtain an ip address via dhcp). If I could get it to start faster, my system would boot up in under 10 seconds Is it safe to launch the network daemon in the background? If no, is there any way to speed it up?
Thanks for the help.
Last edited by 10098 (2010-05-16 12:35:54)

Maybe try Backgrounding it by adding a @ in front of it within /etc/rc.conf.
Yes it's generally safe to background it in most cases unless you have a good reason not to do so.
Last edited by davidm (2010-05-13 16:40:37)

Similar Messages

[SOLVED] Network bridge fails to start after systemd update

Hello,
After rebooting with the upgraded systemd (208-11 -> 210-2) by bridge could not start.
journal
Mar 06 00:08:45 myhost systemd[1]: Job sys-subsystem-net-devices-enp2s0.device/start timed out.
Mar 06 00:08:45 myhost systemd[1]: Timed out waiting for device sys-subsystem-net-devices-enp2s0.device.
Mar 06 00:08:45 myhost systemd[1]: Dependency failed for My network bridge with DHCP.
Mar 06 00:08:45 myhost systemd[1]: Starting Network.
Mar 06 00:08:45 myhost systemd[1]: Reached target Network.
# cat /etc/systemd/system/[email protected]
.include /usr/lib/systemd/system/[email protected]
[Unit]
Description=My network bridge with DHCP
BindsTo=sys-subsystem-net-devices-enp2s0.device
After=sys-subsystem-net-devices-enp2s0.device
# cat /etc/netctl/br0
Description="My network bridge with DHCP"
Interface=br0
Connection=bridge
BindsToInterfaces=(enp2s0)
IP=dhcp
Commenting out BindsTo and After in the unit file allows to start the service, but it would still throw an error
Mar 06 00:14:05 myhost systemd[1]: Starting My network bridge with DHCP...
Mar 06 00:14:05 myhost network[732]: Starting network profile 'br0'...
Mar 06 00:14:05 myhost kernel: Bridge firewalling registered
Mar 06 00:14:05 myhost systemd-udevd[739]: Could not apply link config to br0
I never renamed interfaces, it was always the system-assigned enp2s0.
What could have become wrong?
Last edited by aya (2014-03-11 14:31:31)

aya wrote:I do use a custom kernel and I did not have CONFIG_FHANDLE enabled. I wish it was posted as an announcement or something.
From the 210 release announcement:
systemd 210 announcement wrote:
Heya,
And here's the next release 210:
http://www.freedesktop.org/software/sys … 210.tar.xz
<snip>
Oh, and one reminder that kinda got lost when we announced 209: you have
to enable CONFIG_FHANDLE in your kernel to use systemd >= 209
successfully, otherwise udev won't find any devices.
<snip>

(solved) Network Restart

I've recently discovered a new problem with arch...
The network daemon can't be restarted properly. Whenever I try a "/etc/rc.d/network restart" everything seems to be working fine but I don't have a functioning network afterwards. After a second restart, however, it suddenly works. First of all I thought it was a suspend issue but it also happens directly after a boot.
Don't know what could've caused it nor have I an idea how to solve it.
Help appreciated
Last edited by MrFuji (2007-06-20 18:11:22)

Yep, you're perfectly right, only starting my wireless interface (madwifi btw) but...
nope, that didn't work....
But here's something that might be useful...
First restart
[sven@svenlap ~]$ sudo /etc/rc.d/network stop
:: Stopping Network [DONE]
[sven@svenlap ~]$ sudo /etc/rc.d/network start
:: Starting Network [DONE]
[sven@svenlap ~]$ iwconfig ath0
ath0 IEEE 802.11g ESSID:"FeelGood" Nickname:""
Mode:Managed Frequency:2.412 GHz Access Point: 00:12:BF:A5:62:A4
Bit Rate:54 Mb/s Tx-Power:16 dBm Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=35/94 Signal level=-58 dBm Noise level=-93 dBm
Rx invalid nwid:7556 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
[sven@svenlap ~]$ ifconfig ath0
ath0 Link encap:Ethernet HWaddr 00:19:7D:33:F5:53
inet6 addr: fe80::219:7dff:fe33:f553/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:356 errors:0 dropped:0 overruns:0 frame:0
TX packets:194 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:115759 (113.0 Kb) TX bytes:48925 (47.7 Kb)
And the second one:
[sven@svenlap ~]$ sudo /etc/rc.d/network stop
:: Stopping Network [DONE]
[sven@svenlap ~]$ sudo /etc/rc.d/network start
:: Starting Network [DONE]
[sven@svenlap ~]$ iwconfig ath0
ath0 IEEE 802.11g ESSID:"FeelGood" Nickname:""
Mode:Managed Frequency:2.412 GHz Access Point: 00:12:BF:A5:62:A4
Bit Rate:54 Mb/s Tx-Power:16 dBm Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Power Management:off
Link Quality=32/94 Signal level=-61 dBm Noise level=-93 dBm
Rx invalid nwid:9185 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
[sven@svenlap ~]$ ifconfig ath0
ath0 Link encap:Ethernet HWaddr 00:19:7D:33:F5:53
inet addr:192.168.2.101 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::219:7dff:fe33:f553/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:410 errors:0 dropped:0 overruns:0 frame:0
TX packets:204 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:118887 (116.1 Kb) TX bytes:50183 (49.0 Kb)
There doesn't seem to be something wrong with the iwconfig part but obviously I don't have an IP address after the first restart.
Then maybe misfit is right and it's still something wrong with the dhcpd variable?
edit: It has obviously something to do with dhcpcd because if I restart the network after a "killall dhcpcd" everything works fine....
Last edited by MrFuji (2007-06-20 13:47:13)

[ SOLVED ] Network disappears after a few reboots

I have tried to install Arch twice and both times after rebooting it several times network connection disappears ( i.e., daemon starts ok, but no connection is preset ).
By looking at the error.log, it seems that dhcpcd fails to obtain requested IP address ( nothing specified in rc.conf ).
Is there anything I might be missing or it is a know problem ( saw the same question somewhere else ) ?
Last edited by MinimalBoot (2012-06-05 14:50:38)

glad you could make it work
could you please mark the thread as solved?
you could do so by editing the first post
regards

[SOLVED] network randomly doesn't work after reboot (e100)

Hi
Lately I have some weird issues with network. I shutdown computer during night, so basicly I reboot it at least once per day and every now and then without any pattern network doesn't work at all and so far only solution I have found is to reboot (again).
Before anything else I'm sure it's not hardware problem, since other OS on same computer don't have any issues, neither is router since other devices in network from laptops to mobile phones work flawless.
Relevant info and what I have found so far (not everything is copy/pasted so there may be some typos):
$less rc.conf (network part)
eth1="eth1 192.168.1.242 netmask 255.255.255.0 broadcast 192.168.1.255
INTERFACES=(eth1)
gateway="default gw 192.168.1.1"
ROUTES=(gateway)
$ifconfig
eth1 Link encap:Ethernet HWaddr 00:D0:B7:5A:7A:A9
inet addr:192.168.1.242 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:380 errors:0 dropped:0 overruns:0 frame:0
TX packets:380 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:36154 (35.3 Kb) TX bytes:36154 (35.3 Kb)
$route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
$ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data
From 192.168.1.242 icmp_seq=2 Destination Host Unreachable
So basicly network is dead, can't even ping router, cable connection is detected tho (lights are on). I have tried to restart newtork with /etc/rc.d/network stop/start, nothing. Only clue is dmesg.
$dmesg
Linux version 2.6.30-ARCH (root@T-POWA-LX) (gcc version 4.4.1 (GCC) ) #1 SMP PREEMPT Fri Jul 31 07:30:28 CEST 2009
e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
e100 0000:03:07.0: PCI INT A -> Link[APC2] -> GSI 17 (level, low) -> IRQ 17
e100 0000:03:07.0: PME# disabled
e100: eth1: e100_probe: addr 0xfdfff000, irq 17, MAC addr 00:d0:b7:5a:7a:a9
e100 0000:03:07.0: firmware: requesting e100/d101m_ucode.bin
ADDRCONF(NETDEV_UP): eth1: link is not ready
modrope -r e100 and then reloading it doesn't help either, but reboot does (once I had to reboot twice tho).
Anyone with more clue and ideas then me, it's getting really annoying, it also kill whole KDE plasma-desktop for couple of minutes before plasmoids find out network is really down and I'm not really fan of morning "gamble". I can't pinpoint some hard date/update when this started to happening because like I said it's random but last couple of months should be quite accurate. Thanks in advance.
EDIT: dmesg when network works:
tilen@pikmin ~]$ dmesg | grep e100
pci 0000:03:07.0: Firmware left e100 interrupts enabled; disabling
e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
e100 0000:03:07.0: PCI INT A -> Link[APC2] -> GSI 17 (level, low) -> IRQ 17
e100 0000:03:07.0: PME# disabled
e100: eth0: e100_probe: addr 0xfdfff000, irq 17, MAC addr 00:d0:b7:5a:7a:a9
Last edited by NoOrdinary (2009-09-05 09:47:20)

I don't have anything special set at router but I doubt rc.conf play any role. I will try to set it up with dhcp (but I think I have tried that already) if there is any change.
This morning I had to reboot twice, so new kernel didn't help. Fowler, what network card are you using, also e100 (well or some intel)? I dunno, should this be handed to the kernel team? If it will piss me enough one morning I'll just go and buy a new network card, just wanna be sure that will really solve the problem.
UPDATE: OK, this is just silly. I remebered I have acctualy onboard LAN so I edited rc.conf and dived into the dust under my desk to move cable and there I found out it was acctual onboard in use all the time Now this dosen't make much sense to me anymore, when I can't get net up all the stuff in dmesg is e100 related. Anyway, I connected network to e100 and rebooted, suprise, same story. Dmesg reported again link was not ready. I edited rc.conf to
INTERFACES=(eth0 !eth1)
in case this has anything to do with proper timing at assigning whatever needs to be assigned to network cards at boot so I'm sure just 1 card with all info provided get's kicked in at boot. First reboot after that works, it dosen't prove anything yet but at leat it's some kind of progress in recognising proper cause.
UPDATE 2: Nah, still happens. Googling for "no link during initialization" show a lot of familiar problems, almost all on nforce motherboards and mine is nforce too. I just don't get it why this mess seperate PCI network card. In any case it's extremely annoying.
Last edited by NoOrdinary (2009-09-02 11:46:27)

Make daemons start after boot?

Can I make daemons start after the boot has ended? Netcfg uses about 10 seconds connecting to my wireless network, and the mounting of my windows share (trough fstab, using cifs) takes even longer. Therefore, I'd like to know if there's a way to start netcfg as a daemon and/or also mount my share after I've gotten into Arch and/or X after boot?
Can I use something like .xinitrc for this?
Last edited by Bennythen00b (2010-12-18 23:30:04)

I tried that, but my windows share won't mount then for some reason. :-/
E: To be a little more specific, I backgrounded "net-profiles" and "network". I assume this doesn't work because whatever executes fstab tries to mount the share and fails before the network has finished connecting, or are daemons queued in the background too?
Anyway, just having "network" backgrounded works rather well, and I only have to wait for my wifi to connect. Not a huge problem, but I'd prefer having it start in the background in some way.
Last edited by Bennythen00b (2010-12-19 02:44:08)

Init: dependency based daemon starting?

note: I saw http://bbs.archlinux.org/viewtopic.php?id=69086, but i have no idea how the implementation is done (I don't understand Italian )
the current daemon backgrounding feature in rc.conf is pretty cool to save time, but:
1) you have no feedback if the daemon started successfully or not
2) due to its lack of finegrained-ness, the speed gains are limited.
for example, this is the DAEMONS array of my home server:
DAEMONS=(syslog-ng network @netfs @crond @sshd rpcbind nfs-common nfs-server openntpd @bitlbee @mediatomb @httpd @noip @dnsmasq)
The items at the right (bitlbee, mediatomb, ..) depend on nfs and ntp beind started completely, but ntpd should not have to wait until all the nfs stuff is started.
unfortunately, with the current "linear" syntax there is no way to improve this.
So if there was a way to express "daemon foo can start as soon as daemons (dependencies) bar and baz are started" we can optimize things a bit further.
then we could basically start everything backgrounded as soon as the dependencies are started.
As for problem 1: you could start each initscript in a seprate wrapper function or whatever, which buffers the stdout and stderr. If you start multiple daemons at the same time, scripts could leak output which may look garbled if you see multiple lines of text from different daemons at the same time. Once the script exited, you write the buffered stdout/stderr and put OK/WARNING thing on the right in place. maybe this is overkill though, most of the initscripts i use give no additional output anyway. But with this way, you could start multiple daemons at the same time in background, but still collect their return status and show it to the user.
Initing in this way can probably be done with a relatively small code increase, but would provide a slight performance improvement for some use cases.
Is it worth it? I don't know. Maybe there are even better initsystems which take it a few steps further, but i thought it was a cool idea

Well, you could always create a meta daemon (an init script in /etc/rc.d/ ) which starts a group of daemons.
It's been a while since I used initng as a lancher for archlinux initscript but it is certainly possible. I don't have the modified scripts anymore but it wasn't that hard to modify anyway.
As far as I know the finit-arc is based on fastinit (it doesn't have any dependency tracking):
http://helllabs.org/finit/
Last edited by PJ (2010-04-27 21:10:24)

Boot time confusion involving wireless (BCRM4313) and network daemon

The platform in question of course my Asus eeepc 1015PEM and the issue isn't likely to be coursed by me making a mistake, though I may have misinterpreted what the stock network daemon is all about.
During boot I get this message:
:: Starting network
[ 5.616800] ieee8011 phy0: brcms_ops_bss_info_changed: qos enabled: false (implement)
[ 5.620882] ieee8011 phy0: brcms_ops_config: change power-save mode: false (implement)
All I know is that it has something to do with my wireless, as it goes away when I disable it in BIOS, and that I haven't had this issue with previous arch installation, only with the latest release and possibly with the one just before that, which I didn't mess around with.
As far as I know the stock network daemon can't handle wireless devices, so it does confuse me a bit.
Apart from that, the wireless seem to work as it used to, but I can't confirm it as I haven't had a chance to test it.
Also this is a more or less clean install and I've done very little to begin setting up the wireless.
Well, all that doesn't matter anyway, I'd simply like to know what those two lines mean and how to get rid of them.
Best regards.
Last edited by zacariaz (2012-08-22 16:51:35)

They won't disappear by changing the network daemon, as they're printed when the brcmsmac driver loads. Which is done by udev. That the messages appear right after the network daemon loads is pure coincidence. I don't think the messages indicate a problem, it's just the brcmsmac driver being a bit too chatty. Try adding loglevel=3 to the kernel line in the grub config (or the append line if you use syslinux or lilo).
Last edited by Gusar (2012-08-22 17:08:05)

Network daemon hangs

so i'm not sure what happened, but I rebooted my system this morning, and the network daemon hangs and does not get an ip.....
any thoughts?

i cleared the logs thinking i would let them start fresh, so far I can't find anything network related showing up
I had to boot from a cd and chroot it to disable everything to get it to boot, so right now the only daemon loading is syslog
i tried booting from the cd to chroot again and run updates
if i try to start the network daemon it just hangs and says busy, nothing really happens
i've now tried downgrading the kernel, and dhcpcd and so far nothing
I can set an ip manually using ifconfig but then if i try to add a route, i still have issues, not sure whats happening, but im not happy at the moment
i have a feeling there might be something corrupted somewhere
Last edited by ssl6 (2012-04-01 18:32:09)

Make Network Daemon Wait Until Network is Ready?

I run an Arch64 server which is behind a router. I am also away from home a lot. If the power goes out I worry that there is a chance the server will boot up and the network daemon will give up before the router has booted back up, and then I will be unable to access my machine remotely until I can get home and reboot it manually. Does anyone know of a way to make the network daemon, upon starting up, wait for the network to become available no matter how long it takes? I guess I'm looking for a way to disable the network daemon's timeout period. Thanks in advance!
Last edited by tony5429 (2010-05-20 02:47:59)

Hrm.. maybe I didn't explain myself well enough. The machine is not using DHCP. Instead it tries to take the static IP 192.168.1.100 on the LAN, for which ports 80 and 22 are forwarded through the router so I can access it remotely. My concern is this: Whenever I turn on the machine with the router turned off, when Arch Linux gets to starting up the network daemon it will time out. So I worry that if the power goes out on both the router and the server and the power returns, if the Linux box tries to connect to the network before the network is ready, it could give up too fast and then I would not be able to access it remotely when the router actually did boot back up. So I'm just looking for a way to disable the network daemon's timeout option so that it tries forever until the network is available, regardless of how long that takes. Hope that makes sense. Thanks for the help!

Lightroom 4 crashes when trying to open the slideshow module. I spent over three hours with both Adobe and Apple tech support and we know it is a permission issue but have not been able to get it solved. It started with the last upgrade to 10.8

Lightroom 4 crashes when trying to open the slideshow module. I spent over three hours with both Adobe and Apple tech support and we know it is a permission issue but have not been able to get it solved. It started with the last upgrade to 10.8

Back up all data.
This procedure will unlock all your user files (not system files) and reset their ownership and access-control lists to the default. If you've set special values for those attributes on any of your files, they will be reverted. In that case, either stop here, or be prepared to recreate the settings if necessary. Do so only after verifying that those settings didn't cause the problem. If none of this is meaningful to you, you don't need to worry about it.
Step 1
If you have more than one user account, and the one in question is not an administrator account, then temporarily promote it to administrator status in the Users & Groups preference pane. To do that, unlock the preference pane using the credentials of an administrator, check the box marked Allow user to administer this computer, then reboot. You can demote the problem account back to standard status when this step has been completed.
Triple-click the following line to select it. Copy the selected text to the Clipboard (command-C):
{ sudo chflags -R nouchg,nouappnd ~ $TMPDIR.. ; sudo chown -Rh $UID:staff ~ $_ ; sudo chmod -R u+rwX ~ $_ ; chmod -R -N ~ $_ ; } 2> /dev/null
Launch the Terminal application in any of the following ways:
☞ Enter the first few letters of its name into a Spotlight search. Select it in the results (it should be at the top.)
☞ In the Finder, select Go ▹ Utilities from the menu bar, or press the key combination shift-command-U. The application is in the folder that opens.
☞ Open LaunchPad. Click Utilities, then Terminal in the icon grid.
Paste into the Terminal window (command-V). You'll be prompted for your login password, which won't be displayed when you type it. You may get a one-time warning not to screw up. If you don’t have a login password, you’ll need to set one before you can run the command. If you see a message that your username "is not in the sudoers file," then you're not logged in as an administrator.
The command will take a noticeable amount of time to run. Wait for a new line ending in a dollar sign (“$”) to appear, then quit Terminal.
Step 2 (optional)
The first step should give you usable permissions in your home folder. This step will restore special attributes set by OS X on some user folders to protect them from unintended deletion or renaming. You can skip this step if you don't consider that protection to be necessary.
Boot into Recovery by holding down the key combination command-R at startup. Release the keys when you see a gray screen with a spinning dial.
When the OS X Utilities screen appears, select
Utilities ▹ Terminal
from the menu bar. A Terminal window will open.
In the Terminal window, type this:
resetpassword
That's one word, all lower case, with no spaces. Then press return. A Reset Password window will open. You’re not going to reset a password.
Select your boot volume ("Macintosh HD," unless you gave it a different name) if not already selected.
Select your username from the menu labeled Select the user account if not already selected.
Under Reset Home Directory Permissions and ACLs, click the Reset button.
Select
 ▹ Restart
from the menu bar.

[SOLVED] network unreachable inside the container

I managed a container with systemd-nspawn. The container boots, but the network is unreachable.
Below is my set up.
ON HOST
systemd-dhcpcd.service disable
systemd-networkd is enabled and started
network is started with two netctl profiles
Configuration files:
/etc/netctl/static-hortensia
Description='hortensia static ethernet connection'
Interface=enp7s0
Connection=ethernet
IP=static
Address=('192.168.1.87/24')
Gateway='192.168.1.254'
/etc/netctl/bridge-hortensia
Description="Bridge connection to container"
Interface=br0
Connection=bridge
BindsToInterfaces=()
IP=no
/etc/systemd/network/70-dahlia.netdev
[Match]
Host=host0
Virtualization=container
[NetDev]
Name=br0
Kind=bridge
/etc/systemd/network/80-dahlia.network
[Match]
Virtualization=container
[Network]
DHCP=no
DNS=192.168.1.254
[Address]
Address=192.168.1.94/24
[Route]
Gateway=192.168.1.254
/etc/resolv.conf
# Generated by resolvconf
domain lan
nameserver 192.168.1.254
BEFORE I start the container:
$ ip addr
2: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.87/24 brd 192.168.1.255 scope global enp7s0
valid_lft forever preferred_lft forever
inet6 fe80::16da:e9ff:feb5:7a88/64 scope link
valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/ether 9e:eb:1a:c5:12:34 brd ff:ff:ff:ff:ff:ff
inet6 fe80::9ceb:1aff:fec5:1234/64 scope link
valid_lft forever preferred_lft forever
start the container
# systemd-nspawn --machine=dahlia --network-bridge=br0 -bD /dahlia
$ ip addr
2: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.87/24 brd 192.168.1.255 scope global enp7s0
valid_lft forever preferred_lft forever
inet6 fe80::16da:e9ff:feb5:7a88/64 scope link
valid_lft forever preferred_lft forever
3: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 92:3c:ba:9e:24:07 brd ff:ff:ff:ff:ff:ff
inet6 fe80::9ceb:1aff:fec5:1234/64 scope link
valid_lft forever preferred_lft forever
4: vb-dahlia: <BROADCAST,MULTICAST> mtu 1500 qdisc noop master br0 state DOWN group default qlen 1000
ON CONTAINER
systemd-dhcpcd.service disable
systemd-networkd is enabled and started
NO netctl profiles
NO conf files in /etc/systemd/network/
gab@dahlia ➤➤ ~ % ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 192.168.1.94/24 brd 192.168.1.255 scope global lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: host0: <NO-CARRIER,BROADCAST,ALLMULTI,AUTOMEDIA,NOTRAILERS,UP> mtu
1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 3a:4f:1f:c5:b5:d1 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.94/24 brd 192.168.1.255 scope global host0
valid_lft forever preferred_lft forever
Not sure this output is correct. Is it OK to get a IP adress for lo ? Then, interface host0 is DOWN. I guess this is not normal and could be the cause of my issue.
# ip link set dev host0 up
produces no change, host0 is still down
gab@dahlia ➤➤ ~ % ip route
default via 192.168.1.254 dev host0
192.168.1.0/24 dev host0 proto kernel scope link src 192.168.1.94
gab@dahlia ➤➤ ~ % ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.1.94 icmp_seq=1 Destination Host Unreachable
Configuration files :
/etc/resolv.conf
# Generated by resolvconf
domain lan
nameserver 192.168.1.254
/etc/hosts
# /etc/hosts: static lookup table for host names
#<ip-address> <hostname.domain.org> <hostname>
127.0.0.1 localhost.localdomain localhost
::1 localhost.localdomain localhost
# End of file
Maybe some error here? localhost ? (host0 ?)
Some debug command outputs:
gab@dahlia ➤➤ ~ # SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd
timestamp of '/etc/systemd/network' changed
timestamp of '/run/systemd/network' changed
host0: link (with ifindex 2) added
lo: link (with ifindex 1) added
Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a
Got message type=method_return sender=org.freedesktop.DBus destination=:1.6 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a
Got message type=signal sender=org.freedesktop.DBus destination=:1.6 object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 error=n/a
gab@dahlia ➤➤ ~ % ip route
default via 192.168.1.254 dev host0
192.168.1.0/24 dev host0 proto kernel scope link src 192.168.1.94
gab@dahlia ➤➤ ~ % cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
host0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
lo: 840 9 0 0 0 0 0 0 840 9 0 0 0 0 0 0
Same command ON HOST
gabx@hortensia ➤➤ ~ % cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
br0: 0 0 0 0 0 0 0 0 648 8 0 0 0 0 0 0
vb-dahlia: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
lo: 1700 34 0 0 0 0 0 0 1700 34 0 0 0 0 0 0
enp7s0: 15403401 19789 0 0 0 0 0 0 3834189 16721 0 0 0 0 0 0
gab@dahlia ➤➤ ~ % ping -c3 192.168.1.254
PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data.
64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=0.036 ms
I can ping the gateway.
Any help is appreciated.
Last edited by gabx (2014-03-06 22:15:07)

After a few more test, I have a profile UP in the container, with an IP adress, but network is still unreachable.
The output of the following command puzzles me:
gab@dahlia ➤➤ /etc/netctl % cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
host0: 6004 28 0 0 0 0 0 0 774 11 0 0 0 0 0 0
lo: 336 3 0 0 0 0 0 0 336 3 0 0 0 0 0 0
It seems there is some traffic going through host0.
some debug outputs on the container side
gab@dahlia ➤➤ /etc/netctl % ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: host0: <BROADCAST,ALLMULTI,AUTOMEDIA,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 8e:d4:16:e2:06:4a brd ff:ff:ff:ff:ff:ff
inet 192.168.1.91/24 brd 192.168.1.255 scope global host0
valid_lft forever preferred_lft forever
inet6 fe80::8cd4:16ff:fee2:64a/64 scope link
valid_lft forever preferred_lft forever
gab@dahlia ➤➤ /etc/netctl % ip route
default via 192.168.1.254 dev host0
192.168.1.0/24 dev host0 proto kernel scope link src 192.168.1.91
gab@dahlia ➤➤ /etc/netctl % cat /etc/resolv.conf
# Generated by resolvconf
nameserver 192.168.1.254
Maybe a stupid question, but in case of my bridge, what device is the gateway : the host machine (192.168.1.87) OR the real router (192.168.1.254) ? I could be wrong when trying to indicate the router as the gateway ?
EDIT
Trying to use the host as gateway does not change anything: network still unreachable
More debug outputs.
on the container side
gab@dahlia ➤➤ ~ % ping -c3 192.168.1.254
PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data.
64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=0.044 ms
64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=0.035 ms
64 bytes from 192.168.1.254: icmp_seq=3 ttl=64 time=0.027 ms
--- 192.168.1.254 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.027/0.035/0.044/0.008 ms
gab@dahlia ➤➤ ~ % ping -c3 192.168.1.87
PING 192.168.1.87 (192.168.1.87) 56(84) bytes of data.
64 bytes from 192.168.1.87: icmp_seq=1 ttl=64 time=0.041 ms
64 bytes from 192.168.1.87: icmp_seq=2 ttl=64 time=0.036 ms
64 bytes from 192.168.1.87: icmp_seq=3 ttl=64 time=0.036 ms
--- 192.168.1.87 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.036/0.037/0.041/0.007 ms
I can ping gateway and host
on host side
gabx@hortensia ➤➤ systemd/network % ping -c3 192.168.1.94
PING 192.168.1.94 (192.168.1.94) 56(84) bytes of data.
From 192.168.1.87 icmp_seq=1 Destination Host Unreachable
From 192.168.1.87 icmp_seq=2 Destination Host Unreachable
From 192.168.1.87 icmp_seq=3 Destination Host Unreachable
--- 192.168.1.94 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2008ms
pipe 3
I can not ping container
Last edited by gabx (2014-03-04 12:07:32)

Automounting smb share without network daemon

Hello everyone, I have an issue. I'm using networkmanager to manage wireless connections. While installing networkmanger, the wiki told you must remove network daemon from rc.conf, and use networkmanager instead: that's exactly what I did, and networkmanager does the job just well. I told you that because I think that it is the reason why i'm failing to auto mount smb share through editing fstab. If i put in fstab the command described on the wiki (cisf mounting) I get a FAIL at booting, it says it can't find the share. Otherwise am I wrong and the reason must be related to something else, like syntax errors? Thank you.

Trying to follow your advice, I did the following: I put into /etc/fstab
//server/Videos$ /mnt/video cifs noauto,noatime,username=Y3KNET/Arch,password=Ilove69,ip=192.168.1.1 0 0
//server/Public$ /mnt/public cifs noauto,noatime,username=Y3KNET/Arch,password=Ilove69,ip=192.168.1.1 0 0
then, in /etc/rc.local:
mount /mnt/video
mount /mnt/public
and, as a second try,
sudo mount /mnt/video
sudo mount /mnt/public
but without luck: no mount actually takes place. Anyway, if i type the above code after logon into kde, everything works flawlessly. Where am I mistaken?
Last edited by Y3k (2011-12-03 23:06:36)

Help! How do I know the Oracle daemon started on Linux.

Dear Madem/Sir!
I had installed the Oracle 9.2 on the Red Hat Linux 8.0 platform.
But how do I know the Oracle Daemon started when the Linux startup?
Please help me to figure out it!
thanks and regards,
Janus
[email protected]

A couple of ways, but easiest is to run the command "ps -ef" at a shell prompt. It will tell you which processes are running on your server. If oracle is running, you should see several oracle processes.
You may also try running "sqlplus" and see if it will let you connect to the database. Generally, if you try to run SQL*Plus and the database is not started, you will get an error message to that effect.

[solved]Network fails to start sometimes

Hello!
I'm having a problem with my network. Sometimes it fails to start. Usually, a reboot solves this. Here is the error log:
[root@claudia log]# cat errors.log
Aug 6 03:16:28 claudia dhcpcd[3194]: dhcpStart: interface eth0 is not Ethernet or 802.2 Token Ring
rc.conf:
# NETWORKING
HOSTNAME="claudia"
# Interfaces to start at boot-up (in this order)
# Declare each interface then list in INTERFACES
# - prefix an entry in INTERFACES with a ! to disable it
# - no hyphens in your interface names - Bash doesn't like it
# Note: to use DHCP, set your interface to be "dhcp" (eth0="dhcp")
lo="lo 127.0.0.1"
eth0="dhcp"
INTERFACES=(lo eth0)
# Routes to start at boot-up (in this order)
# Declare each route then list in ROUTES
# - prefix an entry in ROUTES with a ! to disable it
gateway="default gw 192.168.1.1"
ROUTES=(!gateway)
hosts:
[root@claudia log]# cat /etc/hosts
# /etc/hosts: static lookup table for host names
#<ip> <hostname> <hostname>
127.0.0.1 localhost.localdomain localhost claudia
# End of file
What should I do to solve this?
Thanks and regards,
Gustavo

I'd say it's because since the ethernet over firewire module is loaded too, it's counted as a network device too - and which one gets to be eth0 depends if the NIC or ethernet over firewire module is loaded first. There are many solutions to this:
1) If you don't need ethernet over firewire, keep it from being loaded by putting the module name (eth1394 I think) in MOD_BLACKLIST in /etc/rc.conf, like this:
MOD_BLACKLIST=(eth1394)
2) You can make both eth0 and eth1 (and perhaps other NICs too) start up together (I do this with my 2 NICs). To do that, make the rc.conf network section something like this:
lo="lo 127.0.0.1"
eth0="dhcp"
eth1="dhcp"
INTERFACES=(lo eth0 eth1)
Then you should put a @ in front of "network" ( @network ) in the DAEMONS array unless you like waiting for a NIC that won't start

[SOLVED] Network daemon starting slowly

Similar Messages

Maybe you are looking for