Re: [systemd-devel] What is the point of making timesyncd bus-activatible?
On Tue, 19 May 2020 at 10:31, Arian Van Putten wrote: > > Hey list, > > systemd-timesyncd has an Alias=dbus-org.freedesktop.timesync1.service and an > accompanying dbus service file too. > > It is started in early boot; `Before=sysinit.target` so why would making it > dubs-activatible ever make sense? It is always started way before > dbus.service itself is started. > > It also seems that the unit type is not Type=dbus (and doesn't set a BusName) > which confuses me a bit. So maybe I'm misunderstanding how dbus integration > works here. Ist that because we want to consider the services "ready" before > they even register a name on the bus? > > Similarly systemd-resolved.service and systemd-networkd.service have such > aliases whilst they're both pulled in by `multi-user.target` and also do not > have `Type=dbus` and `BusName=` set. > > What are the reasons for that? For resolve1 i guess it makes sense as you > dont have to think about ordering when making dns calls in services. But I am > still confused why it is not of Type=dbus. Is that because it not only gives > a dbus API but also a DNS api? > it serves requests on 127.0.0.53 and provides dynamic files generated in /run/systemd/resolve/ which can be targets of /etc/resolv.conf symlink. Hence even without anything talking to it over dbus or lo interface, it can be serving information to the system. I.e. it populates both /run/systemd/resolve/resolv.conf and /run/systemd/resolve/stub-resolv.conf either of which can be symlinked to /etc/resolv.conf for nss modules to use. -- Regards, Dimitri. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
However, all is not gold with Deepin as well, as when using a .link file in /etc/systemd/network to rename the interface, Deeping as well does not work any more. Here, eth0 aka enp0s3 aka custom lan-01: # journalctl -b0 | grep -E 'sysctl|lan-01|enp0s3|eth0' May 22 22:31:22 test1-PC kernel: Yama: disabled by default; enable with sysctl kernel.yama.* May 22 22:31:22 test1-PC kernel: virtio_net virtio0 enp0s3: renamed from eth0 May 22 22:31:22 test1-PC systemd-sysctl[259]: Couldn't write '840b:b3d7:8121:5774:b967:1737:db42:a87b' to 'net/ipv6/conf/lan-01/stable_secret', ignoring: No such file or directory May 22 22:31:22 test1-PC systemd-sysctl[259]: Couldn't write '2' to 'net/ipv6/conf/lan-01/addr_gen_mode', ignoring: No such file or directory May 22 22:31:22 test1-PC kernel: virtio_net virtio0 lan-01: renamed from enp0s3 May 22 22:31:22 test1-PC systemd-networkd[267]: enp0s3: Interface name change detected, enp0s3 has been renamed to lan-01. May 22 22:31:22 test1-PC systemd-networkd[267]: lan-01: Gained carrier So we have the renaming from kernel ethx to sytemd persistent, then systemd-sysctl, and then again the renaming from the systemd persistent to the user defined .link file. Same is true, when using an udev rule to customly rename an interface instead of a .link file: root@test1-PC:~# journalctl -b0 | grep -E 'sysctl|lan-01|enp0s3|eth0' May 22 22:41:01 test1-PC kernel: Yama: disabled by default; enable with sysctl kernel.yama.* May 22 22:41:01 test1-PC kernel: virtio_net virtio0 enp0s3: renamed from eth0 May 22 22:41:01 test1-PC systemd-sysctl[258]: Couldn't write '840b:b3d7:8121:5774:b967:1737:db42:a87b' to 'net/ipv6/conf/lan-01/stable_secret', ignoring: No such file or directory May 22 22:41:01 test1-PC systemd-sysctl[258]: Couldn't write '2' to 'net/ipv6/conf/lan-01/addr_gen_mode', ignoring: No such file or directory May 22 22:41:01 test1-PC kernel: virtio_net virtio0 lan-01: renamed from enp0s3 May 22 22:41:01 test1-PC systemd-networkd[263]: enp0s3: Interface name change detected, enp0s3 has been renamed to lan-01. May 22 22:41:01 test1-PC systemd-networkd[263]: lan-01: Gained carrier Am 22.05.20 um 21:50 schrieb Ede Wolf: That sounds like actual bug. What systemd version do you use? I've just did a test with Deepin, as I've had VM flying around of that debian based distribution, and here it seems to work, using systemd 241 instead of 245. systemd-sysctl is clearly called after the renaming: May 22 21:48:46 test1-PC kernel: Yama: disabled by default; enable with sysctl kernel.yama.* May 22 21:48:46 test1-PC kernel: virtio_net virtio0 enp0s3: renamed from eth0 May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '840b:b3d7:8121:5774:b967:1737:db42:a87b' to 'net/ipv6/conf/eth0/stable_secret', ignoring: No such file or directory May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '2' to 'net/ipv6/conf/eth0/addr_gen_mode', ignoring: No such file or directory May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '2' to 'net/ipv6/conf/eth0/use_tempaddr', ignoring: No such file or directory May 22 21:48:46 test1-PC systemd-networkd[263]: enp0s3: Gained carrier So here eth0 is the invalid interface, as it should be. Not sure now wether this a regression or distribution specific. Where are the dependencies defined what service runs first at this early stage? ___ 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] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
There are other issues with either systemd-245 or arch. When NOT using any net.ipv6.conf.xxx.use_tempaddr=2 statements in sysctl.conf, but instead are only using IPv6PrivacyExtensions=yes on arch/systemd-245 this setting gets ignored. On Deepin however a temporary address is assigned, as expected. Am 22.05.20 um 21:50 schrieb Ede Wolf: That sounds like actual bug. What systemd version do you use? I've just did a test with Deepin, as I've had VM flying around of that debian based distribution, and here it seems to work, using systemd 241 instead of 245. systemd-sysctl is clearly called after the renaming: May 22 21:48:46 test1-PC kernel: Yama: disabled by default; enable with sysctl kernel.yama.* May 22 21:48:46 test1-PC kernel: virtio_net virtio0 enp0s3: renamed from eth0 May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '840b:b3d7:8121:5774:b967:1737:db42:a87b' to 'net/ipv6/conf/eth0/stable_secret', ignoring: No such file or directory May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '2' to 'net/ipv6/conf/eth0/addr_gen_mode', ignoring: No such file or directory May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '2' to 'net/ipv6/conf/eth0/use_tempaddr', ignoring: No such file or directory May 22 21:48:46 test1-PC systemd-networkd[263]: enp0s3: Gained carrier So here eth0 is the invalid interface, as it should be. Not sure now wether this a regression or distribution specific. Where are the dependencies defined what service runs first at this early stage? ___ 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] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
22.05.2020 15:44, Ede Wolf пишет: > Hello, > > Thanks for replying. As I have written, I am using no custom .rules or > .link file. /etc/udev/rules.d is empty and /etc/systemd/network only > contains .network files. > This is irrelevant. *ANY* rule can set device name which will rename interface. It does not matter whether these rules are in /usr/lib or /etc. Where do you think those "predictable" names come from? Kernel starts always with ethX. > But I believe the problem would not change. As wether I rename an > interface or 99-default.link as part of systemd-networkd does it, should > make no difference. > > The problem is, that sysctl.conf is being executed before the interfaces > get their eventual names. > That sounds like actual bug. What systemd version do you use? > What would work is disabling interface renaming alltogether by adding > net.ifnames=0 to the kernel, but those ethx names are not reliably > persistent. So nothing is really won here. Unless you only have one > interface, that is. > > Unless I have missed somthing, that's why I am asking, those settings > would need to be moved from sysctl.conf to the [Network] section of a > corresponding unit file alltogether, so that systemd has control over it. > > As a workaround I have set default values: > > net.ipv6.conf.default.stable_secret= > net.ipv6.conf.default.addr_gen_mode=2 > net.ipv6.conf.all.addr_gen_mode=2 > > > But I am getting different results on two different machines. One, where > it works even on a systemd renamed link, and one, where it is not. Still > trying to figure out, why that is. > > But the key should be to be able to set those on a per link base, what I > have not been able to do so far at all. > > > > > Am 22.05.20 um 12:21 schrieb Kevin P. Fleming: >> Do you have a udev 'persistent network device name' rules file in >> /etc/udev/rules.d? Many distributions install such a rules file by >> default, and this renames the interfaces to 'standard' names. >> >> On Fri, May 22, 2020 at 3:47 AM Ede Wolf wrote: >>> >>> Hello, >>> >>> I am trying to enable temporary and/or stable addresses for a link and >>> am most likely running into troubles with the device naming. However, I >>> do not change any network name myself, neither in udev nor as part or a >>> link file, it's just the standard system settings (from Arch, in case >>> that matters). >>> >>> my sysctl.conf (both ens3 and eth0 refer to the same interface): >>> >>> >>> net.ipv6.conf.ens3.addr_gen_mode = 2 >>> net.ipv6.conf.ens3.use_tempaddr = 2 >>> >>> net.ipv6.conf.eth0.addr_gen_mode = 2 >>> net.ipv6.conf.eth0.use_tempaddr = 2 >>> >>> >>> And the logs read: >>> >>> journalctl -b0 | grep -E 'sysctl|ens3|eth0' >>> 08:56:46 systemd[263]: systemd-sysctl.service: Executing: >>> /usr/lib/systemd/systemd-sysctl >>> 08:56:46 systemd-sysctl[263]: Couldn't write '2' to >>> 'net/ipv6/conf/ens3/addr_gen_mode', ignoring: No such file or directory >>> 08:56:46 systemd-sysctl[263]: Couldn't write '2' to >>> 'net/ipv6/conf/ens3/use_tempaddr', ignoring: No such file or directory >>> 08:56:47 kernel: virtio_net virtio0 ens3: renamed from eth0 >>> 08:56:47 systemd[1]: sys-subsystem-net-devices-ens3.device: Changed dead >>> -> plugged >>> 08:56:47 systemd[1]: >>> sys-devices-pci:00-:00:03.0-virtio0-net-ens3.device: Changed >>> dead -> plugged >>> 08:56:51 systemd-networkd[459]: ens3: Interface name change detected, >>> ens3 has been renamed to eth0. I wonder where this comes from. >>> 08:56:51 systemd-networkd[459]: eth0: Interface name change detected, >>> eth0 has been renamed to ens3. >>> 08:56:51 systemd-networkd[459]: ens3: IPv6 successfully enabled >>> 08:56:51 systemd-networkd[459]: ens3: Link UP >>> 08:56:51 systemd-networkd[459]: ens3: Gained carrier >>> ... >>> >>> >>> As it appears to me, the eth0 settings from sysctl.conf have been >>> accepted - at least no errors are logged in this regard -, but are lost, >>> because the interface got renamed afterwards. The ens3 interface was not >>> yet known at time of invoking systemd-sysctl, and therefore we get the >>> errors. That in turn means, the settings are not being applied. >>> udev applies sysctl just once - when interface first appears. It is using final name (that can be different from initial kernel name). So if device appeared under eth0 and got name ens3 during event procesing, udev applies sysctl to ens3 and never to eth0. If udev applied settings to eth0 before rename, these settings would be preserved after rename. >>> To make things worse, in sysctl.conf I've additionally set: >>> >>> net.ipv6.conf.default.stable_secret= >>> net.ipv6.conf.default.addr_gen_mode=2 >>> net.ipv6.conf.all.addr_gen_mode=2 >>> >>> >>> Which results in all IP address having a stable privacy scope link, >>> _execpt_ of course ens3. The one that would be by far most important. >>> >>> What am I missing here? And insight is highly appreciated >>> >>> Thanks >>> >>> Ede >>>
Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
Found the reason for this global issue. The not working machine had not been moved to SLAAC, as I've though it was, but had still been configured statically. Bummer. As a workaround I have set default values: net.ipv6.conf.default.stable_secret= net.ipv6.conf.default.addr_gen_mode=2 net.ipv6.conf.all.addr_gen_mode=2 But I am getting different results on two different machines. One, where it works even on a systemd renamed link, and one, where it is not. Still trying to figure out, why that is. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
Hello, Thanks for replying. As I have written, I am using no custom .rules or .link file. /etc/udev/rules.d is empty and /etc/systemd/network only contains .network files. But I believe the problem would not change. As wether I rename an interface or 99-default.link as part of systemd-networkd does it, should make no difference. The problem is, that sysctl.conf is being executed before the interfaces get their eventual names. What would work is disabling interface renaming alltogether by adding net.ifnames=0 to the kernel, but those ethx names are not reliably persistent. So nothing is really won here. Unless you only have one interface, that is. Unless I have missed somthing, that's why I am asking, those settings would need to be moved from sysctl.conf to the [Network] section of a corresponding unit file alltogether, so that systemd has control over it. As a workaround I have set default values: net.ipv6.conf.default.stable_secret= net.ipv6.conf.default.addr_gen_mode=2 net.ipv6.conf.all.addr_gen_mode=2 But I am getting different results on two different machines. One, where it works even on a systemd renamed link, and one, where it is not. Still trying to figure out, why that is. But the key should be to be able to set those on a per link base, what I have not been able to do so far at all. Am 22.05.20 um 12:21 schrieb Kevin P. Fleming: Do you have a udev 'persistent network device name' rules file in /etc/udev/rules.d? Many distributions install such a rules file by default, and this renames the interfaces to 'standard' names. On Fri, May 22, 2020 at 3:47 AM Ede Wolf wrote: Hello, I am trying to enable temporary and/or stable addresses for a link and am most likely running into troubles with the device naming. However, I do not change any network name myself, neither in udev nor as part or a link file, it's just the standard system settings (from Arch, in case that matters). my sysctl.conf (both ens3 and eth0 refer to the same interface): net.ipv6.conf.ens3.addr_gen_mode = 2 net.ipv6.conf.ens3.use_tempaddr = 2 net.ipv6.conf.eth0.addr_gen_mode = 2 net.ipv6.conf.eth0.use_tempaddr = 2 And the logs read: journalctl -b0 | grep -E 'sysctl|ens3|eth0' 08:56:46 systemd[263]: systemd-sysctl.service: Executing: /usr/lib/systemd/systemd-sysctl 08:56:46 systemd-sysctl[263]: Couldn't write '2' to 'net/ipv6/conf/ens3/addr_gen_mode', ignoring: No such file or directory 08:56:46 systemd-sysctl[263]: Couldn't write '2' to 'net/ipv6/conf/ens3/use_tempaddr', ignoring: No such file or directory 08:56:47 kernel: virtio_net virtio0 ens3: renamed from eth0 08:56:47 systemd[1]: sys-subsystem-net-devices-ens3.device: Changed dead -> plugged 08:56:47 systemd[1]: sys-devices-pci:00-:00:03.0-virtio0-net-ens3.device: Changed dead -> plugged 08:56:51 systemd-networkd[459]: ens3: Interface name change detected, ens3 has been renamed to eth0. 08:56:51 systemd-networkd[459]: eth0: Interface name change detected, eth0 has been renamed to ens3. 08:56:51 systemd-networkd[459]: ens3: IPv6 successfully enabled 08:56:51 systemd-networkd[459]: ens3: Link UP 08:56:51 systemd-networkd[459]: ens3: Gained carrier ... As it appears to me, the eth0 settings from sysctl.conf have been accepted - at least no errors are logged in this regard -, but are lost, because the interface got renamed afterwards. The ens3 interface was not yet known at time of invoking systemd-sysctl, and therefore we get the errors. That in turn means, the settings are not being applied. To make things worse, in sysctl.conf I've additionally set: net.ipv6.conf.default.stable_secret= net.ipv6.conf.default.addr_gen_mode=2 net.ipv6.conf.all.addr_gen_mode=2 Which results in all IP address having a stable privacy scope link, _execpt_ of course ens3. The one that would be by far most important. What am I missing here? And insight is highly appreciated Thanks Ede ___ 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] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
Do you have a udev 'persistent network device name' rules file in /etc/udev/rules.d? Many distributions install such a rules file by default, and this renames the interfaces to 'standard' names. On Fri, May 22, 2020 at 3:47 AM Ede Wolf wrote: > > Hello, > > I am trying to enable temporary and/or stable addresses for a link and > am most likely running into troubles with the device naming. However, I > do not change any network name myself, neither in udev nor as part or a > link file, it's just the standard system settings (from Arch, in case > that matters). > > my sysctl.conf (both ens3 and eth0 refer to the same interface): > > > net.ipv6.conf.ens3.addr_gen_mode = 2 > net.ipv6.conf.ens3.use_tempaddr = 2 > > net.ipv6.conf.eth0.addr_gen_mode = 2 > net.ipv6.conf.eth0.use_tempaddr = 2 > > > And the logs read: > > journalctl -b0 | grep -E 'sysctl|ens3|eth0' > 08:56:46 systemd[263]: systemd-sysctl.service: Executing: > /usr/lib/systemd/systemd-sysctl > 08:56:46 systemd-sysctl[263]: Couldn't write '2' to > 'net/ipv6/conf/ens3/addr_gen_mode', ignoring: No such file or directory > 08:56:46 systemd-sysctl[263]: Couldn't write '2' to > 'net/ipv6/conf/ens3/use_tempaddr', ignoring: No such file or directory > 08:56:47 kernel: virtio_net virtio0 ens3: renamed from eth0 > 08:56:47 systemd[1]: sys-subsystem-net-devices-ens3.device: Changed dead > -> plugged > 08:56:47 systemd[1]: > sys-devices-pci:00-:00:03.0-virtio0-net-ens3.device: Changed > dead -> plugged > 08:56:51 systemd-networkd[459]: ens3: Interface name change detected, > ens3 has been renamed to eth0. > 08:56:51 systemd-networkd[459]: eth0: Interface name change detected, > eth0 has been renamed to ens3. > 08:56:51 systemd-networkd[459]: ens3: IPv6 successfully enabled > 08:56:51 systemd-networkd[459]: ens3: Link UP > 08:56:51 systemd-networkd[459]: ens3: Gained carrier > ... > > > As it appears to me, the eth0 settings from sysctl.conf have been > accepted - at least no errors are logged in this regard -, but are lost, > because the interface got renamed afterwards. The ens3 interface was not > yet known at time of invoking systemd-sysctl, and therefore we get the > errors. That in turn means, the settings are not being applied. > > To make things worse, in sysctl.conf I've additionally set: > > net.ipv6.conf.default.stable_secret= > net.ipv6.conf.default.addr_gen_mode=2 > net.ipv6.conf.all.addr_gen_mode=2 > > > Which results in all IP address having a stable privacy scope link, > _execpt_ of course ens3. The one that would be by far most important. > > What am I missing here? And insight is highly appreciated > > Thanks > > Ede > ___ > 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] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames
Hello, I am trying to enable temporary and/or stable addresses for a link and am most likely running into troubles with the device naming. However, I do not change any network name myself, neither in udev nor as part or a link file, it's just the standard system settings (from Arch, in case that matters). my sysctl.conf (both ens3 and eth0 refer to the same interface): net.ipv6.conf.ens3.addr_gen_mode = 2 net.ipv6.conf.ens3.use_tempaddr = 2 net.ipv6.conf.eth0.addr_gen_mode = 2 net.ipv6.conf.eth0.use_tempaddr = 2 And the logs read: journalctl -b0 | grep -E 'sysctl|ens3|eth0' 08:56:46 systemd[263]: systemd-sysctl.service: Executing: /usr/lib/systemd/systemd-sysctl 08:56:46 systemd-sysctl[263]: Couldn't write '2' to 'net/ipv6/conf/ens3/addr_gen_mode', ignoring: No such file or directory 08:56:46 systemd-sysctl[263]: Couldn't write '2' to 'net/ipv6/conf/ens3/use_tempaddr', ignoring: No such file or directory 08:56:47 kernel: virtio_net virtio0 ens3: renamed from eth0 08:56:47 systemd[1]: sys-subsystem-net-devices-ens3.device: Changed dead -> plugged 08:56:47 systemd[1]: sys-devices-pci:00-:00:03.0-virtio0-net-ens3.device: Changed dead -> plugged 08:56:51 systemd-networkd[459]: ens3: Interface name change detected, ens3 has been renamed to eth0. 08:56:51 systemd-networkd[459]: eth0: Interface name change detected, eth0 has been renamed to ens3. 08:56:51 systemd-networkd[459]: ens3: IPv6 successfully enabled 08:56:51 systemd-networkd[459]: ens3: Link UP 08:56:51 systemd-networkd[459]: ens3: Gained carrier ... As it appears to me, the eth0 settings from sysctl.conf have been accepted - at least no errors are logged in this regard -, but are lost, because the interface got renamed afterwards. The ens3 interface was not yet known at time of invoking systemd-sysctl, and therefore we get the errors. That in turn means, the settings are not being applied. To make things worse, in sysctl.conf I've additionally set: net.ipv6.conf.default.stable_secret= net.ipv6.conf.default.addr_gen_mode=2 net.ipv6.conf.all.addr_gen_mode=2 Which results in all IP address having a stable privacy scope link, _execpt_ of course ens3. The one that would be by far most important. What am I missing here? And insight is highly appreciated Thanks Ede ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
