Re: [systemd-devel] Stable interface names even when hardware is added or removed, not true

[Pekka Sarnila]

On 11/16/16 18:11, Greg KH wrote:

On Wed, Nov 16, 2016 at 03:33:42PM +0200, Pekka Sarnila wrote:

On 'Predictable Network Interface Names' it states as a benefit of the new
policy:

  Stable interface names even when hardware is added or removed, i.e.
  no re-enumeration takes place

Unfortunately this is not true.

I'm running a mail server, kernel 4.8.6. Graphics card started to fail.
Replaced it with new one (newer model). Booted the system.

All seemed to be fine, network seemed to work. But after some time got angry
cries: 'can't read the mail !!!'. A big headache.

Although the new card was in the same slot as the old one kernel had changed
the name enp6s0 -> enp3s0 (no firmware/BIOS index available and kernel
policy was used as default). Since enp6s0 was not found our server instead
of fixed ip address used our dhcp-server to get a random temp address. Thus
network worked, but not in the mail-servers correct address.

To figure this out took some nervous time.

Now, I don't know why kernel driver got a different name for this network
interface (ethernet hardware is on the motherboard, and it is the only net
hardware on the system). But obviously it can happen.


That is because your PCI devices renumbered themselves, which is quite
common when changing PCI devices around (or adding/removing them).  Not
much systemd can do about this, sorry.

greg k-h



Well my first point was that the web page should not say

>>   Stable interface names even when hardware is added or removed, i.e.
>>   no re-enumeration takes place

But second was that in principle persistent naming would be possible for 
systems with only one interface. And it should possible to implement it 
in systemd-network, and make it systemd package default for such case.


pekka
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Stable interface names even when hardware is added or removed, not true

[Pekka Sarnila]

I was talking about systemd out of the box distribution defaults.
I'm afraid there are plenty of people who most likely would not be able 
figure out what happened to their system (while being able to change 
their display card).


pekka

On 11/16/16 18:21, Michał Zegan wrote:

But he coul use a .link file to give a persistent interface name based
on some property, wouldn't it be a nice thing to do?

W dniu 16.11.2016 o 17:11, Greg KH pisze:

On Wed, Nov 16, 2016 at 03:33:42PM +0200, Pekka Sarnila wrote:

On 'Predictable Network Interface Names' it states as a benefit of the new
policy:

  Stable interface names even when hardware is added or removed, i.e.
  no re-enumeration takes place

Unfortunately this is not true.

I'm running a mail server, kernel 4.8.6. Graphics card started to fail.
Replaced it with new one (newer model). Booted the system.

All seemed to be fine, network seemed to work. But after some time got angry
cries: 'can't read the mail !!!'. A big headache.

Although the new card was in the same slot as the old one kernel had changed
the name enp6s0 -> enp3s0 (no firmware/BIOS index available and kernel
policy was used as default). Since enp6s0 was not found our server instead
of fixed ip address used our dhcp-server to get a random temp address. Thus
network worked, but not in the mail-servers correct address.

To figure this out took some nervous time.

Now, I don't know why kernel driver got a different name for this network
interface (ethernet hardware is on the motherboard, and it is the only net
hardware on the system). But obviously it can happen.


That is because your PCI devices renumbered themselves, which is quite
common when changing PCI devices around (or adding/removing them).  Not
much systemd can do about this, sorry.

greg k-h
___
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


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Stable interface names even when hardware is added or removed, not true

[Dave Reisner]

On Wed, Nov 16, 2016 at 4:19 PM, Pekka Sarnila  wrote:

>
>
> On 11/16/16 18:11, Greg KH wrote:
>
>> On Wed, Nov 16, 2016 at 03:33:42PM +0200, Pekka Sarnila wrote:
>>
>>> On 'Predictable Network Interface Names' it states as a benefit of the
>>> new
>>> policy:
>>>
>>>   Stable interface names even when hardware is added or removed, i.e.
>>>   no re-enumeration takes place
>>>
>>> Unfortunately this is not true.
>>>
>>> I'm running a mail server, kernel 4.8.6. Graphics card started to fail.
>>> Replaced it with new one (newer model). Booted the system.
>>>
>>> All seemed to be fine, network seemed to work. But after some time got
>>> angry
>>> cries: 'can't read the mail !!!'. A big headache.
>>>
>>> Although the new card was in the same slot as the old one kernel had
>>> changed
>>> the name enp6s0 -> enp3s0 (no firmware/BIOS index available and kernel
>>> policy was used as default). Since enp6s0 was not found our server
>>> instead
>>> of fixed ip address used our dhcp-server to get a random temp address.
>>> Thus
>>> network worked, but not in the mail-servers correct address.
>>>
>>> To figure this out took some nervous time.
>>>
>>> Now, I don't know why kernel driver got a different name for this network
>>> interface (ethernet hardware is on the motherboard, and it is the only
>>> net
>>> hardware on the system). But obviously it can happen.
>>>
>>
>> That is because your PCI devices renumbered themselves, which is quite
>> common when changing PCI devices around (or adding/removing them).  Not
>> much systemd can do about this, sorry.
>>
>> greg k-h
>>
>>
> Well my first point was that the web page should not say
>
> >>   Stable interface names even when hardware is added or removed, i.e.
> >>   no re-enumeration takes place
>
> But second was that in principle persistent naming would be possible for
> systems with only one interface. And it should possible to implement it in
> systemd-network, and make it systemd package default for such case.


