On 01/03/2018 04:53 PM, Rick Stevens wrote:
As a network admin, I can see no reason to remove a fixed IP address
from a NIC based on whether or not there's a carrier present. Even in
the case of DHCP, unless the address lease expires between a disconnect
and reconnect or there's pressure on the D
Once upon a time, Rick Stevens said:
> Now, if we want one of the uplinks to remain unavailable, it is marked
> "administratively down" (in Cisco IOS-speak). For Linux, this would
> essentially be "ip link dev down". This takes the link down,
> but doesn't change the IP address for it.
The diffe
On 01/01/2018 03:09 AM, Roberto Ragusa wrote:
> On 12/24/2017 10:00 PM, Chris Adams wrote:
>> Once upon a time, Sam Varshavchik said:
>>> I defy anyone to identify a tangible benefit that comes from
>>> removing a static IP address from a port when it loses carrier, and
>>> installing one only onc
On 12/24/2017 10:00 PM, Chris Adams wrote:
> Once upon a time, Sam Varshavchik said:
>> I defy anyone to identify a tangible benefit that comes from
>> removing a static IP address from a port when it loses carrier, and
>> installing one only once a carrier is present.
>
> It is useful for system
Once upon a time, Sam Varshavchik said:
> I defy anyone to identify a tangible benefit that comes from
> removing a static IP address from a port when it loses carrier, and
> installing one only once a carrier is present.
It is useful for systems with multiple interfaces, for example a desktop
wi
Roberto Ragusa writes:
On 12/21/2017 06:28 PM, Gordon Messmer wrote:
> Because NetworkManager is an event-driven system. If an interface loses
carrier for a defined period of time (5 seconds prior to the commit I've
referenced), NM will remove the IP configuration from that interface.
An
On 12/21/2017 06:28 PM, Gordon Messmer wrote:
> Because NetworkManager is an event-driven system. If an interface loses
> carrier for a defined period of time (5 seconds prior to the commit I've
> referenced), NM will remove the IP configuration from that interface.
And this is one of the most
Marmorstein, Robert writes:
NetworkManager-wait-online is to make sure that remote drives mount
AFTER an IP address has been configured:
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
That's exactly the use case that's broken here.
By the way, my own experiments (on a lab of
On 12/23/2017 11:54 AM, Marmorstein, Robert wrote:
I agree that the nm-online manpage is confusing. My experiments seem to
indicate
that perhaps "active" means the network interface is "up" in the sense that the
interface is listening for data-link layer (i.e. Ethernet) frames. It doesn't
see
> I would have thought something with "wait online" in its name would
> actually wait for it to be on-line. To me, "on-line" means connected
> and operational. Starting up but not actually on-line, isn't on-line.
I find it interesting that freedesktop.org suggests that the entire purpose of
Netwo
Tom Horsley writes:
On Sat, 23 Dec 2017 10:50:44 -0500
Sam Varshavchik wrote:
> Maybe, perhaps, this approach should've made sense to do so only when NM
> actually was able to support all the functionality it was taking over?
How's
> that for a crazy idea? Does anyone think I'm being complet
On Sat, 23 Dec 2017 10:50:44 -0500
Sam Varshavchik wrote:
> Maybe, perhaps, this approach should've made sense to do so only when NM
> actually was able to support all the functionality it was taking over? How's
> that for a crazy idea? Does anyone think I'm being completely off-base and
> u
Gordon Messmer writes:
I understand what you're saying. It's just that static configuration isn't
what NM does. The old network service does, and I sincerely hope no one
ever suggests deprecating the network service unless NM offers that mode of
operation, which it does not, today.
I'm
On 12/21/2017 10:05 AM, Tom Horsley wrote:
It's just that static configuration isn't what NM does.
Which always struck me as very odd considering that redhat
sponsors most of this stuff and mostly makes money off
servers
Mostly, yes. They do have some desktop people, and sponsor GNOME
devel
On Thu, 21 Dec 2017 09:28:27 -0800
Gordon Messmer wrote:
> It's just that static configuration
> isn't what NM does.
Which always struck me as very odd considering that redhat
sponsors most of this stuff and mostly makes money off
servers which almost always have static configurations
that never
On 12/21/2017 04:17 AM, Sam Varshavchik wrote:
I'm not sure I see why this has to be a factor.
Because NetworkManager is an event-driven system. If an interface loses
carrier for a defined period of time (5 seconds prior to the commit I've
referenced), NM will remove the IP configuration fro
francis.montag...@inria.fr writes:
Hi.
On Thu, 21 Dec 2017 07:17:38 -0500 Sam Varshavchik wrote:
> I just did a little experiment. I took a different server with an unused
> port. I assigned an IP address to it, in its ifcfg file, then ifup-ed it.
> The result:
> 3: eth1:
> I then tested t
Hi.
On Thu, 21 Dec 2017 07:17:38 -0500 Sam Varshavchik wrote:
> I just did a little experiment. I took a different server with an unused
> port. I assigned an IP address to it, in its ifcfg file, then ifup-ed it.
> The result:
> 3: eth1:
> I then tested this using my script. I can bind it
Gordon Messmer writes:
On 12/20/2017 03:44 AM, Sam Varshavchik wrote:
No managed switches here. Just some dumb switch with a bunch of stuff
plugged into it.
Surprising, but the outcome is the same. You have a switch and a NIC which,
in concert, take a long time to negotiate a link, and t
On 12/20/2017 03:44 AM, Sam Varshavchik wrote:
No managed switches here. Just some dumb switch with a bunch of stuff
plugged into it.
Surprising, but the outcome is the same. You have a switch and a NIC
which, in concert, take a long time to negotiate a link, and that's a
problem for Netwo
On Tue, 2017-12-19 at 17:37 -0500, Sam Varshavchik wrote:
> Justin Moore writes:
>
> > I interpret "-s" to mean "all interfaces are active but do not necessarily
> > have an address or a default route". This means that NM will return success
>
> What does it mean for an interface that has a sta
On 20 Dec 2017 04:54, "Gordon Messmer" wrote:
On 12/19/2017 04:46 PM, Sam Varshavchik wrote:
>
> That's the big picture. And looks like it's completely impossible to do
> that, in stock Fedora.
>
Right now, yes. And that's completely and entirely down to NetworkManager
bringing interfaces up
Gordon Messmer writes:
On 12/19/2017 04:46 PM, Sam Varshavchik wrote:
That's the big picture. And looks like it's completely impossible to do
that, in stock Fedora.
Right now, yes. And that's completely and entirely down to NetworkManager
bringing interfaces up in an event-driven fashi
I've filed an RFE:
https://bugzilla.redhat.com/show_bug.cgi?id=1527768
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
On 12/19/2017 04:46 PM, Sam Varshavchik wrote:
That's the big picture. And looks like it's completely impossible to
do that, in stock Fedora.
Right now, yes. And that's completely and entirely down to
NetworkManager bringing interfaces up in an event-driven fashion, when
link is detected.
Gordon Messmer writes:
Thanks, Sam, that looks like very useful information. The logs you posted
indicate that one interface, eno1, had no link when "ip addr show" ran,
after NetworkManager reported itself online. This seems consistent with nm-
online's man page which indicates that startu
Thanks, Sam, that looks like very useful information. The logs you
posted indicate that one interface, eno1, had no link when "ip addr
show" ran, after NetworkManager reported itself online. This seems
consistent with nm-online's man page which indicates that startup is
complete when all conn
Louis Lagendijk writes:
> Running diff on them shows pretty much the only differences you
> would
> expect: NAME, UUID, HWADDR, IPADDR*, PREFIX*, GATEWAY, and DNS* are
> different. In terms of everything else, the config is the samen
what happens if you change this to yes? Does nm-online then w
Justin Moore writes:
I interpret "-s" to mean "all interfaces are active but do not necessarily
have an address or a default route". This means that NM will return success
What does it mean for an interface that has a static IP address explicitly
specified in its ifcfg file to be "active",
Joe Zeff writes:
On 12/19/2017 11:27 AM, Sam Varshavchik wrote:
"Wait for NetworkManager startup to complete, rather than waiting for
network connectivity specifically. Startup is considered complete once
NetworkManager has activated (or attempted to activate) every auto-activate
connect
On Tue, 2017-12-19 at 14:14 -0500, Sam Varshavchik wrote:
> Louis Lagendijk writes:
>
> > One question that has been bugging me for some time now: I wonder
> > if
> > nm-online checks for IP-addressing only when the "require ipv4
> > addressing for this connection to complete" option nm-connectio
Sam,
Here's my understanding of the situation:
* a network interface can either be active/started -- i.e., is in the "up"
state, without necessarily having a network address -- or connected --
i.e., having an address; and
* a system can have multiple network interfaces.
I interpret "-s" to mean
On 12/19/2017 11:27 AM, Sam Varshavchik wrote:
"Wait for NetworkManager startup to complete, rather than waiting for
network connectivity specifically. Startup is considered complete once
NetworkManager has activated (or attempted to activate) every
auto-activate connection which is available
Dr J Austin writes:
I have read the nm-online man page about 10 times and I am still not
clear what it is telling me.
The way I parse it, without -s it waits until at least one network
connection is present. With the option, it should wait until all connections
are up. The man page starts
Louis Lagendijk writes:
One question that has been bugging me for some time now: I wonder if
nm-online checks for IP-addressing only when the "require ipv4
addressing for this connection to complete" option nm-connection-
editor (which I guess results in IPV4_FAILURE_FATAL=yes being set in
the
On Tue, 2017-12-19 at 07:16 -0500, Sam Varshavchik wrote:
> Gordon Messmer writes:
>
> > On 12/18/2017 05:52 AM, Sam Varshavchik wrote:
> > > Time IP addresses
> > > ==
> > > 08:35:34
> > > 08:35:35 192.168.0.1
> > >
> > > At 08:35:34 the server had no IP addresses
> >
>
On Tue, 2017-12-19 at 07:16 -0500, Sam Varshavchik wrote:
> Gordon Messmer writes:
>
> > On 12/18/2017 05:52 AM, Sam Varshavchik wrote:
> > > Time IP addresses
> > > ==
> > > 08:35:34
> > > 08:35:35 192.168.0.1
> > >
> > > At 08:35:34 the server had no IP addresses
> >
>
On 19 Dec 2017 07:49, wrote:
On Mon, 18 Dec 2017 14:12:55 -0800 Gordon Messmer wrote:
> On 12/17/2017 01:17 PM, francis.montag...@inria.fr wrote:
>>Dec 17 21:32:59 X systemd[1]: Mounting /data2...
>>Dec 17 21:33:19 X mount[996]: mount to NFS server 'Y' failed:
Resource temporarily unavai
On Tue, 19 Dec 2017 07:25:46 -0500 Tom Horsley wrote:
> On Tue, 19 Dec 2017 20:16:51 +0800
>> FWIW, are you aware that you shouldn't make changes to
>> /usr/lib/systemd/system/* files? These can be overwritten up
>> updates.
Yes yes, but we are debugging.
>> If you want to make changes you sho
On Tue, 19 Dec 2017 20:16:51 +0800
Ed Greshko wrote:
> FWIW, are you aware that you shouldn't make changes to
> /usr/lib/systemd/system/*
> files? These can be overwritten up updates. If you want to make changes you
> should
> created a file with the same name in /etc/systemd/system.
And wh
On 12/19/17 19:17, Dr J Austin wrote:
> On Mon, 2017-12-18 at 19:24 -0500, Sam Varshavchik wrote:
>> Gordon Messmer writes:
>>
>>> On 12/18/2017 05:52 AM, Sam Varshavchik wrote:
Time IP addresses
==
08:35:34
08:35:35 192.168.0.1
At 08:35:34 the
Gordon Messmer writes:
On 12/18/2017 05:52 AM, Sam Varshavchik wrote:
Time IP addresses
==
08:35:34
08:35:35 192.168.0.1
At 08:35:34 the server had no IP addresses
Well, it probably had 127.0.0.1, which brings into question what the
complete state of the network w
On Mon, 2017-12-18 at 19:24 -0500, Sam Varshavchik wrote:
> Gordon Messmer writes:
>
> > On 12/18/2017 05:52 AM, Sam Varshavchik wrote:
> > > Time IP addresses
> > > ==
> > > 08:35:34
> > > 08:35:35 192.168.0.1
> > >
> > > At 08:35:34 the server had no IP addresses
> >
>
On Mon, 18 Dec 2017 14:12:55 -0800 Gordon Messmer wrote:
> On 12/17/2017 01:17 PM, francis.montag...@inria.fr wrote:
>>Dec 17 21:32:59 X systemd[1]: Mounting /data2...
>>Dec 17 21:33:19 X mount[996]: mount to NFS server 'Y' failed: Resource
>> temporarily unavailable, retrying
>>Dec 1
Gordon Messmer writes:
On 12/18/2017 05:52 AM, Sam Varshavchik wrote:
Time IP addresses
==
08:35:34
08:35:35 192.168.0.1
At 08:35:34 the server had no IP addresses
Well, it probably had 127.0.0.1, which brings into question what the
complete state of the network w
On 12/18/2017 05:52 AM, Sam Varshavchik wrote:
Time IP addresses
==
08:35:34
08:35:35 192.168.0.1
At 08:35:34 the server had no IP addresses
Well, it probably had 127.0.0.1, which brings into question what the
complete state of the network was.
Could you arrange to
On 12/17/2017 01:17 PM, francis.montag...@inria.fr wrote:
On Sun, 17 Dec 2017 11:49:39 -0800 Gordon Messmer wrote:
In order to determine that, someone who can reproduce the problem needs
to revert that specific change on their system.
With that declaration in /etc/fstab:
Y:/data2 /data2
On Mon, 18 Dec 2017 09:56:03 -0700
stan wrote:
> Boot went to multi-threaded, and so
> became non-deterministic, in order to shorten boot time.
And that has saved oh so much time compared to the time
every sysadmin has spent fighting with it :-).
___
us
On Mon, 2017-12-18 at 09:56 -0700, stan wrote:
> On Mon, 18 Dec 2017 07:19:02 -0500
> Sam Varshavchik wrote:
>
> > When we had initiscripts, I forget which one it was, but there was
> > one that read all the config files, and enabled those interfaces. And
> > stuff that depended on the network be
On Mon, 18 Dec 2017 07:19:02 -0500
Sam Varshavchik wrote:
> When we had initiscripts, I forget which one it was, but there was
> one that read all the config files, and enabled those interfaces. And
> stuff that depended on the network being up ran after that. Simple.
> Easy. So, again: is it unr
Sam Varshavchik writes:
a well-defined point when the system boots, then, I guess we can reach the
conclusion that NetworkManager is totally incapable of accomplishing basic
networking administration tasks, and move on to consider ugly hacks like
https://github.com/svarshavchik/unfrak-syste
Allegedly, on or about 18 December 2017, Cameron Simpson sent:
> NetworkManager-wait-online may not be doing what people had hoped.
I would have thought something with "wait online" in its name would
actually wait for it to be on-line. To me, "on-line" means connected
and operational. Starting u
Cameron Simpson writes:
On 17Dec2017 18:05, sam varshavchik wrote:
But I really don't understand why so much research is needed for this issue,
by disabling random things, and then trying other random things. Either
NetworkManager-wait-online actually waits until the network interfaces have
On Sun, Dec 17, 2017 at 2:49 PM, Gordon Messmer
wrote:
> On 12/17/2017 08:38 AM, Tom H wrote:
>>
>> Yes, it's the same thing as doing what I suggested next and you
>> snipped out.
>
> Not exactly... I'd like to know if this commit is the one that broke
> the service:
>
> https://cgit.freedesktop.o
On Sun, Dec 17, 2017 at 11:44 AM, Chris Murphy wrote:
> On Sun, Dec 17, 2017 at 8:41 AM, Dr J Austin wrote:
>> I gave up using ldap/autofs some time ago and until the last update
>> the _netdev option in fstab (or something else maybe) has been working
>> perfectly.
>>
>> 148.197.29.5:/home
On 17Dec2017 18:05, sam varshavchik wrote:
But I really don't understand why so much research is needed for this issue,
by disabling random things, and then trying other random things. Either
NetworkManager-wait-online actually waits until the network interfaces have
their IP address set, or i
Tom H writes:
Does privoxy start properly if you disable NM and its wait-online unit
and use systemd-networkd and its wait-online unit?
Does privoxy start properly if you disable NM's wait-online unit and
use a custom wait-online unit that waits until
"/sys/class/net//carrier" is "1"?
privoxy
On Sun, 17 Dec 2017 11:49:39 -0800 Gordon Messmer wrote:
> Not exactly... I'd like to know if this commit is the one that broke the
> service:
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/data/NetworkManager-wait-online.service.in?id=520d2814ba720cf8aee9d6f91fca4e3ea0d855
On 12/17/2017 08:38 AM, Tom H wrote:
Yes, it's the same thing as doing what I suggested next and you snipped out.
Not exactly... I'd like to know if this commit is the one that broke the
service:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/data/NetworkManager-wait-onli
On Sun, Dec 17, 2017 at 8:41 AM, Dr J Austin wrote:
> On Sun, 2017-12-17 at 08:20 -0500, Tom Horsley wrote:
>> On Sun, 17 Dec 2017 11:07:52 +
>> Dr J Austin wrote:
>>
>> > Anyone else with the same problem/
>>
>> I gave up on getting NFS mounts to work a long time ago.
>> I have a job I start
On Sun, Dec 17, 2017 at 11:23 AM, Gordon Messmer
wrote:
> On 12/17/2017 07:18 AM, Tom H wrote:
>>
>> I've just read "man nm-online" (possibly for the first time!) and
>> "nm-online -s" doesn't seem to do what
>> "NetworkManager-wait-online.service" is supposed to do, systemd-wise.
>> It waits "for
On 12/17/2017 07:18 AM, Tom H wrote:
I've just read "man nm-online" (possibly for the first time!) and
"nm-online -s" doesn't seem to do what
"NetworkManager-wait-online.service" is supposed to do, systemd-wise.
It waits "for NetworkManager startup to complete, rather than waiting
for network con
On Sun, 2017-12-17 at 08:20 -0500, Tom Horsley wrote:
> On Sun, 17 Dec 2017 11:07:52 +
> Dr J Austin wrote:
>
> > Anyone else with the same problem/
>
> I gave up on getting NFS mounts to work a long time ago.
> I have a job I start with "at now" in rc.local that
> delays for a few seconds th
On Sat, Dec 16, 2017 at 10:03 AM, Sam Varshavchik wrote:
>
> Just had another boot that utterly failed because services that were
> supposed to start only after the network interfaces came up, didn't. They
> started too soon. Privoxy's logfile has the smoking gun:
>
> 2017-12-16 09:42:39.875 7f4ac
Dr J Austin writes:
On Sat, 2017-12-16 at 10:03 -0500, Sam Varshavchik wrote:
> Why is it so friggin difficult to get something this simple, this basic
> concept of starting things only after the network interfaces are up,
working
> correctly, and reliably?
>
> Oh yeah, I know. systemd.
Sim
broken
In-reply-to: Your message of "Sun, 17 Dec 2017 08:20:37 -0500."
<20171217082037.2148ddd8@zooty>
On Sun, 17 Dec 2017 08:20:37 -0500 Tom Horsley wrote:
> On Sun, 17 Dec 2017 11:07:52 +
> Dr J Austin wrote:
>> Anyone else with the same problem/
> I gave up on getting NFS m
On Sun, 17 Dec 2017 11:07:52 +
Dr J Austin wrote:
> Anyone else with the same problem/
I gave up on getting NFS mounts to work a long time ago.
I have a job I start with "at now" in rc.local that
delays for a few seconds then does all the NFS mounts.
I have other commands in there as well to
On Sat, 2017-12-16 at 10:03 -0500, Sam Varshavchik wrote:
> Just had another boot that utterly failed because services that were
> supposed to start only after the network interfaces came up, didn't. They
> started too soon. Privoxy's logfile has the smoking gun:
>
> 2017-12-16 09:42:39.875 7f
Just had another boot that utterly failed because services that were
supposed to start only after the network interfaces came up, didn't. They
started too soon. Privoxy's logfile has the smoking gun:
2017-12-16 09:42:39.875 7f4acdaa6740 Fatal error: can't bind to
192.168.0.1:8000: Cannot ass
69 matches
Mail list logo
