Re: [systemd-devel] F30->F31 systemd-networkd no IPv6 autoconfiguration
Thank you for responding Ryan. AFAIK, I don't have both systemd-networkd and
NetworkManager "running" or enabled. In fact, I have had NetworkManager
disabled on these systems for some time (back through F27, I believe). Post
upgrade (or fresh install) I ensure that NetworkManager is not re-enabled, and
that systemd-networkd is enabled. Unforuntately, trying to remove
NetworkManager completely seems like a heavy hammer based on the `dnf remove`
output below.
Also, these identical systemd-networkd configurations do work on F30, just not
on systems upgraded to F31.
The only recent change I notice in F31, is that NetworkManager is initialized
during early boot even when the service is disabled and masked.
This is the early boot NetworkManager output:
[1573262139.2398] NetworkManager (version 1.20.4-1.fc31) is
starting... (for the first time)
[1573262139.2399] Read config: /etc/NetworkManager/NetworkManager.conf
[1573262139.2416] auth[0x55b3f3c8b4a0]: create auth-manager: D-Bus
connection not available. Polkit is disabled and all requests are
authenticated.
[1573262139.2426] manager[0x55b3f3c94060]: monitoring kernel firmware
directory '/lib/firmware'.
[1573262139.2427] hostname: hostname: hostnamed not used as proxy
creation failed with: Could not connect: No such file or directory
[1573262139.2428] hostname: hostname changed from (none) to "linux-
ws1.messinet.com"
[1573262139.2430] dns-mgr[0x55b3f3c8f210]: init: dns=default,systemd-
resolved rc-manager=symlink
[1573262139.2447] Loaded device plugin: NMTeamFactory (/usr/lib64/
NetworkManager/1.20.4-1.fc31/libnm-device-plugin-team.so)
[1573262139.2448] manager: rfkill: Wi-Fi enabled by radio killswitch;
enabled by state file
[1573262139.2448] manager: rfkill: WWAN enabled by radio killswitch;
enabled by state file
[1573262139.2448] manager: Networking is enabled by state file
[1573262139.2448] dhcp-init: Using DHCP client 'internal'
[1573262139.2453] settings: Loaded settings plugin: ifcfg-rh ("/usr/
lib64/NetworkManager/1.20.4-1.fc31/libnm-settings-plugin-ifcfg-rh.so")
[1573262139.2454] settings: Loaded settings plugin: keyfile (internal)
[1573262139.2459] device (lo): carrier: link connected
[1573262139.2460] manager: (lo): new Generic device (/org/freedesktop/
NetworkManager/Devices/1)
[1573262139.2464] manager: (eno1): new Ethernet device (/org/
freedesktop/NetworkManager/Devices/2)
[1573262139.2466] device (eno1): state change: unmanaged ->
unavailable (reason 'managed', sys-iface-state: 'external')
[1573262139.4343] sleep-monitor-sd: failed to acquire D-Bus proxy:
Could not connect: No such file or directory
[1573262139.4343] firewall: could not connect to system D-Bus (Could
not connect: No such file or directory)
[1573262139.4344] ifcfg-rh: dbus: couldn't initialize system bus:
Could not connect: No such file or directory
~]# dnf --assumeno remove NetworkManager
Dependencies resolved.
==
Package
Architecture Version
Repository Size
==
Removing:
NetworkManager
x86_64 1:1.20.4-1.fc31
@fedora9.6 M
Removing dependent packages:
NetworkManager-adsl
x86_64 1:1.20.4-1.fc31
@fedora 52 k
NetworkManager-bluetooth
x86_64 1:1.20.4-1.fc31
@fedora158 k
NetworkManager-ppp
x86_64 1:1.20.4-1.fc31
@fedora 91 k
Re: [systemd-devel] F30->F31 systemd-networkd no IPv6 autoconfiguration
Having two networking systems running at once can cause all sorts of problems, not sure if this is the issue here or why NM is still starting but you can try using 'systemctl mask' on it to completely prevent it from running. On Fri, Nov 8, 2019, 7:37 PM Anthony Joseph Messina wrote: > I apologize if this isn't the right place to post this request for > assistance. I've attempted the Fedora User's list with no luck and would > prefer to ask before filing a bug. > > After a successful "dnf systemd upgrade" F30->F31, I'm finding that a few > of my machines which use systemd-networkd instead of NetworkManager are no > longer autoconfiguring IPv6 addresses. I also noticed that even though > NetworkManager is disabled, it is initiated in early boot, which I'm not > sure is related. > > It appears as though the system isn't assigning the link-local address and > therefore can't communicate via IPv6. If anyone has any pointers on where > to begin, I'd appreciate it. Thanks. -A > > Both systems below use the following > /etc/systemd/network/10-wired-dhcp.network: > > [Match] > Name=en* > > [Network] > DHCP=yes > IPv6PrivacyExtensions=yes > > > Both systems are running: > kernel-5.3.8-300.fc31.x86_64 > systemd-243-4.gitef67743.fc31.x86_64 > NetworkManager-1.20.4-1.fc31.x86_64 > > > A system that IS working with systemd-networkd displays the following > debug output: > > eno1: New device has no master, continuing without > eno1: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST > eno1: Link 2 added > eno1: udev initialized link > eno1: State changed: pending -> initialized > eno1: Saved original MTU: 1500 > eno1: Remembering foreign address: fe80::f64d:30ff:fe6e:2cf5/64 (valid > forever) > eno1: Gained IPv6LL > eno1: Remembering route: dst: ff00::/8, src: n/a, gw: n/a, prefsrc: n/a, > scope: global, table: local, proto: boot, type: unicast > eno1: Remembering route: dst: fe80::f64d:30ff:fe6e:2cf5/128, src: n/a, gw: > n/a, prefsrc: n/a, scope: global, table: local, proto: kernel, type: local > eno1: Remembering route: dst: fe80::/64, src: n/a, gw: n/a, prefsrc: n/a, > scope: global, table: main, proto: kernel, type: unicast > eno1: Remembering updated address: fe80::f64d:30ff:fe6e:2cf5/64 (valid > forever) > eno1: Updating remembered route: dst: fe80::f64d:30ff:fe6e:2cf5/128, src: > n/a, gw: n/a, prefsrc: n/a, scope: global, table: local, proto: kernel, > type: local > eno1: Link state is up-to-date > eno1: found matching network '/etc/systemd/network/10-wired-dhcp.network' > Setting '/proc/sys/net/ipv6/conf/eno1/disable_ipv6' to '0' > eno1: IPv6 successfully enabled > Setting '/proc/sys/net/ipv6/conf/eno1/proxy_ndp' to '0' > Setting '/proc/sys/net/ipv6/conf/eno1/use_tempaddr' to '2' > Setting '/proc/sys/net/ipv6/conf/eno1/accept_ra' to '0' > eno1: Started LLDP. > eno1: Setting address genmode for link > eno1: Acquiring DHCPv4 lease > eno1: Discovering IPv6 routers > eno1: State changed: initialized -> configuring > eno1: Acquiring DHCPv6 lease on NDisc request > > > Another system that IS NOT working displays the following debug output > (note the missing Remembering foreign address and Gained IPv6LL lines): > > eno1: New device has no master, continuing without > eno1: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST > eno1: Link 2 added > eno1: udev initialized link > eno1: State changed: pending -> initialized > eno1: Saved original MTU: 1500 > eno1: Remembering route: dst: ff00::/8, src: n/a, gw: n/a, prefsrc: n/a, > scope: global, table: local, proto: boot, type: unicast > eno1: Link state is up-to-date > eno1: found matching network '/etc/systemd/network/10-wired-dhcp.network' > eno1: IPv6 successfully enabled > eno1: Started LLDP. > eno1: Setting address genmode for link > eno1: Acquiring DHCPv4 lease > eno1: State changed: initialized -> configuring > > -- > Anthony - https://messinet.com > F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6 > > > > ___ > 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] F30->F31 systemd-networkd no IPv6 autoconfiguration
I apologize if this isn't the right place to post this request for assistance. I've attempted the Fedora User's list with no luck and would prefer to ask before filing a bug. After a successful "dnf systemd upgrade" F30->F31, I'm finding that a few of my machines which use systemd-networkd instead of NetworkManager are no longer autoconfiguring IPv6 addresses. I also noticed that even though NetworkManager is disabled, it is initiated in early boot, which I'm not sure is related. It appears as though the system isn't assigning the link-local address and therefore can't communicate via IPv6. If anyone has any pointers on where to begin, I'd appreciate it. Thanks. -A Both systems below use the following /etc/systemd/network/10-wired-dhcp.network: [Match] Name=en* [Network] DHCP=yes IPv6PrivacyExtensions=yes Both systems are running: kernel-5.3.8-300.fc31.x86_64 systemd-243-4.gitef67743.fc31.x86_64 NetworkManager-1.20.4-1.fc31.x86_64 A system that IS working with systemd-networkd displays the following debug output: eno1: New device has no master, continuing without eno1: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST eno1: Link 2 added eno1: udev initialized link eno1: State changed: pending -> initialized eno1: Saved original MTU: 1500 eno1: Remembering foreign address: fe80::f64d:30ff:fe6e:2cf5/64 (valid forever) eno1: Gained IPv6LL eno1: Remembering route: dst: ff00::/8, src: n/a, gw: n/a, prefsrc: n/a, scope: global, table: local, proto: boot, type: unicast eno1: Remembering route: dst: fe80::f64d:30ff:fe6e:2cf5/128, src: n/a, gw: n/a, prefsrc: n/a, scope: global, table: local, proto: kernel, type: local eno1: Remembering route: dst: fe80::/64, src: n/a, gw: n/a, prefsrc: n/a, scope: global, table: main, proto: kernel, type: unicast eno1: Remembering updated address: fe80::f64d:30ff:fe6e:2cf5/64 (valid forever) eno1: Updating remembered route: dst: fe80::f64d:30ff:fe6e:2cf5/128, src: n/a, gw: n/a, prefsrc: n/a, scope: global, table: local, proto: kernel, type: local eno1: Link state is up-to-date eno1: found matching network '/etc/systemd/network/10-wired-dhcp.network' Setting '/proc/sys/net/ipv6/conf/eno1/disable_ipv6' to '0' eno1: IPv6 successfully enabled Setting '/proc/sys/net/ipv6/conf/eno1/proxy_ndp' to '0' Setting '/proc/sys/net/ipv6/conf/eno1/use_tempaddr' to '2' Setting '/proc/sys/net/ipv6/conf/eno1/accept_ra' to '0' eno1: Started LLDP. eno1: Setting address genmode for link eno1: Acquiring DHCPv4 lease eno1: Discovering IPv6 routers eno1: State changed: initialized -> configuring eno1: Acquiring DHCPv6 lease on NDisc request Another system that IS NOT working displays the following debug output (note the missing Remembering foreign address and Gained IPv6LL lines): eno1: New device has no master, continuing without eno1: Flags change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST eno1: Link 2 added eno1: udev initialized link eno1: State changed: pending -> initialized eno1: Saved original MTU: 1500 eno1: Remembering route: dst: ff00::/8, src: n/a, gw: n/a, prefsrc: n/a, scope: global, table: local, proto: boot, type: unicast eno1: Link state is up-to-date eno1: found matching network '/etc/systemd/network/10-wired-dhcp.network' eno1: IPv6 successfully enabled eno1: Started LLDP. eno1: Setting address genmode for link eno1: Acquiring DHCPv4 lease eno1: State changed: initialized -> configuring -- Anthony - https://messinet.com F9B6 560E 68EA 037D 8C3D D1C9 FF31 3BDB D9D8 99B6 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd219 and Realtime priority
On Fr, 08.11.19 14:07, Jon Sykes (jono.syke...@gmail.com) wrote: > Thanks for the info Lukas; much appreciated. As a side note for this would > it be useful to denote which versions of systemd the page > https://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/ is > valid for? That page cost me a fair amount of time trying to apply the > solutions and trying to work out what I was doing wrong before I managed to > find the information about those options not being applicable anymore It's very out of date. It#s on my todo list to update it, but I so far didn't find the time to. Ignore it. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd219 and Realtime priority
Thanks for the info Lukas; much appreciated. As a side note for this would it be useful to denote which versions of systemd the page https://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/ is valid for? That page cost me a fair amount of time trying to apply the solutions and trying to work out what I was doing wrong before I managed to find the information about those options not being applicable anymore Thanks Jon On Fri, 8 Nov 2019 at 10:24, Lukas Nykryn wrote: > Hi! > > I think you should contact the Red Hat support with this question. Most of > the distribution have CONFIG_RT_GROUP_SCHED disabled since in the general > use cases people don't use it at all. RHEL is an exception here, since we > keep that feature on, despite the recommendation of upstream, to cover some > weird use-cases. > > You also might want to look at https://access.redhat.com/articles/3696121 > > Lukas > > > > čt 7. 11. 2019 v 18:15 odesílatel Jon Sykes > napsal: > >> Hi, >> >> I'm using RHEL7 with systemd-219-62.el7_6.6.x86_64. I've recently hit an >> issue whereby a process started by a systemd service cannot assign itself >> realtime priority. Digging into the issue it seems that it is because >> systemd starts all services within a cpu/system.slice/ cgroup >> which by default wont be allocated any rt runtime through >> the cpu.rt_runtime_us value. >> >> I searched for info on how to solve this issue and came across >> https://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/ >> unfortunately >> 2 of the 3 suggestions don't seem to be valid anymore: >> >> - /etc/systemd/system.conf and set DefaultControllers= >> This appears to have been removed as an option. When I tried this it had >> no effect >> >> - edit your service file, and add ControlGroup=cpu:/ to its [Service] >> section >> This doesn't appear to be a valid option anymore: >> https://bugzilla.redhat.com/show_bug.cgi?id=86 >> >> This only leaves the option of setting cpu.rt_runtime_us value for the >> unit, however, there are a number of reasons why this isn't ideal and if >> the root cgroup config changes at any point then the value I choose isn't >> guaranteed to do what I had intended. (as pointed out in: >> https://lists.freedesktop.org/archives/systemd-devel/2015-March/029144.html >> ) >> >> Is there any other way to get my service to run within a cgroup that >> allows it to assign itself realtime priority? It would seem preferable to >> be able to just run the service in the root cgroup - is this possible >> through configuration? >> >> Thanks >> Jon >> ___ >> 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] Thoughts about storing unit/job statistics
Hello all, As part of work on a GNOME feature for monitoring how often the user uses applications (for example, to let them know that they spent 4 hours in the Slack app, or 17 hours playing games), I’m trying to work out the best way to store data like that. If we assume the system is using systemd user sessions, then an application being run is actually a unit being started, and so the data we want to store is actually the duration of each unit run. A related issue is that of storing network usage data per unit, to allow the user to see which apps have been using the most data over the last (say) month. If I were to implement this as a separate daemon, it would need to be active all the time, listening to UnitNew/UnitRemoved/JobNew/JobRemoved signals from systemd. That seems like a waste of a process. Let’s call this problem 0. One approach would be to store this data in the journal, but (problems 1-3): 1. We can’t control how long the journal data is around for, or even if it’s set to persist. 2. This data couldn’t be stored separately (for example, in a separate journal file) so that the user could delete it all together and separately from the rest of the journal. (To reset their usage data.) 3. Querying it from the journal would mean filtering and iterating through everything else in the journal, which is not going to be the fastest (although it probably wouldn’t be too bad, and we would be appending a lot more often than we would be querying). So I have two questions: 1. Does this seem like the kind of functionality which should go into the journal, if it was modified to address problems 1-3 above? 1a. If not, do you have any suggestions for how to implement it so that problem 0 above is not an issue, i.e. we don’t have to keep a daemon running all the time just to record a small chunk of data once every few minutes? 2. Does this seem like a subset of a larger bit of functionality, storing metrics about units and jobs for later analysis, which might be interesting to non-desktop users of systemd? Thanks, Philip ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd219 and Realtime priority
Hi! I think you should contact the Red Hat support with this question. Most of the distribution have CONFIG_RT_GROUP_SCHED disabled since in the general use cases people don't use it at all. RHEL is an exception here, since we keep that feature on, despite the recommendation of upstream, to cover some weird use-cases. You also might want to look at https://access.redhat.com/articles/3696121 Lukas čt 7. 11. 2019 v 18:15 odesílatel Jon Sykes napsal: > Hi, > > I'm using RHEL7 with systemd-219-62.el7_6.6.x86_64. I've recently hit an > issue whereby a process started by a systemd service cannot assign itself > realtime priority. Digging into the issue it seems that it is because > systemd starts all services within a cpu/system.slice/ cgroup > which by default wont be allocated any rt runtime through > the cpu.rt_runtime_us value. > > I searched for info on how to solve this issue and came across > https://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/ > unfortunately > 2 of the 3 suggestions don't seem to be valid anymore: > > - /etc/systemd/system.conf and set DefaultControllers= > This appears to have been removed as an option. When I tried this it had > no effect > > - edit your service file, and add ControlGroup=cpu:/ to its [Service] > section > This doesn't appear to be a valid option anymore: > https://bugzilla.redhat.com/show_bug.cgi?id=86 > > This only leaves the option of setting cpu.rt_runtime_us value for the > unit, however, there are a number of reasons why this isn't ideal and if > the root cgroup config changes at any point then the value I choose isn't > guaranteed to do what I had intended. (as pointed out in: > https://lists.freedesktop.org/archives/systemd-devel/2015-March/029144.html > ) > > Is there any other way to get my service to run within a cgroup that > allows it to assign itself realtime priority? It would seem preferable to > be able to just run the service in the root cgroup - is this possible > through configuration? > > Thanks > Jon > ___ > 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
