Page 1 of 1
[Solved] F@H Kills Network On Boot Under Arch Linux
Posted: Mon Apr 14, 2014 6:18 am
by adam777
Hello all,
I just did a fresh Arch Linux installation, based on the [testing] repository and using NetworkManager under Gnome 3.12.
Upon using the system this last few days I had some weird network issues where my wireless connection would connect fine during boot, but I could not do anything, not even pinging my local router.
Spending a few fruitless hours, I finally managed to connect the issue to Folding@Home, such that if folding is enabled on boot the network is behaving as described above.
If I disable folding (by pausing it and rebooting the system, disabling the service etc.), network behaves just fine on next boot.
I really can't figure any logical connection between the two, but after several enabling and disabling I'm pretty sure Folding@Home is to blame.
I'm not sure what kind of log will be beneficial to the situation, but will be glad to test whatever is needed.
Thanks, Adam.
Re: F@H Kills Network On Boot Under Arch Linux
Posted: Mon Apr 14, 2014 6:27 am
by Jesse_V
That is extremely odd. I do know that F@h binds a couple of localhost ports but I don't see how that could be problematic based on your description. My best guess is that it's trying to open ports and initiate the FAHClient localhost server before the networking is fully ready, so it's a sort of race condition. That doesn't seem very likely though.
Re: F@H Kills Network On Boot Under Arch Linux
Posted: Mon Apr 14, 2014 8:10 am
by davidcoton
Jesse, I beg to differ. It's known that older versions of FAH (7.3.x and possibly before) on Linux, running as a service, could try to access the network before it was ready, thus failing (ever) to download GPUs.txt. That particular symptom has been fixed in 7.4.4, probably by detecting the failure and retrying until the network is up. It's possible that early access could break the network handler. I think Mr Coffland will need to take a look -- he may be able to suggest some tests.
It will be important to identify exactly which Linux builds are affected (Standard Arch? Test build? Other features?) because the absence of other reports suggests the effect, while serious, is not widespread.
David
Re: F@H Kills Network On Boot Under Arch Linux
Posted: Mon Apr 14, 2014 1:56 pm
by 7im
I'm sure Joe can build in some delay mechanism, but it's not going to be a high priority to workaround an inherent operating systems' failure to handle a standard network call. A post on the arch Linux distro forum about that failure might be more productive.
Re: F@H Kills Network On Boot Under Arch Linux
Posted: Mon Apr 14, 2014 2:48 pm
by Kurtis200200
adam777,
This suggestion may go against some other priorities you have in using NetworkManager, but I'm running arch linux [not 'testing' packages though] and foldingathome on boot and am not experiencing your issues; my network interface connection is controlled by the systemd files mentioned on the
ArchWiki, specifically the entries under 5.1.1 (for dhcpcd) and 5.2.1 (for static IP).
Specifically (I'm using static IP and wpa_supplicant to connect to a wireless network), my
[email protected] file is as follows:
Code: Select all
[user@System ~]$ cat /etc/systemd/system/network-wireless\@.service
[Unit]
Description=Wireless (MyWirelessNetwork) Connectivity (%i)
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/conf.d/network-wireless\@%i
ExecStart=/usr/bin/ip link set dev %i up
ExecStart=/usr/bin/wpa_supplicant -B -i %i -c /etc/wpa_supplicant.conf
ExecStart=/usr/bin/ip addr add ${address}/${netmask} broadcast ${broadcast} dev %i
ExecStart=/usr/bin/ip route add default via ${gateway}
ExecStop=/usr/bin/ip addr flush dev %i
ExecStop=/usr/bin/ip link set dev %i down
[Install]
WantedBy=multi-user.target
and my network@
thenameofmywifideviceunder"ip link" is as follows
Code: Select all
[user@System ~]$ cat /etc/conf.d/network@thenameofmywifideviceunder"ip link".service
address=192.168.0.77
netmask=24
broadcast=192.168.0.255
gateway=192.168.0.1
My guess is that since systemd in my case is handling the wireless connection, it happens early enough in boot that I'm not experiencing the same problems you are
Re: F@H Kills Network On Boot Under Arch Linux
Posted: Mon Apr 14, 2014 3:15 pm
by bruce
Adam777, I don't think you're going to find the help you need. We can bet that Mr.vCoffland doesn't have an Arch Linux system so he can't test out your problem. Moreover, Arch is not on the list of supported versions, so when he sends a bill for his services to the folks at Stanford, he's not going to get paid. I'm afraid you're on your own with a little help from volunteers here on the forum like Kurtis and Jesse.
Jesse_V wrote:That is extremely odd. I do know that F@h binds a couple of localhost ports but I don't see how that could be problematic based on your description. My best guess is that it's trying to open ports and initiate the FAHClient localhost server before the networking is fully ready, so it's a sort of race condition. That doesn't seem very likely though.
Yes, it's likely that FAH is trying to download GPUs.txt before the network is ready. That part of the FAH code ans not changed. FAH will then stop trying for long enough for the network to get started once it sees a network error. (The part that changed is that now it tries again later -- I think it waits 5 minutes before trying again.)
Re: F@H Kills Network On Boot Under Arch Linux
Posted: Mon Apr 14, 2014 7:08 pm
by Kurtis200200
I'm also happy to provide more-live support via private messages or IRC; Arch Linux has been to me a cruel partner, but is also probably my favorite operating system for 24/7 crunching and folding to-date.
Re: F@H Kills Network On Boot Under Arch Linux
Posted: Mon Apr 14, 2014 8:44 pm
by bruce
Kurtis200200 wrote:I'm also happy to provide more-live support via private messages or IRC; Arch Linux has been to me a cruel partner, but is also probably my favorite operating system for 24/7 crunching and folding to-date.
If you use PM/IRC, you'll only be helping one person. As a general rule, it's better to post the suggestions since others may have the same problem.
Re: F@H Kills Network On Boot Under Arch Linux
Posted: Mon Apr 14, 2014 11:10 pm
by Kurtis200200
I'm afraid I'm getting mixed signals from you bruce; either there are too few people using Arch to merit a thread on this forum, in which case help should be off-forum and can benefit from being faster, or adam777 should slow down the resolution of his boot problem by conducting it on this forum for the benefit of other presumed Arch linux users
Re: F@H Kills Network On Boot Under Arch Linux
Posted: Tue Apr 15, 2014 12:58 am
by bruce
The signals are not mixed. Apparently you misunderstood.
Forum volunteers are welcome to help people with unsupported versions of Linux. I've moved this topic to the forum specifically dealing with unsupported Linux Distros where the discussion can continue until it's solved.
Stanford specifies which Distros they're able to support and Arch doesn't happen to be one of them. That does not mean FAH won't run on on them, only that the professional programmers who are hired by Stanford won't be able to fix things discovered through volunteer-based-support unless they also apply to Debian,Mint,Ubuntu,Redhat,Centos, or Fedora.
Re: F@H Kills Network On Boot Under Arch Linux
Posted: Tue Apr 15, 2014 8:18 am
by adam777
Thanks all for pointing me in the right direction.
It indeed seems like some weird race condition.
To sort things out, I've created a simple systemd timer to delay the start of the folding service after boot and everything seems to work fine
Code: Select all
[Unit]
Description=Delay foldingathome service
[Timer]
OnBootSec=5min
Unit=foldingathome.service
[Install]
WantedBy=multi-user.target
Re: [Solved] F@H Kills Network On Boot Under Arch Linux
Posted: Tue Apr 15, 2014 8:26 am
by Jesse_V
Very nice, looks like we all win the prize here!
Thanks for posting the script, we can keep it in mind next time.