Bug 735617
Summary: | /etc/ethers ignored | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | nucleo <alekcejk> |
Component: | net-tools | Assignee: | Jiri Popelka <jpopelka> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 16 | CC: | harald, iprikryl, johannbg, jpopelka, kay, lpoetter, metherid, mschmidt, notting, plautrba, vchepkov |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | net-tools-1.60-126.fc16 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-02-08 23:00:22 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
nucleo
2011-09-04 08:29:00 UTC
If I restart arp-ethers.service after system boot finished entries from /etc/ethers applied so maybe arp-ethers.service should be started later after network service. So arp-ethers.service is from net-tools and Fedora 16 now have net-tools-1.60-122.fc16 This arp-ethers.service works for me: [Unit] Description=Load static arp entries ConditionPathExists=/etc/ethers DefaultDependencies=no After=shutdown.target network.target [Service] Type=oneshot ExecStart=/sbin/arp -f /etc/ethers RemainAfterExit=yes [Install] WantedBy=multi-user.target And maybe no sense to run it on shutdown? Yes, arp-ethers.service has been added to net-tools recently due to bug #713759. However it would be great if somebody in CC (i.e. somebody more acquainted with systemd) could take a quick look at the original service file [1] and suggested solution (comment #3) to advice me what could be the correct solution to this problem. Thanks! [1] http://pkgs.fedoraproject.org/gitweb/?p=net-tools.git;a=blob_plain;f=arp-ethers.service Nucleo is currently testing this one... [Unit] Description=Load static arp entries ConditionPathExists=/etc/ethers DefaultDependencies=on After=network.target [Service] Type=oneshot ExecStart=/sbin/arp -f /etc/ethers RemainAfterExit=yes [Install] WantedBy=multi-user.target Yes, I tested this one (only with DefaultDependencies=false) and it works for me too. Removed default dependency line since it's no longer needed ( was there probably for shutdown target ) and added syslog.target this should be final version. [Unit] Description=Load static arp entries ConditionPathExists=/etc/ethers After=syslog.target network.target [Service] Type=oneshot ExecStart=/sbin/arp -f /etc/ethers RemainAfterExit=yes [Install] WantedBy=multi-user.target Last one also works. (In reply to comment #8) > After=syslog.target network.target I don't think specifying syslog.target is necessary anymore. In F16 we depend on a socket-activated syslog implementation. You probably want services that depend on network.target to be able to rely on the ARP entries being loaded already. This ordering does not guarantee that. This would: After=network.service Before=network.target How does loading the ARP entries work when NetworkManager is used and interfaces are expected to go up and down at any time? Does NM itself load the ARP entries? (In reply to comment #10) > (In reply to comment #8) > > After=syslog.target network.target > > I don't think specifying syslog.target is necessary anymore. In F16 we depend > on a socket-activated syslog implementation. I always do encase this can be pushed upstream and distribution might be running older version of systemd than what we have in Fedora + I doubt that the unit could be used on F15 without it there given the current systemd version there. This should work. But maybe some other solution should be used because static arp entries should be applied somewhere in the middle of interface initialization after interface already up but address not set yet or before gateway reachability checked (gateway address maybe one of static arp entries). This bug also prevents automatic start of sshd.service for me To make Vadym Chepkov's report more specific: The bug is that the wrong ordering dependencies of arp-ethers.service as shipped in F16 cause ordering cycles, which systemd resolves by dropping services from the cycle (sshd being one of the victims). Is a new version of net-tools going to be submitted as an update soon? net-tools-1.60-126.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/net-tools-1.60-126.fc16 Package net-tools-1.60-126.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing net-tools-1.60-126.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-1062/net-tools-1.60-126.fc16 then log in and leave karma (feedback). net-tools-1.60-126.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. |