No, it's not. It sounds more like you want to disable the naming policy,
which means you get "eth0" for the first device that shows up.


>
> pekka
>
> ___
> 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] Stable interface names even when hardware is added or removed, not true

[Michał Zegan]

But he coul use a .link file to give a persistent interface name based
on some property, wouldn't it be a nice thing to do?

W dniu 16.11.2016 o 17:11, Greg KH pisze:
> On Wed, Nov 16, 2016 at 03:33:42PM +0200, Pekka Sarnila wrote:
>> On 'Predictable Network Interface Names' it states as a benefit of the new
>> policy:
>>
>>   Stable interface names even when hardware is added or removed, i.e.
>>   no re-enumeration takes place
>>
>> Unfortunately this is not true.
>>
>> I'm running a mail server, kernel 4.8.6. Graphics card started to fail.
>> Replaced it with new one (newer model). Booted the system.
>>
>> All seemed to be fine, network seemed to work. But after some time got angry
>> cries: 'can't read the mail !!!'. A big headache.
>>
>> Although the new card was in the same slot as the old one kernel had changed
>> the name enp6s0 -> enp3s0 (no firmware/BIOS index available and kernel
>> policy was used as default). Since enp6s0 was not found our server instead
>> of fixed ip address used our dhcp-server to get a random temp address. Thus
>> network worked, but not in the mail-servers correct address.
>>
>> To figure this out took some nervous time.
>>
>> Now, I don't know why kernel driver got a different name for this network
>> interface (ethernet hardware is on the motherboard, and it is the only net
>> hardware on the system). But obviously it can happen.
> 
> That is because your PCI devices renumbered themselves, which is quite
> common when changing PCI devices around (or adding/removing them).  Not
> much systemd can do about this, sorry.
> 
> greg k-h
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



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] Stable interface names even when hardware is added or removed, not true

[Greg KH]

On Wed, Nov 16, 2016 at 03:33:42PM +0200, Pekka Sarnila wrote:
> On 'Predictable Network Interface Names' it states as a benefit of the new
> policy:
> 
>   Stable interface names even when hardware is added or removed, i.e.
>   no re-enumeration takes place
> 
> Unfortunately this is not true.
> 
> I'm running a mail server, kernel 4.8.6. Graphics card started to fail.
> Replaced it with new one (newer model). Booted the system.
> 
> All seemed to be fine, network seemed to work. But after some time got angry
> cries: 'can't read the mail !!!'. A big headache.
> 
> Although the new card was in the same slot as the old one kernel had changed
> the name enp6s0 -> enp3s0 (no firmware/BIOS index available and kernel
> policy was used as default). Since enp6s0 was not found our server instead
> of fixed ip address used our dhcp-server to get a random temp address. Thus
> network worked, but not in the mail-servers correct address.
> 
> To figure this out took some nervous time.
> 
> Now, I don't know why kernel driver got a different name for this network
> interface (ethernet hardware is on the motherboard, and it is the only net
> hardware on the system). But obviously it can happen.

That is because your PCI devices renumbered themselves, which is quite
common when changing PCI devices around (or adding/removing them).  Not
much systemd can do about this, sorry.

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-tmpfiles-clean could remove recently created files

[Alexander Kochetkov]

> Consider filing an RFE for this, or even better an PR…

Issue submitted:
https://github.com/systemd/systemd/issues/4679

Regards,
Alexander.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-tmpfiles-clean could remove recently created files

[Lennart Poettering]

On Wed, 16.11.16 16:08, Alexander Kochetkov (al.koc...@gmail.com) wrote:

