Re: [systemd-devel] Network Interface Names: solution for a desktop OS
16.04.2016 03:14, Reindl Harald пишет: > > > Am 15.04.2016 um 21:06 schrieb Xen: >> If you cannot give me a default mapping automatically, why not allow me >> to generate one easily? Is there a tool that can take the current device >> and produce the list I proposed? > > just use network.service aka /etc/init.d/network, enter the MAC and you > are done - so what is the problem you can't solve for hundret network > devices Motherboard dies and is replaced. All your interface names disappear. This makes rather challenging affair requiring relatively high administration skills out of mundane technical task. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Am 15.04.2016 um 21:06 schrieb Xen: If you cannot give me a default mapping automatically, why not allow me to generate one easily? Is there a tool that can take the current device and produce the list I proposed? just use network.service aka /etc/init.d/network, enter the MAC and you are done - so what is the problem you can't solve for hundret network devices in the time you wrote a lot of mails? [root@srv-rhsoft:/etc/sysconfig/network-scripts]$ cat ifcfg-lan-guest DEVICE=lan-guest HWADDR=ac:16:2d:a1:74:ec TYPE=Ethernet BOOTPROTO=static ONBOOT=yes ARPCHECK=no NM_CONTROLLED=no USERCTL=no IPV6INIT=no [root@srv-rhsoft:/etc/sysconfig/network-scripts]$ cat ifcfg-lan-phone DEVICE=lan-phone HWADDR=ac:16:2d:a1:74:ef TYPE=Ethernet BOOTPROTO=static ONBOOT=yes ARPCHECK=no NM_CONTROLLED=no USERCTL=no IPV6INIT=no [root@srv-rhsoft:/etc/sysconfig/network-scripts]$ cat ifcfg-lan-tv DEVICE=lan-tv HWADDR=ac:16:2d:a1:74:ee TYPE=Ethernet BOOTPROTO=static ONBOOT=yes ARPCHECK=no NM_CONTROLLED=no USERCTL=no IPV6INIT=no [root@srv-rhsoft:~]$ ifconfig br-guest: flags=67 mtu 1500 inet 192.168.10.1 netmask 255.255.255.0 broadcast 192.168.10.255 ether 28:92:4a:2b:5d:45 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 br-lan: flags=4675 mtu 1500 inet 192.168.2.2 netmask 255.255.255.0 broadcast 192.168.2.255 ether 28:92:4a:2b:5d:44 txqueuelen 1000 (Ethernet) RX packets 200795 bytes 13539651 (12.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 361993 bytes 348652911 (332.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 br-wan: flags=67 mtu 1500 inet 62.178.103.85 netmask 255.255.255.0 broadcast 255.255.255.255 ether 00:50:8d:b5:cc:de txqueuelen 1000 (Ethernet) RX packets 19907295 bytes 13469242158 (12.5 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 8931216 bytes 2759476933 (2.5 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lan-guest: flags=4099 mtu 1500 ether ac:16:2d:a1:74:ec txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0xf798-f79f lan-phone: flags=67 mtu 1500 ether ac:16:2d:a1:74:ef txqueuelen 1000 (Ethernet) RX packets 18846 bytes 4093274 (3.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 50325 bytes 6833909 (6.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 3 device memory 0xf780-f787 lan-spare: flags=4099 mtu 1500 ether ac:16:2d:a1:74:ed txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0xf790-f797 lan-tv: flags=4099 mtu 1500 ether ac:16:2d:a1:74:ee txqueuelen 1000 (Ethernet) RX packets 1604 bytes 389611 (380.4 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 7863 bytes 1345947 (1.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0xf788-f78f lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 1 (Lokale Schleife) RX packets 677749 bytes 137663241 (131.2 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 677749 bytes 137663241 (131.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vmnet1: flags=67 mtu 1500 ether 00:50:56:c0:00:01 txqueuelen 1000 (Ethernet) RX packets 24579 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 7133198 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vmnet8: flags=4163 mtu 1500 inet 192.168.196.2 netmask 255.255.255.0 broadcast 192.168.196.255 ether 00:50:56:c0:00:08 txqueuelen 1000 (Ethernet) RX packets 3896512 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 7861144 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vpn-client: flags=4163 mtu 1472 inet 10.0.0.241 netmask 255.255.255.0 broadcast 10.0.0.255 ether 86:34:12:f1:90:ba txqueuelen 100 (Ethernet) RX packets 8755070 bytes 10502866980 (9.7 GiB) RX errors 0 dropped 17506 overruns 0 frame 0 TX packets 4827075 bytes 301197431 (287.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vpn-server: f
Re: [systemd-devel] Factoring out initctl support
On 04/15/2016 10:47 PM, Michael Biebl wrote: > 2016-04-15 19:33 GMT+02:00 Daniel Mack : >> On 04/15/2016 07:03 PM, Mike Gilbert wrote: >>> On Fri, Apr 15, 2016 at 11:43 AM, Daniel Mack wrote: On 04/15/2016 03:55 PM, Mike Gilbert wrote: >> > I'm happy to move it if others want to utilize it. I will need someone > to set me up with access to push the code, however. Great, will do. What's your GitHub handle? >>> >>> I'm floppym on github. >>> >> >> Thanks - you're now the admin of this new repository: >> >> https://github.com/systemd/systemd-initctl/ >> >> I'm happy to push the client code there once you migrated the project. >> >> >> However, I'd still like to have an Ack from Michael Biebl on the >> downstream integration of this new repository. > > Well, I guess I already explained our situation. We still need > /dev/initctl in Debian, so ripping that out means we have to provide > that some other way. > I'm not sure if a separate package (large overhead) or simply > reverting the removal is the better option here. Including the built results of systemd-initctl into your .deb packet is not a solution? Making that an extra package causes too much trouble, I totally agree. > I can only reiterate what I said before: the code is pretty isolated > so I don't see how that causes upstream any maintenance headaches and > I would volunteer to take care of any issues that are caused by that > code. > Personally I would prefer it, if we added a configure switch. This > would be off by default so we wouldn't advertise legacy cruft by > default but it would make it easier for distros which need to maintain > that level of compat support. This is an exercise in making the code base smaller and dropping support for some legacy, while still keeping support around via external packages. And initctl is a low-hanging fruit, hence the idea. Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Factoring out initctl support
2016-04-15 19:33 GMT+02:00 Daniel Mack : > On 04/15/2016 07:03 PM, Mike Gilbert wrote: >> On Fri, Apr 15, 2016 at 11:43 AM, Daniel Mack wrote: >>> On 04/15/2016 03:55 PM, Mike Gilbert wrote: > I'm happy to move it if others want to utilize it. I will need someone to set me up with access to push the code, however. >>> >>> Great, will do. What's your GitHub handle? >> >> I'm floppym on github. >> > > Thanks - you're now the admin of this new repository: > > https://github.com/systemd/systemd-initctl/ > > I'm happy to push the client code there once you migrated the project. > > > However, I'd still like to have an Ack from Michael Biebl on the > downstream integration of this new repository. Well, I guess I already explained our situation. We still need /dev/initctl in Debian, so ripping that out means we have to provide that some other way. I'm not sure if a separate package (large overhead) or simply reverting the removal is the better option here. I can only reiterate what I said before: the code is pretty isolated so I don't see how that causes upstream any maintenance headaches and I would volunteer to take care of any issues that are caused by that code. Personally I would prefer it, if we added a configure switch. This would be off by default so we wouldn't advertise legacy cruft by default but it would make it easier for distros which need to maintain that level of compat support. Ripping the code out means additional work for us and basically no gain upstream imho, aside from asthetics. So from my POV it's a NACK, as I don't see the benefits and only the additional work. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Andrei Borzenkov schreef op 13-04-16 05:39: > Yes. And I do not see how all this information is expected to be stuffed > into 14 characters available for interface name, or even less if we > account to VLAN numbers. > > I am not aware of any OS that tries to do it. All of them maintain > persistent association between interface names and hardware > characteristics; most use physical topology, but this is not really > mandatory. Interface names themselves are usually allocated on the first > come first serve basis. This gives reasonable behavior for small systems > (where existing interface will always get the same name irrespectively > of how it is connected) and stable names for large systems. > > That is what we used in the past as well in form of udev rules. And any > answer "but you can easily disable predictable names" is hypocritical > because the whole infrastructure to maintain such name database was > ripped out, so anyone who disables predictable names is forced to > reinvent the wheel and reimplement it. Which by far exceeds what average > user is capable of. So average user simply has no choice. What you are saying is that most OSes keep a record on disk of an association they have chosen at some point in time, right. And that you can either use physical topology for this, but other device identification measures are possible too. The thing what I am currently thinking just comes down on three things: 1. an interface name is not the place where a hardware address needs to be registered, kept, maintained, or encoded. The name itself must be an alias. 2. this alias is the place to find and access the root device, if any device is configured with multiple ports or virtual devices/ports, that is an addressing following the resolution of the alias, not as part of it 3. persistent mapping may be preferable. But if the mapping is going to be redone at every boot, at least make it reasonably persistent across reboots, but don't expect it to be the holy grail. If people need a truly persistent mapping for persistent hardware (addresses) they should create it themselves or operating system software should cater to its configuration. For instance. If you cannot give me a default mapping automatically, why not allow me to generate one easily? Is there a tool that can take the current device and produce the list I proposed? Is there anything against me using that list as a persistent mapping I device myself? Can this be automated? Is there a way to generate a (udev) config that will bind my network device (ep3s0, for instance) to eth0 or ethernet0? Is any of this made easier? Udev rules are persistent mappings, or could be. Why not have an operating system installer generate this persistent mapping? Andrei suggests that you can't: > And any answer "but you can easily disable predictable names" is > hypocritical because the whole infrastructure to maintain such name > database was ripped out, so anyone who disables predictable names is > forced to reinvent the wheel and reimplement it. Which by far exceeds > what average user is capable of. So average user simply has no choice. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Greg KH schreef op 13-04-16 05:04:
> On Wed, Apr 13, 2016 at 02:42:29AM +0200, Xen wrote:
>> When you say that probing on the PCI bus never ends, and if we are
>> talking not about some form of hotplugging, then I really wonder what
>> you're on about ;-) because I do think the kernel has a limited set of
>> probes that it can perform, and at some point it is going to quit.
>
> Not if it is interrupt driven, the kernel only responds to devices when
> they show up, it doesn't know how many devices are going to be ever
> found.
>
>> It seems clear that some things are only going to be done once.
>
> "once"?
Okay so I did just a very small amount of reading for your pleasure and
amusement.
I quote:
"There are two problems to be solved for network device drivers.
Firstly, not all of the network device drivers built into the Linux
kernel will have devices to control. Secondly, the ethernet devices in
the system are always called /dev/eth0, /dev/eth1 and so on, no matter
what their underlying device drivers are. The problem of ``missing''
network devices is easily solved. As the initialization routine for each
network device is called, it returns a status indicating whether or not
it located an instance of the controller that it is driving. If the
driver could not find any devices, its entry in the device list pointed
at by dev_base is removed. If the driver could find a device it fills
out the rest of the device data structure with information about the
device and the addresses of the support functions within the network
device driver."
So yes, drivers are tried one by one and they try to find devices they
can manage. When they cannot, they are removed from the list and never
tried again.
"never"? Yes, not ever again during the running of the system.
Not a mention of any waiting needing to be done and the entire document
only mentions "at boot time" -- this is not a thing that happens "after
boot".
Another indication:
"The second problem, that of dynamically assigning ethernet devices to
the standard /dev/ethN device special files is solved more elegantly.
There are eight standard entries in the devices list; one for eth0, eth1
and so on to eth7. The initialization routine is the same for all of
them, it tries each ethernet device driver built into the kernel in turn
until one finds a device. When the driver finds its ethernet device it
fills out the ethN device data structure, which it now owns. It is also
at this time that the network device driver initializes the physical
hardware that it is controlling and works out which IRQ it is using,
which DMA channel (if any) and so on. A driver may find several
instances of the network device that it is controlling and, in this
case, it will take over several of the /dev/ethN device data structures.
Once all eight standard /dev/ethN have been allocated, no more ethernet
devices will be probed for."
Does THAT sound like for-ever trying to find more devices? No, it
doesn't at all.
It's an old document (1999) but I think nothing ever changed about that.
("nothing" -- yes, nothing that fundamentally changed this model).
See I'm helping you here with your clever words. Sometimes people call
that "inb4" but I hate that acronym.
Ethernet device discovery ENDS at a certain point which is pretty clear
from this document.
I do not question your expertise. I question your sincerity here.
Device drivers are being asked to POLL for devices -- THIS IS NOT EVENT
DRIVEN.
> Not if it is interrupt driven, the kernel only responds to devices
> when they show up, it doesn't know how many devices are going to be
> ever found.
You didn't say whether it was event driven, so technically you never
lied. You were however creating a thought experiment about something
that isn't true.
Device polling is not interrupt driven. It seems clear these device
drivers perform their functions of discovery in a timely fashion, and it
is not an everlasting process at all.
Even if it works using bios callbacks (I don't know) it is still not
event driven.
I could look at the source for the driver of my own device, you know?
That would amuse you even more, I'm sure.
>> So I am not sure what you are alluding to. If there is some theoretical
>> tail (and it has not to do with hotplugging) I'm not sure if it is ever
>> going to be relevant here. If there is a theoretical tail, the system
>> cannot wait for it anyway.
>
> The issue is that you need to create a system that allows devices to
> show up whenever they decide to show up, you can't "wait around" for
> anything as you never know just how long, or what will, or will not,
> show up.
This "showing up" -- you pretend or insinuate or imply here that these
devices decide to do that thing on their own whenever they have had a
nice cup of tea they liked.
No, the device driver polls for it.
Also, you didn't say that this was the reality now, only that I need to
create such a system. Again, not technically lying ;-).
You never said t
Re: [systemd-devel] Factoring out initctl support
On Fri, Apr 15, 2016 at 1:33 PM, Daniel Mack wrote: > On 04/15/2016 07:03 PM, Mike Gilbert wrote: >> On Fri, Apr 15, 2016 at 11:43 AM, Daniel Mack wrote: >>> On 04/15/2016 03:55 PM, Mike Gilbert wrote: > I'm happy to move it if others want to utilize it. I will need someone to set me up with access to push the code, however. >>> >>> Great, will do. What's your GitHub handle? >> >> I'm floppym on github. >> > > Thanks - you're now the admin of this new repository: > > https://github.com/systemd/systemd-initctl/ > > I'm happy to push the client code there once you migrated the project. The project has been migrated. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Factoring out initctl support
On 04/15/2016 07:03 PM, Mike Gilbert wrote: > On Fri, Apr 15, 2016 at 11:43 AM, Daniel Mack wrote: >> On 04/15/2016 03:55 PM, Mike Gilbert wrote: >>> I'm happy to move it if others want to utilize it. I will need someone >>> to set me up with access to push the code, however. >> >> Great, will do. What's your GitHub handle? > > I'm floppym on github. > Thanks - you're now the admin of this new repository: https://github.com/systemd/systemd-initctl/ I'm happy to push the client code there once you migrated the project. However, I'd still like to have an Ack from Michael Biebl on the downstream integration of this new repository. Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Factoring out initctl support
On Fri, Apr 15, 2016 at 11:43 AM, Daniel Mack wrote: > On 04/15/2016 03:55 PM, Mike Gilbert wrote: >> On Fri, Apr 15, 2016 at 6:42 AM, Daniel Mack wrote: >>> Nice, thanks for working on this! What's still missing in that is the >>> other side, the client that talks to the initctl socket. I have patches >>> to remove the initctl bits from the systemd repo, and add a callout from >>> systemctl to binaries in a directory. The initctl client would live in >>> that directory, and be automatically called as a fallback then. >> >> I'm not sure what you mean by this; the de-facto "initctl client" is >> the telinit binary from sysvinit. There should be no need to >> re-implement that. >> >> Are you referring to some other interface? Does upstart do something similar? > > I'm referring to systemctl's own implementation, which is used when PID1 > is not systemd. See talk_initctl() in systemctl.c. I'd move that out to > an own binary, and add a generic callout mechanism to systemctl (which I > already did). Oh, I see. I had no idea systemctl has such code. > What also missing in your repository is the manpage and a README. > >>> Would you be okay with transferring this repository to the systemd >>> organization on GitHub? >> >> I'm happy to move it if others want to utilize it. I will need someone >> to set me up with access to push the code, however. > > Great, will do. What's your GitHub handle? I'm floppym on github. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Reindl Harald schreef op 15-04-16 18:06: > > > Am 15.04.2016 um 18:02 schrieb Xen: >> Reindl Harald schreef op 15-04-16 17:55: > so 3 seconds is unacceptable and the idea ist a joke in general > because > you wait for something possibly happen while you don't know how > long you > have to wait and jsut hope for luck - that's not a good design and > won't > bew accepted anywhere You are the only one taking 3 seconds seriously as something to hang onto just so you can say that I am full of shit >>> >>> it don't matter *how long* you wait for something you don't know if it >>> ever appears and how long it take to appear - period >> >> That's why you *don't* and you just proceed with it in line with the >> current booting of the system, you just postpone the renaming to a later >> stage where you rename all in one go, instead of each time a device is >> discovered > > * you don't know *when* that later is > * until that has happened all other services have to wait > * this won#t work in real life > * if it would work that way it would have been implemented > > HONESTLY: i *hate* that predictable stuff too, i don't need it, i > disable it and would prefer that the ones who *really* need it has to > enable it instead you need to touch your config on the majority of > machines which have only one NIC (since current mainboards don't have > dualport NICs as some yaers ago) > > BUT: i would be careful to pretend i have a doable solution which works > for *all* usecases when people working for many years on the kernel did > not found one Well thank you for these kind words. But what you say is just not entirely accurate. You do not respond to this statement that by default, and by definition, almost, networking services have to wait on networking hardware anyway. The only time when what you say would make sense, if is there exists the condition where *some* networking devices are allowed to show up at a later time, and networking *services* are capable of dealing with that. I do not think that is common reality and current boot systems are also not designed around that. I mean, am I so stupid here or is this just common sense? Show me the system that can handle networking devices showing up after network service start on those devices. Either it knows what to wait for, or it will fail. So not all other services would have to wait, only network services, and you do NOT wait, you just go ahead. At least if what I say makes sense, but what you have said until now does not disprove that. And there are other solutions as well. *The udev solution that uses biosdevname (program) falls completely along the line of what I have proposed here and it already exist, it is packaged, and apparently it works*. It is apparently a udev rule that renames devices one by one (in the all_ethX policy) provided there is no hotplugging. If this system already exists and demonstrably works, why are you battling against it? Just because I am stupid or have a big mouth??? > * if it would work that way it would have been implemented Not if political choices are being made. Conversely, only if those kernel/systemd developers are somehow infallable beings that never make a partial choice. > BUT: i would be careful to pretend i have a doable solution which > worksfor *all* usecases when people working for many years on the > kernel did not found one That entirely depends on what interests they are trying to harmonize with each other and this is a willfull choice. If you want every house to have a sink, and you also want every house for the new owners to choose their own sink, you will have a problem because these things cannot be united. These designers have wanted ALL linux systems to have like hardware addresses encoded into network device names. Andrei suggested that this is just impossible to begin with. He also suggested that other vendors have different solutions. For instance, Windows from what I know keeps a track record of devices and only changes something about their configuration if they suddenly go missing or new ones appear. The Linux kernel / system does not normally maintain persistent records of what hardware has been found and retries the same procedures on every boot. Even simply maintaining a saved mapping of hardware-address-to-device-names would instantly solve this issue provided you provide for a way to handle mutations. That is because if hardware-addresses in this case are reliable and persistent, the device names they are mapped to would be identical on each boot as it would not depend on the time the driver or device made itself known. Gives its own complications but this is what Windows has done (I believe). Moreoever you can also use different froms of identification such as vendor ID and all of that. You don't have to use hardware address exclusively. If I remove a device from my slot the sound card in the next slot will have a different address
Re: [systemd-devel] on the default for, PredictableNetworkInterfaceNames
Reindl Harald schreef op 14-04-16 12:02:
>
>
> Am 14.04.2016 um 11:45 schrieb Jetchko Jekov:
>> On Thu, Apr 14, 2016 at 10:57 AM Reindl Harald > > can iterate over.
>> >
>> > $ ip -o a | awk '{print $2}' | uniq
>>
>> blub - gives a (incomplete) list of the current interfaces - so
>> what is
>> the advantage you wnated to demonstrate?
>>
>> wrong
>> that gives you *configured IP addresses* on interfaces. if there are
>> interfaces without addresses obviously they wont be listed ...
>
> don't tell me what something gives when you have the input and output
> even in your quoted mail
You realize this guy is doing the same thing to you that you've done to me?
He is going to come up with reasons why what you say is not true, and
even if you say "I have to pick my apples in fall because they are ripe"
he is going to suggest deep freezing the entire orchard so you can pluck
them in winter ;-)".
"ip -o a" does not agree with any purpose I had in using ifconfig here
and shows much less info.
That's like suggesting me to use an oven because ovens are better than
pans, even if I was trying to fry something and not bake.
Anyway thanks for responding to this.
If there is anything I hate it is people who are only concerned with
what is "better" instead of what is more useful. Or more suited to the
task at hand. Or whatever.
>
>> for list of interfaces command is
>> ip [-o] l[ink] [show]
>>
>> and I would point out that output of ifconfig wont give you complete
>> list of interfaces as opposed to ip link show
>>
>> [root@rh:~]$ ip -o a | awk '{print $2}' | uniq
>> lo
>> vmnet8
>> br-lan
>>
>> [root@rh:~]$ ifconfig | grep mtu
>> bond0: flags=5187 mtu 1472
>> br-lan: flags=4163 mtu 1472
>> eth0: flags=6211 mtu 1472
>> eth1: flags=6211 mtu 1472
>> lo: flags=73 mtu 65536
>> vmnet8: flags=4163 mtu 1500
>
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Am 15.04.2016 um 18:02 schrieb Xen: Reindl Harald schreef op 15-04-16 17:55: so 3 seconds is unacceptable and the idea ist a joke in general because you wait for something possibly happen while you don't know how long you have to wait and jsut hope for luck - that's not a good design and won't bew accepted anywhere You are the only one taking 3 seconds seriously as something to hang onto just so you can say that I am full of shit it don't matter *how long* you wait for something you don't know if it ever appears and how long it take to appear - period That's why you *don't* and you just proceed with it in line with the current booting of the system, you just postpone the renaming to a later stage where you rename all in one go, instead of each time a device is discovered * you don't know *when* that later is * until that has happened all other services have to wait * this won#t work in real life * if it would work that way it would have been implemented HONESTLY: i *hate* that predictable stuff too, i don't need it, i disable it and would prefer that the ones who *really* need it has to enable it instead you need to touch your config on the majority of machines which have only one NIC (since current mainboards don't have dualport NICs as some yaers ago) BUT: i would be careful to pretend i have a doable solution which works for *all* usecases when people working for many years on the kernel did not found one signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Reindl Harald schreef op 15-04-16 17:55: > > > Am 15.04.2016 um 17:48 schrieb Xen: >> Reindl Harald schreef op 13-04-16 10:24: >>> 4xHDD raid-10, hardware from 2011 >>> Startup finished in 660ms (kernel) + 5.380s (initrd) + 12.769s >>> (userspace) = 18.810s >>> >>> os on sd-card >>> Startup finished in 375ms (kernel) + 4.306s (initrd) + 8.323s >>> (userspace) = 13.005s >>> >>> so 3 seconds is unacceptable and the idea ist a joke in general because >>> you wait for something possibly happen while you don't know how long you >>> have to wait and jsut hope for luck - that's not a good design and won't >>> bew accepted anywhere >> >> You are the only one taking 3 seconds seriously as something to hang >> onto just so you can say that I am full of shit > > it don't matter *how long* you wait for something you don't know if it > ever appears and how long it take to appear - period That's why you *don't* and you just proceed with it in line with the current booting of the system, you just postpone the renaming to a later stage where you rename all in one go, instead of each time a device is discovered. The thing I talked about was not any form of "sleep". Even Greg thought it was not completely out of the ordinary. If you can produce for me systems that see networking devices added after they have already been tried to "up" - meaning the software configuration (firewall, routing) is being started on non-existing devices, fine. Produce that list. Show me those systems where not all devices are present at network up time. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Am 15.04.2016 um 17:42 schrieb Xen: Greg KH schreef op 13-04-16 05:04: You are lying to me and trying to lead me in the woods. The stuff you say is stuff people say that in the end don't end up being true. It does not even agree with the reality of how the system works currently. They are nonsense rebuttals and anyone with enough knowledge would be able to refute them. You're playing mind games here and NOW you finally reached the point where you should just shut up and don't say any word because you have no clue about what you are talking nor to whom you are talking - your bad that the person you responded to have more knowledge about the kernel the half of this whole mailing list together https://en.wikipedia.org/wiki/Greg_Kroah-Hartman signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Am 15.04.2016 um 17:54 schrieb Xen: Reindl Harald schreef op 13-04-16 10:26: What are you on about? Just because I don't have a superfast system, I cannot say anything? no beause of "hmm let wait 3 seconds for something we don't know if it ever appears and how long it would take to appear" is unacceptable in general as additional boot time and on many setups would double the whole boot time nobody right in his mind would implement a "sleep 3" for a general purpose setup in the boot process *kernel time* is below 1 second on most machines Do you realize how utterly ridiculous you sound? Even if what you say is true, it would double the boot time of a 5 second boot to 10 seconds. which is unacceptable, not a solution and can even not be called a workaround I'm sure your life is now at stake. I'm sure all your vital services are now failing. Call life support. This guy is in trouble. yes, when i have to decide to reboot 30 machines and find a timewindow for the task it makes a large difference if it takes just 4 seconds where nobody out there could provie that it was my server or his internet connection Yes I'm making a mockery of your state of life here. Being concerned about 4 fucking seconds when each time reliably your system has all devices present in any case. if only 3 people with your attitude would have anything to say we would be back at boot times from 10 years ago That means "IN ANY CASE". That means: ALL THE TIME. Systems do not wait 3 fucking hours for a networking device to show up okay. you where the one who started with "wait for something" signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Am 15.04.2016 um 17:48 schrieb Xen: Reindl Harald schreef op 13-04-16 10:24: 4xHDD raid-10, hardware from 2011 Startup finished in 660ms (kernel) + 5.380s (initrd) + 12.769s (userspace) = 18.810s os on sd-card Startup finished in 375ms (kernel) + 4.306s (initrd) + 8.323s (userspace) = 13.005s so 3 seconds is unacceptable and the idea ist a joke in general because you wait for something possibly happen while you don't know how long you have to wait and jsut hope for luck - that's not a good design and won't bew accepted anywhere You are the only one taking 3 seconds seriously as something to hang onto just so you can say that I am full of shit it don't matter *how long* you wait for something you don't know if it ever appears and how long it take to appear - period signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Reindl Harald schreef op 13-04-16 10:26: > > > Am 13.04.2016 um 03:08 schrieb Xen: >> Reindl Harald schreef op 13-04-16 02:06: >>> >>> Am 13.04.2016 um 01:20 schrieb Xen: Greg KH schreef op 13-04-16 01:16: > On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote: >> All you need to do is wait a few seconds before you start renaming > > Most machines boot to login faster than a "few seconds", so: Most machines boot to login faster than a few seconds? What machines are you talking about? Anyway the 3 seconds I mentioned is or would be a relative number >>> >>> STOP IT NOW >> >> What are you on about? >> >> Just because I don't have a superfast system, I cannot say anything? > > no beause of "hmm let wait 3 seconds for something we don't know if it > ever appears and how long it would take to appear" is unacceptable in > general as additional boot time and on many setups would double the > whole boot time > > nobody right in his mind would implement a "sleep 3" for a general > purpose setup in the boot process > > *kernel time* is below 1 second on most machines Do you realize how utterly ridiculous you sound? Even if what you say is true, it would double the boot time of a 5 second boot to 10 seconds. I'm sure your life is now at stake. I'm sure all your vital services are now failing. Call life support. This guy is in trouble. Yes I'm making a mockery of your state of life here. Being concerned about 4 fucking seconds when each time reliably your system has all devices present in any case. That means "IN ANY CASE". That means: ALL THE TIME. Systems do not wait 3 fucking hours for a networking device to show up okay. And systems that condense boot times to 4 seconds do not either, because they could not reliably do so if this was true, this theoretical hypothetical thing you are so consistently alluding to just to have a stick to throw at me. If your system boots in 4 seconds then your networking device is going to be there. And it is also going to be there prior to starting networking. Christ, letting me be drawn into a debate where people can lie to me because I am not intimiate with certain details of the boot process. I invite you to produce a real dmesg in which your networking device is not detected / kernel loaded prior to having a login prompt or something of the kind. I honestly invite you to back up your false statements in this way, and if not, just let me be for a change and like that other person said: fume elsewhere. But it appears you are doing enough of that already. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Reindl Harald schreef op 13-04-16 10:24: > > > Am 13.04.2016 um 02:42 schrieb Xen: >> Greg KH schreef op 13-04-16 01:29: >>> On Wed, Apr 13, 2016 at 01:20:05AM +0200, Xen wrote: >> >>> All execpt for 4-socket and larger servers. They take tens of minutes >>> in the BIOS and then less than a minute in the kernel/userspace, >>> depending on the amount of memory. >>> >>> Doesn't your laptop/desktop boot that fast? If not, you are using the >>> wrong distro :) >> >> I have no SSD. Even a 4-rotating-disk raid-10 system using a relatively >> new processor (FX 6300) does definitely not boot within a few seconds > > 4xHDD raid-10, hardware from 2011 > Startup finished in 660ms (kernel) + 5.380s (initrd) + 12.769s > (userspace) = 18.810s > > os on sd-card > Startup finished in 375ms (kernel) + 4.306s (initrd) + 8.323s > (userspace) = 13.005s > > so 3 seconds is unacceptable and the idea ist a joke in general because > you wait for something possibly happen while you don't know how long you > have to wait and jsut hope for luck - that's not a good design and won't > bew accepted anywhere You are the only one taking 3 seconds seriously as something to hang onto just so you can say that I am full of shit. That makes you a retard, not me. If the system needs to start networking and its devices are not present, it is in trouble anyway. You seem to fail to appreciate that logical problem. You so proudly profess that your system is booted in whatever short amount of time but good old you is willing to wait three hours before the networking device is actually detected? What fool you are then. It is perfectly clear that in every boot you do this device is going to be present at a perfectly rational and predictable interval of time. You have systems that boot in 4 seconds but now you have issues with networking hardware not showing up in time? Can you please stop contradicting yourself Jesus christ, I am out of here, or at least not responding anymore to you (after the next). Oh and yes to restate: If you currently have systems that reliably are able to start networking, then you will also have systems that reliably are able to start networking if you rename devices prior to that moment in one go. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Factoring out initctl support
On 04/15/2016 03:55 PM, Mike Gilbert wrote: > On Fri, Apr 15, 2016 at 6:42 AM, Daniel Mack wrote: >> Nice, thanks for working on this! What's still missing in that is the >> other side, the client that talks to the initctl socket. I have patches >> to remove the initctl bits from the systemd repo, and add a callout from >> systemctl to binaries in a directory. The initctl client would live in >> that directory, and be automatically called as a fallback then. > > I'm not sure what you mean by this; the de-facto "initctl client" is > the telinit binary from sysvinit. There should be no need to > re-implement that. > > Are you referring to some other interface? Does upstart do something similar? I'm referring to systemctl's own implementation, which is used when PID1 is not systemd. See talk_initctl() in systemctl.c. I'd move that out to an own binary, and add a generic callout mechanism to systemctl (which I already did). What also missing in your repository is the manpage and a README. >> Would you be okay with transferring this repository to the systemd >> organization on GitHub? > > I'm happy to move it if others want to utilize it. I will need someone > to set me up with access to push the code, however. Great, will do. What's your GitHub handle? Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Greg KH schreef op 13-04-16 05:04: > On Wed, Apr 13, 2016 at 02:42:29AM +0200, Xen wrote: >> When you say that probing on the PCI bus never ends, and if we are >> talking not about some form of hotplugging, then I really wonder what >> you're on about ;-) because I do think the kernel has a limited set of >> probes that it can perform, and at some point it is going to quit. > > Not if it is interrupt driven, the kernel only responds to devices when > they show up, it doesn't know how many devices are going to be ever > found. > >> It seems clear that some things are only going to be done once. > > "once"? > >> So I am not sure what you are alluding to. If there is some theoretical >> tail (and it has not to do with hotplugging) I'm not sure if it is ever >> going to be relevant here. If there is a theoretical tail, the system >> cannot wait for it anyway. > > The issue is that you need to create a system that allows devices to > show up whenever they decide to show up, you can't "wait around" for > anything as you never know just how long, or what will, or will not, > show up. > > You have to design a system that is event driven, as that is how > hardware works, and is the only way your system can work properly due to > it possibly changing all the time (devices added / removed between > boots, etc.) You are lying to me and trying to lead me in the woods. The stuff you say is stuff people say that in the end don't end up being true. It does not even agree with the reality of how the system works currently. They are nonsense rebuttals and anyone with enough knowledge would be able to refute them. You're playing mind games here. Any system needing to take into account that some urgently needed networking device might shop up after 3 days when the moon is in the right position in the sky this is what you are saying. It doesn't agree with reality and I am not going to respond to this nonsense. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Factoring out initctl support (was: Re: [RFC] the chopping block)
On Fri, Apr 15, 2016 at 6:42 AM, Daniel Mack wrote: > Nice, thanks for working on this! What's still missing in that is the > other side, the client that talks to the initctl socket. I have patches > to remove the initctl bits from the systemd repo, and add a callout from > systemctl to binaries in a directory. The initctl client would live in > that directory, and be automatically called as a fallback then. I'm not sure what you mean by this; the de-facto "initctl client" is the telinit binary from sysvinit. There should be no need to re-implement that. Are you referring to some other interface? Does upstart do something similar? > Would you be okay with transferring this repository to the systemd > organization on GitHub? I'm happy to move it if others want to utilize it. I will need someone to set me up with access to push the code, however. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Factoring out initctl support (was: Re: [RFC] the chopping block)
Hi Mike, On 04/01/2016 10:11 PM, Mike Gilbert wrote: > On Wed, Feb 24, 2016 at 10:42 PM, Mike Gilbert wrote: >> The existing systemd-initctl (/dev/initctl) interface works quite >> nicely, so I will probably end up extracting it from systemd when you >> drop it, or just building/installing it from an older systemd tarball. >> No need to reinvent the wheel. >> >> Thanks for the response. > > Ripping systemd-initctl out of the systemd source tree was more > difficult than I anticipated. Instead, I rewrote a simpler version. > The code is on bitbucket. > > https://bitbucket.org/floppym/gentoo-systemd-initctl/src Nice, thanks for working on this! What's still missing in that is the other side, the client that talks to the initctl socket. I have patches to remove the initctl bits from the systemd repo, and add a callout from systemctl to binaries in a directory. The initctl client would live in that directory, and be automatically called as a fallback then. Would you be okay with transferring this repository to the systemd organization on GitHub? Michael, would you be fine with integrating this downstream to not lose any compat? Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] centos-ci
On 04/12/2016 01:52 PM, Jóhann B. Guðmundsson wrote: > Anyone know that centos is not running the latest version(s) of systemd > required for the upstream bug tracker so one has to ask what > notification spam is this > "Can one of the admins verify this patch?" Regarding that spam, I already took measures against that. I wasn't aware the CentOS CI started commenting on PRs, and neither was anyone else on their side. The GitHub integration in the CentOS Jenkins is brand new, we're their first user, so such things can happen. Sorry about that. Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] some services always being killed when stress tests running
On Wed, Apr 13, 2016 at 07:20:12PM +, Zizka, Jan (Nokia - CZ/Prague) wrote: > > From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On > > Behalf Of EXT Han Pingtian > > Sent: Wednesday, April 06, 2016 4:33 AM > > On Fri, Apr 01, 2016 at 09:13:54PM +0200, Lennart Poettering wrote: > > > On Tue, 22.03.16 10:02, Han Pingtian (ha...@linux.vnet.ibm.com) wrote: > > > > > > > But only after about 30 minutes, a lot of systemd services failed > > > > and restarted like this: > > > > > > > > ... ... > > > > [26885.910036] systemd[1]: systemd-journald.service: Failed with result > > 'signal'. > > > > [26885.910218] systemd[1]: systemd-udevd.service: Main process > > > > exited, code=killed, status=9/KILL > > > > > > This indicates that something killed the processes in question with > > > SIGKILL. Quite possibly this was the OOM killer, which was triggered > > > by your stress test? Check the kernel logs if you see anything about > > > that... > > > > > I have seen this problem on another system a while ago. But on all the > > systems which this problem can be reproduced, there isn't any OOM killer > > message can be found in kernel logs. How could we debug this problem? > > You could use auditd to monitor the signals and then you will see which > process have sent the SIGKILL. There is also another method mentioned here: > https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/Finding_the_source_of_signals_on_Linux_with_strace_auditd_or_Systemtap?lang=en > > Jan Thanks so much! I have find the reason by using systemtap. It's some test cases from LTP kill the services. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-boot in fedora 23/24
2016-04-14 20:02 GMT+03:00 Zbigniew Jędrzejewski-Szmek : > It's there. It works. See bootctl(1). > > Zbyszek Thanks! Sorry for noise. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
