Re: [systemd-devel] systemd-networkd: switch between several static network setups on wired connection
Hi Torsten, On Wed, Mar 29, 2023 at 02:58:05PM +0200, f...@igh.de wrote: > > Dear Systemd Folx, > > > > I have a laptop that I run at different locations with different > networks. I want to have static(!) network setup (address, gateway, DNS, > NTP) for my wired adapter on these networks. I can define setup for > each of them in a .network file matching my interface (eth0), but only > the alphabetically first of them is taken into account. > > For now I create a symbolic link to the desired config and restart > systemd-netword. > > Is there a more straight forward way for chosing the actual setup, for > instance using networkctl? Unless you have something that networkd can notice is different about the interface from one location to another (cf. [Match] in the systemd.network(5) man page [1]), you will have to give it a kick in order to change its behaviour. But restarting the entire daemon is not strictly necessary. You can update the symlink you described and then run 'networkctl reload' to make it reload the .network and .link files. I think you will then have to run 'networkctl reconfigure eth0' as well. [1] https://www.freedesktop.org/software/systemd/man/systemd.network.html#%5BMatch%5D%20Section%20Options > > Might there also be a chance to automatically chose a wired setup > depending on a local SSID visible? SSID is a wireless thing so it will not be something that a wired interface can match on. But for wireless interfaces you can achieve what you want much better by using SSID= in the [Match] section. > > Thanks and best regards > > > Torsten Kind regards, Alvin
Re: [systemd-devel] dependent services status
Hi Ted, On Thu, Nov 17, 2022 at 08:52:00AM -0600, Ted Toth wrote: > I have a set of services that depend on each other however when > services are started and considered 'active' that does not necessarily > mean they are in a state that a dependent service requires them to be > in to operate properly (for example an inotify watch has been > established). systemd services, I think, have a substate, is there a > way I can set that to a custom value to indicate the services idea of > its own state? If you set Type=notify in the [Service] block of the service definition file, you can use the sd_notify(3) API: https://www.freedesktop.org/software/systemd/man/sd_notify.html Is that what you are looking for? Kind regards, Alvin
Re: [systemd-devel] Query degraded state
Hi, On Thu, Apr 28, 2022 at 04:03:01PM +0100, Barry Scott wrote: > Is there a command I can use to test for the degraded state? > > I could parsing the output of systemctl-failed or > syetemctl status but was looking for something less fragile. I think the correct way to do this programatically is via the dbus API, but if you want something moderately greppable, try: # systemctl show | grep SystemState SystemState=running Hope that helps. Kind regards, Alvin
Re: [systemd-devel] Systemd setup DSA interfaces in port mode and bond them together?
On 11/19/21 12:52, Paul Menzel wrote: > >> Hmm, looks like I might just have to wait a bit until we can step up to >> 5.11. We just stepped up to 5.10.69. IMX8 Freescale yocto lags a bit. >> And too bleeding edge hurts. > > Well, I know opinions differ on that, but in this case, it obviously > hurt that you use an old Linux kernel, as the problem you have might be > already fixed it current Linux kernels. > > It’d be great if you verified, that the problem is fixed in Linux 5.15, > which is also an LTS series, and then maybe get the commits in questions > into the 5.10.x stable series. I don't think the commits in question will be suitable for stable, since they are not bugfixes as such. DSA still works just fine without them. But yes, staying up-to-date on kernel releases is always salient advice. :-) Kind regards, Alvin
Re: [systemd-devel] Systemd setup DSA interfaces in port mode and bond them together?
On 11/18/21 23:25, Brian Hutchinson wrote:
> Hi Alvin,
>
>
> On Thu, Nov 18, 2021 at 4:20 PM Alvin Šipraga <mailto:a...@bang-olufsen.dk>> wrote:
>
> Hi Brian,
>
> On 11/18/21 01:20, Brian Hutchinson wrote:
> > Yet another update, I was able to get it working .. but feel
> like it is
> > a hack so comments welcome ... see below:
> >
>
>
>
> >
> > I tried and tried to get eth0 to come up before the bond was brought
> > up. I had everything named in lexical order but didn't appear to
> > matter. I added a eth0.network file and in it specified
> > |ActivationPolicy=|always-up and other things but could not get
> eth0 to
> > come up.
>
> What kernel version are you using? Since Linux 5.11 we have the
>
>
> I'm using linux-fslc-imx 5.10.69
>
> following two changes ([1] and [2]) which should automatically bring
> up/down the master (eth0) whenever user ports (lan1, lan2) are brought
> up/down. Please confirm whether or not you are using 5.11 or later.
>
>
> I don't think that will work either. eth0 has to be up and stay up or
> DSA driver won't work at all. eth0 has to be up or the slaves can't be
> added to the bond.
This use-case is also addressed in the newer kernels (>=5.11), see the
below commit. It is not only when a user port is brought up (as I
summarized it), but rather when it is opened.
commit 9d5ef190e5615a7b63af89f88c4106a5bc127974
Author: Vladimir Oltean
Date: Fri Feb 5 15:37:10 2021 +0200
net: dsa: automatically bring up DSA master when opening user port
DSA wants the master interface to be open before the user port is
due to
historical reasons. The promiscuity of interfaces that are down used to
have issues, as referenced Lennert Buytenhek in commit df02c6ff2e39
("dsa: fix master interface allmulti/promisc handling").
The bugfix mentioned there, commit b6c40d68ff64 ("net: only invoke
dev->change_rx_flags when device is UP"), was basically a "don't do
that" approach to working around the promiscuity while down issue.
Further work done by Vlad Yasevich in commit d2615bf45069 ("net: core:
Always propagate flag changes to interfaces") has resolved the
underlying issue, and it is strictly up to the DSA and 8021q drivers
now, it is no longer mandated by the networking core that the master
interface must be up when changing its promiscuity.
From DSA's point of view, deciding to error out in dsa_slave_open
because the master isn't up is
(a) a bad user experience and
(b) knocking at an open door.
Even if there still was an issue with promiscuity while down, DSA could
still just open the master and avoid it.
Doing it this way has the additional benefit that user space can now
remove DSA-specific workarounds, like systemd-networkd with
BindCarrier:
https://github.com/systemd/systemd/issues/7478
And we can finally remove one of the 2 bullets in the "Common pitfalls
using DSA setups" chapter.
Tested with two cascaded DSA switches:
$ ip link set sw0p2 up
fsl_enetc :00:00.2 eno2: configuring for fixed/internal link mode
fsl_enetc :00:00.2 eno2: Link is Up - 1Gbps/Full - flow control
rx/tx
mscc_felix :00:00.5 swp0: configuring for fixed/sgmii link mode
mscc_felix :00:00.5 swp0: Link is Up - 1Gbps/Full - flow
control off
8021q: adding VLAN 0 to HW filter on device swp0
sja1105 spi2.0 sw0p2: configuring for phy/rgmii-id link mode
IPv6: ADDRCONF(NETDEV_CHANGE): eno2: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): swp0: link becomes ready
Signed-off-by: Vladimir Oltean
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: Jakub Kicinski
>
> If you look back up the thread where I'm doing the commands manually
> (I'll re-copy below) ... the first thing is to bring eth0 up. If that
> doesn't happen, nothing else works.
I forgot about the bond in my reply. Does it work if you do
BindCarrier=eth0 from the bond's .network file? You might be out of luck
depending on how networkd implements BindCarrier=, but hopefully
something like that works. Remember also that you need a .network file
covering eth0, even though it's just a conduit and you don't want to
give it an IP. You can do that by omitting the [Network] section and
just having a [Match] on eth0.
>
> These are the manual steps that work. This is what I'm trying to
> automate the "systemd way". I read that "bond0" is somehow reserved so
> my systemd.netdev and .network files use bond1.
>
> #!/bin/bash
>
> # Create a redundant bond b
Re: [systemd-devel] Systemd setup DSA interfaces in port mode and bond them together?
Hi Brian, On 11/18/21 01:20, Brian Hutchinson wrote: > Yet another update, I was able to get it working .. but feel like it is > a hack so comments welcome ... see below: > > > I tried and tried to get eth0 to come up before the bond was brought > up. I had everything named in lexical order but didn't appear to > matter. I added a eth0.network file and in it specified > |ActivationPolicy=|always-up and other things but could not get eth0 to > come up. What kernel version are you using? Since Linux 5.11 we have the following two changes ([1] and [2]) which should automatically bring up/down the master (eth0) whenever user ports (lan1, lan2) are brought up/down. Please confirm whether or not you are using 5.11 or later. If you are using an older kernel, and systemd is version 243 or later, you can use the BindCarrier= setting (see [1]) in the [Network] section of your .network file(s) for lan1 and lan2. Something like this: [Match] Name=lan* [Network] BindCarrier=eth0 See also [3]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d5ef190e5615a7b63af89f88c4106a5bc127974 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c0a8a9c274936543e436aef691499304ce3127dc [3] https://www.freedesktop.org/software/systemd/man/systemd.network.html#BindCarrier= [4] https://github.com/systemd/systemd/issues/7478#issuecomment-514562190 If both your kernel and systemd are old, I think you'll have to use something like your hack. One more thing: > [Service] > ExecStart=/usr/local/bin/eth0-up.sh > RemainAfterExit=yes > > [Install] > WantedBy=multi-user.target > > cat /usr/local/bin/eth0-up.sh > #!/bin/bash > ip link set eth0 up You don't need a separate shell script, you can just invoke the ip command directly: [Service] ExecStart=/usr/bin/ip link set eth0 up ... Kind regards, Alvin
[systemd-devel] timesyncd may try to sync when system is not really online
Hello, systemd-timesyncd listens for changes in network state and will start a timesync when it determines that the system is online. It does this via network_is_online(), which just queries the global carrier and address state advertised by systemd-networkd. systemd-networkd determines the global carrier and address state by simply iterating through all links and taking the maximum of the link carrier and address states. However, a routable link does not necessarily mean that the system is online. One example is with wireless access point interfaces: an AP is set up with hostapd and networkd configures a static IP address on that interface, making it routable. By the above, this causes timesyncd to attempt a timesync that is doomed to fail. We are having trouble with this logic because we start hitting timesyncd's internal rate limiter. After a non-AP interface gets an IP and we are truly "online", timesyncd will try to start a timesync, but may defer it for up to 30 seconds due to rate limiting. Ideally, timesyncd should be able to distinguish between the two cases such that it can ignore the state of the AP interface and avoid spurious timesync attempts. I can think of a few solutions to this problem but I wanted to consult the mailing list to see if anybody has some better ideas. Here are some proposals, in order of descending preference: 1. Add a new [Link] option NotForOnline= (or similar) to systemd.networkd(5) to indicate that this link being routable does not imply that the system is online. This could also implicitly set RequiredForOnline=no if desired. Then: i) Parse the above option in network_is_online() to exclude certain links; or ii) parse the above option only in timesyncd. Note that the only user of network_is_online() is timesyncd anyway. 2. Add a new [Link] option IgnoreLinkState= (or similar) to systemd.network(5) to indicate to systemd-networkd that this link's carrier and address state should not be factored into the calculation of global carrier and address state. 3. Same as (1) above, but rather than adding a new option, just parse RequiredForOnline=. 4. Something like the above, but set the ignored or allowed interfaces in timesyncd.conf. 5. Make the rate limiter user-configurable so that a user can disable or tune it accordingly. Options (1) and (2) seem to be the only decent solutions IMO. But I'm a bit cautious of (2) because I don't know what other stuff might be depending on systemd's global state. Happy to hear other ideas on this. Could be that we are also doing something wrong and there is already a knob to twist. I can provide further details if necessary. I'll prepare a patch once I've waited some time for any feedback here. Kind regards, Alvin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Activate netdev only on demand (e.g. for wireguard connection)
Hi, On 3/11/21 11:01 AM, Reindl Harald wrote: > > > Am 11.03.21 um 06:36 schrieb Amish: >> Hello >> >> So I have a wireguard setup which I use to connect to my server. >> >> But I do not connect to it daily, just once a in a while. >> >> I have setup wg0.netdev file and wg0.network file and all is working >> fine. >> >> But how do I set it up such that interface wg0 does not connect >> automatically but comes up only when I run: >> >> #networkctl up wg0 >> >> Effectively I want wireguard to connect/disconnect on demand > > given that wireguard runs directly in the kernel and has no single > userland process what problem would you like to solve and why? Seems like a perfectly mainstream use-case, no? Some people don't want to be hooked up to their VPN by default - particularly if it reroutes all their Internet traffic - so it makes sense to have this controlled manually. Amish, I think you described your problem perfectly fine. It sounds like you want to add: [Network] ActivationPolicy=manual to your wg0.network file. More info here: https://www.freedesktop.org/software/systemd/man/systemd.network.html#ActivationPolicy= If you are only using the wireguard interface to connect to a specific IP or subnet (e.g. your server's), you can also fine-tune the routes in your .network file. That way you might be able to live with - and even prefer - the interface always being up. Kind regards, Alvin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [EXT] Re: Using timedatectl on a readonly rootfile system using mender
Hi, On 9/8/20 4:12 PM, Colin Guthrie wrote: > 2. Set your /etc/ master image to make /etc/localtime to be a symlink to > /run/localtime and then ensure /run/localtime is a symlink to the > appropriate file in /usr during early boot (e.g. in initramfs). Then > when you want to to change the timezone, just update the /run/ symlink. This might not work as expected - systemd sometimes assumes that /etc/localtime is a symlink into /usr/share/zoneinfo and will not understand double symlinks. See src/basic/time-util.c:get_timezone() for at least one example. It's not too difficult to work around and I can provide a patch if anybody wants it, although I don't think it will safely deal with circular symlinks. It isn't something that upstream will be interested in accommodating, based on Lennart's reasoning in this thread. If you choose to go this way, /etc/localtime could also point to a symlink on a rw mounted filesystem, allowing for writable and persistent storage of timezone settings. But as Colin points out, you won't be able to make such changes with systemd tooling. The bind mount solution will probably work without patching systemd, assuming that it doesn't disagree with the mender restrictions you mentioned. Alvin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