> Hello,
> 
> I’d like to discuss the issue I faced. I don’t know should I fill issue 
> report or make something else.
> I made a decision to disable systemd-tmpfiles-clean entirely.
> 
> systemd-tmpfiles-clean by default configured to delete all files from /tmp 
> with atime older than 10 days
> after 15 min of system startup. That is regulated using tmpfiles.d rule and 
> systemd-tmpfiles-clean.timer.
> 
> If machine has incorrect time set during boot (RTC not configured and no 
> /var/lib/systemd/clock) and
> later that time will be corrected using ntp, than systemd-tmpfiles-clean 
> could delete all files and folder
> (created withing 15 min, even opened and used at time systemd-tmpfiles-clean 
> run) from /tmp directory.
> 
> I’d think about patching linux kernel to bind tmpfs atime to CLOCK_MONOTONIC. 
> So atime wouldn’d be
> affected by system time changes.
> 
> May be there is another solution for the issue.

I figure systemd could also record the realtime and monotonic clock
when it first passed control to userspace and tmpfiles could then use
that information and only delete files that are older than the age
value on the wallclock AND older than the age value on the monotonic
clock when taking the initial clock pairing into account.

Consider filing an RFE for this, or even better an PR...

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Pavilion x360 13 randomly enables/disables airplane mode

[Lennart Poettering]

On Wed, 16.11.16 12:11, Francesco Brozzu (francescobro...@gmail.com) wrote:

> Hi!
> 
> I've been using my Pavilion x360 13 with Linux for quite some time now,
> however a couple of months ago I started having a weird issue: basically
> switching to tablet mode, or simply moving the display, would trigger
> airplane mode. After some debugging I found out that the issue is in the
> hwdb keyboard rules of udev, that maps the virtual button that switches the
> desktop from laptop to tablet mode in Windows to the airplane mode toggle
> in Linux. A possible fix (or at least what I'm using right now and what
> works) would be disabling the keys that trigger airplane mode directly from
> the hwdb layout (see attachment)

Could you please post this as PR on github? That's usually the best
way to get your stuff merged upstream these days!

Thanks,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Stable interface names even when hardware is added or removed, not true

[Pekka Sarnila]

On 'Predictable Network Interface Names' it states as a benefit of the 
new policy:


  Stable interface names even when hardware is added or removed, i.e.
  no re-enumeration takes place

Unfortunately this is not true.

I'm running a mail server, kernel 4.8.6. Graphics card started to fail. 
Replaced it with new one (newer model). Booted the system.


All seemed to be fine, network seemed to work. But after some time got 
angry cries: 'can't read the mail !!!'. A big headache.


Although the new card was in the same slot as the old one kernel had 
changed the name enp6s0 -> enp3s0 (no firmware/BIOS index available and 
kernel policy was used as default). Since enp6s0 was not found our 
server instead of fixed ip address used our dhcp-server to get a random 
temp address. Thus network worked, but not in the mail-servers correct 
address.


To figure this out took some nervous time.

Now, I don't know why kernel driver got a different name for this 
network interface (ethernet hardware is on the motherboard, and it is 
the only net hardware on the system). But obviously it can happen.


Could there be general solution for this? On ordinary system MAC could 
be used, but on virtual one. And there are of course docking systems for 
laptops. So that is not general enough.


It would seem there is no general way to enumerate persistently network 
interfaces unless the network hardware itself directly gives its name 
(and have unique names over the world). Or is there?


However could there be a way for systemsd/udev to know that there is 
only one interface in the system? At least then always as a default the 
same name could be given.


Pekka
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-tmpfiles-clean could remove recently created files

[Alexander Kochetkov]

Hello,

I’d like to discuss the issue I faced. I don’t know should I fill issue report 
or make something else.
I made a decision to disable systemd-tmpfiles-clean entirely.

systemd-tmpfiles-clean by default configured to delete all files from /tmp with 
atime older than 10 days
after 15 min of system startup. That is regulated using tmpfiles.d rule and 
systemd-tmpfiles-clean.timer.

If machine has incorrect time set during boot (RTC not configured and no 
/var/lib/systemd/clock) and
later that time will be corrected using ntp, than systemd-tmpfiles-clean could 
delete all files and folder
(created withing 15 min, even opened and used at time systemd-tmpfiles-clean 
run) from /tmp directory.

I’d think about patching linux kernel to bind tmpfs atime to CLOCK_MONOTONIC. 
So atime wouldn’d be
affected by system time changes.

May be there is another solution for the issue.

Regards,
Alexander.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel