[systemd-devel] Need clarity on journald.conf options
Hello, I am trying to seek clarity on few of journald.conf options. This is what I have set in journald.conf.d/99-local.conf [Journal] # allocate maximum 100GB for all journal files combined SystemMaxUse=100G # But keep atleast 15% of disk space; free. # no value specified - for default (i.e. 15%) SystemKeepFree= # Maximum size of one journal file should not exceed 200MB. SystemMaxFileSize=200M # But rotate it every week (even if size is less than 200MB) MaxFileSec=1week # No limit on number of journal files created (see query below) SystemMaxFiles=0 # Keep files for 3 years. (unless MaxUse/KeepFree is crossed) MaxRetentionSec=3year Please let me know if settings are correct (as mentioned in annotation) I am confused about SystemMaxUse documentation which says "each value is capped to 4G". Does it mean that 4G is maximum I can set? i.e. maximum space that all journal files combined will be 4G even if I set it to 100G? I am also confused about SystemMaxFiles=0, as documentation states that 100 is default. So does setting it to ZERO set it to default i.e. 100 or it sets to unlimited? I do not want files to vanish after 2 years i.e. after 104 rotations. Documentation does not state how to set it to unlimited. i.e. SystemMaxFiles= (should mean default i.e. 100) SystemMaxFiles=0 (should mean unlimited and not 100) I can set it to very high value though to avoid any confution. May be documentation needs to be little more clear? Please guide, Thank you Amish. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 回复： systemctl can't execute stop actually, whenservice is started by other way
On Wednesday 28 June 2017 02:08 PM, wrote: Is there a way to execute stop actually, even the status is inactive. On Tue, 27.06.17 13:48, (624001...@qq.com <mailto:624001...@qq.com>) wrote: > for example: service nscd > 1.execute: systemctl stop nscd.service > stop nscd process actually > 2.execute: /usr/bin/nscd > start nscd by shell command Why dont you (or your script) start it with: systemctl start nscd Then status and stop will also work as expected. Amish. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent address on "Lost carrier"
Resending my previous email as I would really want this feature.
I asked for help on IRC channel too but it hardly appears active.
Amish.
On Friday 16 June 2017 01:06 PM, Lennart Poettering wrote:
On Thu, 15.06.17 18:22, Amish (anon.am...@gmail.com) wrote:
Hmm, that wasn't the actual question though, was it? The point was just
to make networkd ignore carrier status (i.e. often there's no need to
remove addresses just because the interface is down for a moment), not
to stop managing halfway.
Adding an option "IgnoreCarrier=" or so would be OK I figure. Best way
to get it implemented is submitting a PR for it ;-)
Ok I am completely new to systemd.
So looking at the code and trying to figure out the flow.
I believe I have to add IgnoreCarrier option in link-config.[ch] file.
Function that handles "Lost/Gain Carrier" is in networkd-link.c
There are two struct here: one is "link_config" and other is "Link"
link-config is what will store boolean ignore_carrier. (or any
configuration value)
Link is what stores actual link data. (carrier status)
I am kind of stuck at one place. Searched a lot - but could not figure out.
I could not find anyway to find underlying "link_config" associated with
"Link".
For example:
Inside networkd-link.c how do I check this:
if (Link->link_config->ignore_carrier) {
// do nothing
}
else {
// continue existing code
}
Please also have a look at whatever I have done so far, here:
https://github.com/amishxda/systemd/commits/master
Thanks
Amish.
PS: Dont know if this list is right place to ask such questions.
But since its "-devel" mailing list I am posting here.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent address on "Lost carrier"
On Thursday 15 June 2017 03:07 PM, Mantas Mikulėnas wrote: On Thu, Jun 15, 2017 at 11:21 AM, Lennart Poettering <lenn...@poettering.net <mailto:lenn...@poettering.net>> wrote: On Tue, 13.06.17 21:44, Amish (anon.am...@gmail.com <mailto:anon.am...@gmail.com>) wrote: > Hello, > > I have the following in /etc/systemd/network/25-eth0.network > > [Match] > MACAddress=00:11:22:33:44:55 > > [Network] > Address=192.168.1.32/24 <http://192.168.1.32/24> > Gateway=192.168.1.1 > > Now I have few "dynamic" routes where destination IP keeps changing. > > Example: > /usr/bin/ip route add to 1.2.3.4 via 192.168.1.2 (Different gateway) > > Many more routes are added by one script which keeps adding / deleting > routes based on certain algorithms. > > Since destination IP keeps changing, I can not put it in [Route] section. > > Now my problem is, if for any reason the interface loses carrier (cable > fault / switch / router reboot), the IP associated with it is removed and > hence all the routes added by script gets lost. > > My question is how to stop this? > > How do I tell systemd to not to delete IP address on "Lost carrier"? > > I tried with: > > BindCarrier=lo > OR > BindCarrier=eth0 > OR > BindCarrier=lo eth0 > > But none worked. > > Any idea / suggestions? Something similar to - CriticalConnection for DHCP? > > Or may be we can have Persistent=true in "[Network]" OR "[Address]" section? This is really not how networkd is supposed to be used. Either it manages an interface in its entirety or not at all. It's not designed to manage an interface only "half-way", i.e. manage addresses but not the routes. Hmm, that wasn't the actual question though, was it? The point was just to make networkd ignore carrier status (i.e. often there's no need to remove addresses just because the interface is down for a moment), not to stop managing halfway. Yes thats what I am looking for. I wonder, if IP is "static IP" why should it remove it from interface? or atleast let administrator have an option to specify if IP should be deleted or not on "Lost carrier" Also on a side note: Even if I use [Route] section in .network file. There is still an issue. Say I have two WAN connections. WAN1 and WAN2. All traffic goes through WAN1. (default route) But say I add [Route] section, telling that traffic to some networks is supposed to go via WAN2. But no sooner the "Carrier" gets lost on WAN2, the routes added by [Route] section also gets deleted. And traffic that was supposed to go via WAN2, start going through WAN1. Ofcourse routes get readded when WAN2 "Gains carrier" but by that time some connection get dropped / interrupted / rejected by RST as packets went through WAN1 (which was not allowed). Please consider of adding an option to Ignore "Lost carrier" atleast for static IPs. Thanks and regards, Amish. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent address on "Lost carrier"
On Friday 16 June 2017 01:06 PM, Lennart Poettering wrote:
On Thu, 15.06.17 18:22, Amish (anon.am...@gmail.com) wrote:
Hmm, that wasn't the actual question though, was it? The point was just
to make networkd ignore carrier status (i.e. often there's no need to
remove addresses just because the interface is down for a moment), not
to stop managing halfway.
Adding an option "IgnoreCarrier=" or so would be OK I figure. Best way
to get it implemented is submitting a PR for it ;-)
Ok I am completely new to systemd.
So looking at the code and trying to figure out the flow.
I believe I have to add IgnoreCarrier option in link-config.[ch] file.
Function that handles "Lost/Gain Carrier" is in networkd-link.c
There are two struct here: one is "link_config" and other is "Link"
link-config is what will store boolean ignore_carrier. (or any
configuration value)
Link is what stores actual link data. (carrier status)
I am kind of stuck at one place. Searched a lot - but could not figure out.
I could not find anyway to find underlying "link_config" associated with
"Link".
For example:
Inside networkd-link.c how do I check this:
if (Link->link_config->ignore_carrier) {
// do nothing
}
else {
// continue existing code
}
Please also have a look at whatever I have done so far, here:
https://github.com/amishxda/systemd/commits/master
Thanks
Amish.
PS: Dont know if this list is right place to ask such questions.
But since its "-devel" mailing list I am posting here.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Persistent address on "Lost carrier"
Hello, I have the following in /etc/systemd/network/25-eth0.network [Match] MACAddress=00:11:22:33:44:55 [Network] Address=192.168.1.32/24 Gateway=192.168.1.1 Now I have few "dynamic" routes where destination IP keeps changing. Example: /usr/bin/ip route add to 1.2.3.4 via 192.168.1.2 (Different gateway) Many more routes are added by one script which keeps adding / deleting routes based on certain algorithms. Since destination IP keeps changing, I can not put it in [Route] section. Now my problem is, if for any reason the interface loses carrier (cable fault / switch / router reboot), the IP associated with it is removed and hence all the routes added by script gets lost. My question is how to stop this? How do I tell systemd to not to delete IP address on "Lost carrier"? I tried with: BindCarrier=lo OR BindCarrier=eth0 OR BindCarrier=lo eth0 But none worked. Any idea / suggestions? Something similar to - CriticalConnection for DHCP? Or may be we can have Persistent=true in "[Network]" OR "[Address]" section? Thanks in advance, Regards Amish. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 235
On Friday 06 October 2017 07:36 PM, Susant Sahani wrote: On Fri, Oct 6, 2017 at 3:03 PM, Amish <anon.am...@gmail.com <mailto:anon.am...@gmail.com>> wrote: Hello, Thank you. I am curious to know if this new setting: ConfigureWithoutCarrier=1 would resolve my query few months back. (Although I would not be able to try it out yet for 2-3 weeks) Subject: Persistent address on "Lost carrier" Link: https://lists.freedesktop.org/archives/systemd-devel/2017-June/039041.html <https://lists.freedesktop.org/archives/systemd-devel/2017-June/039041.html> i.e. systemd-networkd should not remove IP address and routes on "Lost carrier". I looked at the code here: https://github.com/systemd/systemd/blob/master/src/network/networkd-link.c <https://github.com/systemd/systemd/blob/master/src/network/networkd-link.c> It appears that - it is still not so. i.e. If carrier is lost (eg. cable removed / network issues) then link_update() function would go ahead and call link_carrier_lost() and unconfigure the device. i.e. it will not obey ConfigureWithoutCarrier=1 which I believe it should. No that is not intended use case for ConfigureWithoutCarrier=. It will only look during configuring the the link. While configuring a link even if that link has no carrier it will go on set it as configured for example empty bridges. https://github.com/systemd/systemd/issues/6645 <https://github.com/systemd/systemd/issues/6645>. But in your case It is already configured via gained carrier not via ConfigureWithoutCarrier even if you set it to true. My issue is on similar lines too. May be extension to it. i.e. if ConfigureWithoutCarrier is set then it should not Un-configure when carrier is lost. The problem I face is that I have some IPs via certain "secure" interface. (set via [Route]) But if carrier is lost for a while for any reason then IP address as well as routes get deleted. When routes get deleted then packets to those IPs start going via "default" route which becomes security risk. I can workaround this via firewall. But it would be great if ConfigureWithoutCarrier is checked for carrier_lost case too and IP is not un-configured. Thanks and regards, Amish. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 235
Hello, Thank you. I am curious to know if this new setting: ConfigureWithoutCarrier=1 would resolve my query few months back. (Although I would not be able to try it out yet for 2-3 weeks) Subject: Persistent address on "Lost carrier" Link: https://lists.freedesktop.org/archives/systemd-devel/2017-June/039041.html i.e. systemd-networkd should not remove IP address and routes on "Lost carrier". I looked at the code here: https://github.com/systemd/systemd/blob/master/src/network/networkd-link.c It appears that - it is still not so. i.e. If carrier is lost (eg. cable removed / network issues) then link_update() function would go ahead and call link_carrier_lost() and unconfigure the device. i.e. it will not obey ConfigureWithoutCarrier=1 which I believe it should. Thanks and regards, Amish. On Friday 06 October 2017 01:54 PM, Lennart Poettering wrote: Heya! I am happy to announce systemd 235: * systemd-networkd's [Address] section in .network files gained a new Scope= setting for configuring the IP address scope. The [Network] section gained a new boolean setting ConfigureWithoutCarrier= that tells systemd-networkd to ignore link sensing when configuring the device. The [DHCP] section gained a new Anonymize= boolean option for turning on a number of options suggested in RFC 7844. A new [RoutingPolicyRule] section has been added for configuring the IP routing policy. The [Route] section has gained support for a new Type= setting which permits configuring blackhole/unreachable/prohibit routes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent address on "Lost carrier"
On Friday 16 June 2017 01:06 PM, Lennart Poettering wrote: On Thu, 15.06.17 18:22, Amish (anon.am...@gmail.com) wrote: Hmm, that wasn't the actual question though, was it? The point was just to make networkd ignore carrier status (i.e. often there's no need to remove addresses just because the interface is down for a moment), not to stop managing halfway. Adding an option "IgnoreCarrier=" or so would be OK I figure. Best way to get it implemented is submitting a PR for it ;-) Lennart Submitted PR for this: https://github.com/systemd/systemd/pull/7091 Please check Thank you, Amish ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] network config file - [Match] by AccessPointName, AccessPointMAC
Hello, Is there a way to do a [Match] in .network file to match wireless AccessPoint (by Name or MAC)? The reason is I go to 2-3 companies (plus home/friend's home wifi). 2 places dont have DHCP server ON; on wifi router but asks to set pre-defined static IP. Other places have DHCP active. So my idea is to have three .network files. File: 50-wlan0-c1.network. [Match] # this is wifi adapter MAC (not AP MAC) MACAddress=00:11:22:33:44:55 AccessPointName=company1-AP-Name [Network] Address=192.168.1.55/24 Gateway=192.168.1.1 = File: 50-wlan0-c2.conf [Match] # this is wifi adapter MAC (not AP MAC) MACAddress=00:11:22:33:44:55 AccessPointMAC=company2-AP-MAC [Network] Address=192.168.2.28/24 Gateway=192.168.2.10 # anything else on DHCP (50 processed before 51) File: 51-wlan0-dhcp.conf [Match] # this is wifi adapter MAC (not AP MAC) MACAddress=00:11:22:33:44:55 [Network] DHCP=yes This is how Android and iOS work i.e. they allow to set IP address per AP. I think Windows allows it too. (not sure though) Thanks and regards, PS: Hope I have not overlooked any existing setting or an easier way to do it. Amish. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] weird systemd-inhibit behaviour
Hello I am trying out systemd-inhibit as follows (on Arch Linux systemd version 238.133-4) but things dont seem to be working as expected. So I would like to know if I am missing something or is there a bug? Note: Everything is commented in /etc/systemd/logind.conf and there is no logind.conf.d directory in /run, /etc or /usr paths. Case 1) Inside multi-user.target - logged in to local tty as root. # systemd-inhibit --what=handle-hibernate-key:handle-lid-switch:handle-power-key:handle-suspend-key:idle:sleep:shutdown sleep 300 & # systemd-inhibit --list Who: sleep 300 (UID 0/root, PID 2544/systemd-inhibit) What: shutdown:sleep:idle:handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch Why: Unknown reason Mode: block ... $ echo switched to non-root user $ systemctl suspend Operation inhibited by "sleep 300" (PID 2544 "systemd-inhibit", user root), reason is "Unknown reason". Please retry operation after closing inhibitors and logging out other users. Alternatively, ignore inhibitors and users with 'systemctl suspend -i'. # echo back as root user # systemctl suspend # or halt or poweroff or reboot It goes ahead and performs the action even if I am not using -i (--ignore-inhibitors) switch. Documentation for -i (--ignore-inhibitors) states this: If any locks are taken, shutdown and sleep state requests will normally fail (regardless of whether privileged or not) and a list of active locks is printed. It clearly states - "privileged or not" - so even if I am running systemctl as root - it should not shutdown or sleep in above case. Case 2) Inside graphical.target - using KDE plasma - logged in as a non-root user. Same first command as in case 1). # logged into KDE as non-root user but command below run as root inside konsole # systemd-inhibit --what=handle-hibernate-key:handle-lid-switch:handle-power-key:handle-suspend-key:idle:sleep:shutdown sleep 300 & Now if I click KDE Menu-->Leave-->Suspend (Suspend to RAM) ... it blocks suspend and asks me for root password - stating that there is an inhibitor. But if I click KDE Menu-->Leave-->Shut Down ... it goes ahead and shuts down the machine. /usr/lib/sddm/sddm.conf.d/sddm.conf has these systemctl commands mentioned in it: HaltCommand=/usr/bin/systemctl poweroff RebootCommand=/usr/bin/systemctl reboot So I believe something is not right or I am doing something wrong in an unexpected way. Case 2) may be KDE related issue but case 1) should atleast have worked as expected. Can anyone else test? Thank you, Amish. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How safe are D and R directives for systemd-tmpfiles?
Hello,
I am interested in knowing how safe D and R directives for tmpfiles.d are?
If by some accident OR some packagers malicious intent - someone places
a file with "R /" in tmpfiles.d, would this erase everything?
Does systemd have a way of specifying that R and D should be applicable
only for /tmp or /var/{cache,run,tmp} only?
I could not locate anything on man page.
Thanks in advance,
Amish
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How safe are D and R directives for systemd-tmpfiles?
On 16/10/18 7:03 PM, Lennart Poettering wrote:
On Di, 16.10.18 18:14, Amish (anon.am...@gmail.com) wrote:
Does systemd have a way of specifying that R and D should be applicable only
for /tmp or /var/{cache,run,tmp} only?
When you invoke the systemd-tmpfiles binary you could specify
--prefix= to drop it's effect on non-listed prefixes.
Ah! Thank you. I overlooked this.
But is there a config file where this can be mentioned? (separate prefix
for create and remove)
OR can the default unit file be changed?
https://github.com/systemd/systemd/blob/master/units/systemd-tmpfiles-setup.service.in
to:
[Service]
Type=oneshot
RemainAfterExit=yes
EnvironmentFile=/etc/systemd/systemd-tmpfiles.env
ExecStart=@rootbindir@/systemd-tmpfiles --create --boot
--exclude-prefix=/dev $CREATEPREFIX
ExecStart=@rootbindir@/systemd-tmpfiles --remove --boot
--exclude-prefix=/dev $REMOVEPREFIX
SuccessExitStatus=65 73
I know I can setup an override file but just curious if above (or
similar) should be default.
Generally though: the directories where systemd-tmpfiles reads its
configuration from are owned by root and not writable by unprivileged
users. Moreover, the snippets are nothing you sloppily enter on the
command line, it's not a user-facing concept. Hence there's much less
chance to be misused on purpose or by accident.
I know but just wanted to be extra-safe.
And thank you for the prompt reply,
Amish.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On 16/01/19 11:52 pm, Lennart Poettering wrote: On Mi, 16.01.19 09:46, Colin Guthrie (gm...@colin.guthr.ie) wrote: Jérémy ROSEN wrote on 16/01/2019 08:24: yes... adding a "this is the start of the freeze" tag sounds like a low hanging fruit... it's almost no work for the core team to do, and it would be a clear signal that the freeze period is starting... And automated mails to the list when this happens would be nice too, as some folk will likely still follow the list more than they login to github (and for those that do login to github they may have many other projects so it could get lost in the noise) Hmm, I figure we'd need to set up a webhook for that... but someone would have to host this? Anyone wants to set this up? If so, that'd be excellent of course! Thanks, Lennart May be a user (say systemd-watch) with systemd-devel@lists.freedesktop.org as email id can be created on Github. And that user activates "Watch" feature with "Releases only" mode set. So Github will automatically send email to mailing list. (needs some testing by mailing list administrator) Regards, Amish. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bugfix release(s)
On 18/01/19 2:29 am, Lennart Poettering wrote: On Do, 17.01.19 07:05, Amish (anon.am...@gmail.com) wrote: On 16/01/19 11:52 pm, Lennart Poettering wrote: On Mi, 16.01.19 09:46, Colin Guthrie (gm...@colin.guthr.ie) wrote: Jérémy ROSEN wrote on 16/01/2019 08:24: yes... adding a "this is the start of the freeze" tag sounds like a low hanging fruit... it's almost no work for the core team to do, and it would be a clear signal that the freeze period is starting... And automated mails to the list when this happens would be nice too, as some folk will likely still follow the list more than they login to github (and for those that do login to github they may have many other projects so it could get lost in the noise) Hmm, I figure we'd need to set up a webhook for that... but someone would have to host this? Anyone wants to set this up? If so, that'd be excellent of course! Thanks, Lennart May be a user (say systemd-watch) with systemd-devel@lists.freedesktop.org as email id can be created on Github. And that user activates "Watch" feature with "Releases only" mode set. So Github will automatically send email to mailing list. (needs some testing by mailing list administrator) Hmm, interesting idea. But that would mean if people would everuse @systemd-watch in any comment on the github page they'd spam our mailing list? Or is there a way to turn that off? As I said - it needs some testing. May be filter can be put in mailing list which ignores mails from github with @mentions. We can check some sample emails received from Github and create filters accordingly. I have activated that option for me - so next time I would come to know difference in two types of emails. Regards, Amish ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd multipath routing
On 07/05/19 6:23 pm, Arnaud Lemaire wrote: Hi there, I'm trying to set up network multipath routing with systemd, but I cannot find a way to do it cleanly. The part that I cannot set up is : ``` $ ip route default nexthop via 192.168.11.1 dev inet.11 weight 5 nexthop via 192.168.22.2 dev inet.22 weight 10 ... ``` I'm getting around it with this unit: $ cat /etc/systemd/system/multipath-routing.service ... And it's working, but as soon as I unplug the network cable and plug it back, the routes are gone and the unit is not triggered Latest systemd.network (v242) supports: IgnoreCarrierLoss=true. This way routes should not vanish when cable is unplugged. Regards, Amish ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-inhibit fails when run from a service file
(Resending because earlier one, date 26/11/2019, did not get any response) Hello, I have a small perl program which downloads something. While downloading it inhibits (blocks) shutdown, reboot etc. The program runs as user "foo". Roughly the code is something like this: $ cat /home/foo/downloads/dnld.sh #!/bin/bash /usr/bin/systemd-inhibit --what=shutdown:sleep:idle:handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch --who=Downloader '--why=Important download in progress' --mode=block /home/foo/downloads/dnld.pl This works fine when I run from a user foo's shell. $ /home/foo/downloads/dnld.sh & $ systemctl --dry-run suspend Operation inhibited by "Downloader" (PID 27441 "systemd-inhibit", user foo), reason is "Important download in progress". But now I call same script via dnld.service file. $ cat /etc/systemd/system/dnld.service [Unit] Description=Download files After=network.target [Service] User=foo Type=simple WorkingDirectory=/home/foo/downloads ExecStart=/home/foo/downloads/dnld.sh When I start the service it gives "Failed to inhibit: Access denied" error. # systemctl start dnld.service # journalctl -u dnld.service Nov 26 13:33:30 foo systemd[1]: Started Download files. Nov 26 13:33:30 foo dnld.sh[27745]: Failed to inhibit: Access denied Nov 26 13:33:30 foo systemd[1]: dnld.service: Main process exited, code=exited, status=1/FAILURE Nov 26 13:33:30 foo systemd[1]: dnld.service: Failed with result 'exit-code'. If I change code to not call systemd-inhibit: $ cat /home/foo/downloads/dnld.sh #!/bin/bash /home/foo/downloads/dnld.pl Then service file runs fine. # systemctl start dnld.service; sleep 30 # journalctl -u dnld.service Nov 26 13:50:17 foo systemd[1]: Started Download files. Nov 26 13:50:37 foo systemd[1]: dnld.service: Succeeded. So how do I allow systemd-inhibit call when a script is called via systemd instead of directly? Is this systemd bug or am I missing something in dnld.service file? Amish ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-inhibit fails when run from a service file
Hello, I have a small perl program which downloads something. While downloading it inhibits (blocks) shutdown, reboot etc. The program runs as user "foo". Roughly the code is something like this: $ cat /home/foo/downloads/dnld.sh #!/bin/bash /usr/bin/systemd-inhibit --what=shutdown:sleep:idle:handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch --who=Downloader '--why=Important download in progress' --mode=block /home/foo/downloads/dnld.pl This works fine when I run from a user foo's shell. $ /home/foo/downloads/dnld.sh & $ systemctl --dry-run suspend Operation inhibited by "Downloader" (PID 27441 "systemd-inhibit", user foo), reason is "Important download in progress". But now I call same script via dnld.service file. $ cat /etc/systemd/system/dnld.service [Unit] Description=Download files After=network.target [Service] User=foo Type=simple WorkingDirectory=/home/foo/downloads ExecStart=/home/foo/downloads/dnld.sh When I start the service it gives "Failed to inhibit: Access denied" error. # systemctl start dnld.service # journalctl -u dnld.service Nov 26 13:33:30 foo systemd[1]: Started Download files. Nov 26 13:33:30 foo dnld.sh[27745]: Failed to inhibit: Access denied Nov 26 13:33:30 foo systemd[1]: dnld.service: Main process exited, code=exited, status=1/FAILURE Nov 26 13:33:30 foo systemd[1]: dnld.service: Failed with result 'exit-code'. If I change code to not call systemd-inhibit: $ cat /home/foo/downloads/dnld.sh #!/bin/bash /home/foo/downloads/dnld.pl Then service file runs fine. # systemctl start dnld.service; sleep 30 # journalctl -u dnld.service Nov 26 13:50:17 foo systemd[1]: Started Download files. Nov 26 13:50:37 foo systemd[1]: dnld.service: Succeeded. So how do I allow systemd-inhibit call when a script is called via systemd instead of directly? Is this systemd bug or am I missing something in dnld.service file? Amish. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-inhibit fails when run from a service file
On 13/01/20 3:03 pm, Lennart Poettering wrote: On Di, 26.11.19 13:55, Amish (anon.am...@gmail.com) wrote: If I change code to not call systemd-inhibit: $ cat /home/foo/downloads/dnld.sh #!/bin/bash /home/foo/downloads/dnld.pl Then service file runs fine. # systemctl start dnld.service; sleep 30 # journalctl -u dnld.service Nov 26 13:50:17 foo systemd[1]: Started Download files. Nov 26 13:50:37 foo systemd[1]: dnld.service: Succeeded. So how do I allow systemd-inhibit call when a script is called via systemd instead of directly? Is this systemd bug or am I missing something in dnld.service file? You need to allow this in PolicyKit. if you request an inhibitor from a login shell you get policykit privs because of the default policy. If you do this from a non-logged in user you won't, and need to adjust the policy. Lennart I tried changing some PolicyKit settings but I was not successful. However, I would admit that I did not understand the settings much either. But how about having this as a feature for systemd.service. Something like: [Service] Inhibit=shutdown,sleep,idle,... InhibitMode=block|delay ExecStart=... So before running any command, systemd will inhibit accordingly. (can be useful even when run with User=foo set) Any critical service which does not expect shutdown, reboot etc. can use this feature to block / delay the same while it is running. I can file RFE if you want. Thanks and regards, Amish. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd vulnerability detection
On 29/04/20 1:00 am, Lennart Poettering wrote: Please see: https://systemd.io/SECURITY/ ... Lennart On a side note, phrasing on the site needs to be changed. It almost makes you click "public" link instead of "non-public" e-mail link. It should be something like this: If you discover a security vulnerability, we’d appreciate a non-public disclosure. To reach systemd developers in a non-public way, report the issue to the systemd-secur...@redhat.com mailing list. The disclosure will be coordinated with distributions. Please do not use issue tracker and systemd-devel mailing list, as they are fully public. (There should be no hyperlink to issue tracker or systemd-devel mailing list to discourage accidental clicking) Amish ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Can service of timers.target having After=multi-user.target create a loop?
On 13/07/20 2:07 am, Uoti Urpala wrote: On Sun, 2020-07-12 at 17:13 +0300, Andrei Borzenkov wrote: 12.07.2020 16:21, Amish пишет: I have a timer file like this: [Unit] Description=Foo After=multi-user.target [Timer] OnCalendar=*:0/5 Persistent=false [Install] WantedBy=timers.target Because AFAIK timers.target runs before multi-user.target. But here something inside timers.target waits for multi-user.target. So how does systemd resolve this loop? There is no loop. There is no transitive dependency between timer unit and service unit. Timer unit gets started early and enqueues start job for service unit; this start job waits for multi-user.target according to After dependency. Mulitple invocation of timer will try enqueue start job again which will simply be merged with existing pending request. But shouldn't the After line be in the .service file, not the timer, in this case? The timer should be ready early if it's activated by timers.target, the service should wait before running. I have put it in .timer file and works as expected. Jul 13 10:38:27 server1 systemd[1]: Reached target Multi-User System. Jul 13 10:38:27 server1 systemd[1]: Started Foo. (the timer activated) Jul 13 10:38:27 server1 systemd[1]: Reached target Timers. ... Jul 13 10:40:01 server1 systemd[1]: Starting Foo... (the service that runs at */5) Jul 13 10:40:01 server1 systemd[1]: foo.service: Succeeded. Jul 13 10:40:01 server1 systemd[1]: Finished Foo. Regards Amish ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Can service of timers.target having After=multi-user.target create a loop?
Hello, This is a question out of curiosity and not currently any problem. I have a timer file like this: [Unit] Description=Foo After=multi-user.target [Timer] OnCalendar=*:0/5 Persistent=false [Install] WantedBy=timers.target And corresponding service file like this: [Unit] Description=Foo [Service] Type=oneshot ExecStart=-/usr/bin/checkservices /usr/bin/checkservices checks if some important services are running and sends alert if not. Above timer is supposed to run every five minutes. But not while system is still booting. If I do not put After=multi-user.target then timer gets triggered even before those services have begun (while booting) and sends false alarm. With above settings, I do not face that issue. But just out of curiosity I am eager to know if this or something similar can cause loop and hang system forever from booting? Because AFAIK timers.target runs before multi-user.target. But here something inside timers.target waits for multi-user.target. So how does systemd resolve this loop? Thanks in advance Amish ___ 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)
On 11/03/21 7:39 pm, Alvin Šipraga wrote: 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 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= ... Kind regards, Alvin So today, I upgraded to systemd 248 and this new feature (ActivationPolicy=) works just as I wanted. Now I can trigger wireguard connection on demand instead of running it 24x7. Thank you and regards, Amish. ___ 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)
On 11/03/21 7:39 pm, Alvin Šipraga wrote: 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? 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= Thank you. I think this feature does not exist yet on current stable release. (I use Arch Linux systemd version 247.3) So as of now I can not try that setting. But just seeking a clarification about it. I think this feature will still bring up the interface wg0 via wg0.netdev file. But it will not assign IP address till it is activated manually. So VPN connection will still occur behind the scenes just that IP address and routes will not be setup. What I want is that it should not initiate VPN connection itself. i.e.: ActivationPolicy=manual for netdev file and not network file. But let me wait till the feature lands in Arch Linux and then I will test it. 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. Yes thats what I have done, but I would still prefer a way to activate it on demand. Thanks, Amish ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Activate netdev only on demand (e.g. for wireguard connection)
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. Any tips or tricks? I know I can use wg-quick@.service but I prefer to use systemd-networkd instead. Currently what I do is rename .netdev to .notdev. So it does not start automatically. And then when I want it up. I rename it to .netdev and do: #networkctl reload. But thats an inefficient workaround. I would like a solution where I can bring it up or down on demand with single command: #networkctl up wg0 #networkctl down wg0 Thank you Amish. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Antw: [EXT] Upgraded multiple systems to systemd 249.3 and all had eth1 not started / configured
On 16/08/21 7:46 pm, Michael Biebl wrote:
How exactly do you rename your interfaces? Do you use a udev rule? Can
you post those scripts/rules?
I had already posted this in PS of my first email. It is two step process.
Here it is again:
Little about tmpeth* naming.
Some old scripts that we have expect interface names starting with eth.
But those names are not predictable.
So to get predictable names starting with eth*, first I temporarily
rename all interface with tmpeth*. This is done via udev rules.
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:XX",
NAME="tmpeth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:YY",
NAME="tmpeth1"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:ZZ",
NAME="tmpeth2"
Then I have a small service (script) which runs before
network-pre.target to convert these names back to eth*
#search for network interface with name starting from "tmpeth" and
rename them to "eth"
/usr/bin/find /sys/class/net -maxdepth 1 -name "tmpeth[0-9]" -type l
-printf "%f\n" | while read tmpiface; do /usr/bin/ip link set dev
"$tmpiface" name "$(echo $tmpiface | sed s/tmpeth/eth/)"; done
This ensures that I have predictable names starting with eth*. And it is
working fine from 2-3 years. Even with current issue, name assignment is
working fine.
Amish.
Re: [systemd-devel] Upgraded multiple systems to systemd 249.3 and all had eth1 not started / configured
orkd which is
causing the issue.
Thank you and regards,
Amish
On 17/08/21 3:18 pm, Colin Guthrie wrote:
Hiya,
As has been said, this is racy. "Sufficiently early" is just a hope,
rather than a guarantee. Perhaps something in the kernel made things
more or less efficient (try booting with the old kernel to see if it
helps, but as this is a race, it may only work some of the time.). Or
perhaps some unit ordering changed so make this better? Perhaps udev
settle units have now been dropped and thus the boot is faster and
things happen in a more hotplug oriented way? Lot's of possibilities
for why this no longer works (and even before it definitely wasn't a
guaranteed or recommended approach).
As has been said, you're best to pick a different "namespace" lan0
wan0 wan1 etc. if you can but if you can't change this due to some
legacy scripts, at least pick sufficiently high ethN numbers to stay
out of the way of the kernel, e.g. if you have three eth cards, then
pick your names starting from e.g. 5: eth5, eth6, eth7 and thus you
can avoid this dance with temporary names (although I'd still
recommend using different names altogether if you can).
Hope that helps.
Col
Amish wrote on 16/08/2021 13:38:
On 16/08/21 5:39 pm, Lennart Poettering wrote:
On Mo, 16.08.21 17:31, Amish (anon.am...@gmail.com) wrote:
On 16/08/21 5:25 pm, Lennart Poettering wrote:
On Mo, 16.08.21 16:09, Amish (anon.am...@gmail.com) wrote:
Some old scripts that we have expect interface names starting
with eth. But
those names are not predictable.
So to get predictable names starting with eth*, first I
temporarily rename
all interface with tmpeth*. This is done via udev rules.
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:XX",
NAME="tmpeth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:YY",
NAME="tmpeth1"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:ZZ",
NAME="tmpeth2"
Then I have a small service (script) which runs before
network-pre.target to
convert these names back to eth*
#search for network interface with name starting from "tmpeth"
and rename
them to "eth"
/usr/bin/find /sys/class/net -maxdepth 1 -name "tmpeth[0-9]"
-type l -printf
"%f\n" | while read tmpiface; do /usr/bin/ip link set dev
"$tmpiface" name
"$(echo $tmpiface | sed s/tmpeth/eth/)"; done
This ensures that I have predictable names starting with eth*.
And it is
working fine from 2-3 years. Even with current issue, name
assignment is
working fine.
This cannot work and is necesarily race. Stay out of the ethXYZ
namespace, that's the kernel's namespace. Pick any other names,
i.e. "foobar0", "foobar1", but otherwise you just have a racy racy
mess, because the kernel might take the name whenever it pleases.
No I dont think this is race. Because my script runs after Udev has
finished
assigning the interfaces names.
device probing can take any time it wants. there isn't a point in time
where everything is probed.
These are internal PCI LAN cards. I believe these gets probed (and
named) sufficiently early.
And then we can expect names assigned by Udev to remain same.
And I can see in the logs that names are not changed after my script
runs.
Also this has been working successfully for me from 2 or more years.
But after today's update, something is breaking all the systems.
Additionally just now on other system I see eth2 (instead of eth1)
being renamed to eth0.
I just want to know what changed and where? (Kernel or Systemd?).
*Also another point is, I have set ConfigureWithoutCarrier=yes in
network files and all are static IPs, so systemd-networkd should have
configured the devices even if links are not up. But its not doing
that anymore either after today's update.*
Regards
Amish.
Lennart
--
Lennart Poettering, Berlin
Re: [systemd-devel] Upgraded multiple systems to systemd 249.3 and all had eth1 not started / configured
Hello Further to my previous email: I see that there is already an *extremely similar issue* reported on July 12, 2021 and it has been fixed. https://github.com/systemd/systemd/issues/20203 But I do not know if this fix exists in systemd v249.3 (Arch Linux) If it exists that means that fix is breaking my system. And if it does not exist that means, I can expect it to fix my issue. Regards, Amish. On 18/08/21 11:42 am, Amish wrote: Hello, Thank you for your reply. I can understand that there can be race. *But when I check logs, there is no race happening*. *Let us see and analyze the logs.* Stage 1: System boots, and kernel assigns eth0, eth1 and eth2 as interface names. Aug 18 09:17:13 kk kernel: e1000e :00:1f.6 eth0: (PCI Express:2.5GT/s:Width x1) e0:d5:5e:8d:7f:2f Aug 18 09:17:13 kk kernel: e1000e :00:1f.6 eth0: Intel(R) PRO/1000 Network Connection Aug 18 09:17:13 kk kernel: e1000e :00:1f.6 eth0: MAC: 13, PHY: 12, PBA No: FF-0FF Aug 18 09:17:13 kk kernel: 8139too :04:00.0 eth1: RealTek RTL8139 at 0x0e8fc9bb, 00:e0:4d:05:ee:a2, IRQ 19 Aug 18 09:17:13 kk kernel: r8169 :02:00.0 eth2: RTL8168e/8111e, 50:3e:aa:05:2b:ca, XID 2c2, IRQ 129 Aug 18 09:17:13 kk kernel: r8169 :02:00.0 eth2: jumbo features [frames: 9194 bytes, tx checksumming: ko] Stage 2: Now udev rules are triggered and the interfaces are renamed to tmpeth0, tmpeth2 and tmpeth1. Aug 18 09:17:13 kk kernel: 8139too :04:00.0 tmpeth2: renamed from eth1 Aug 18 09:17:13 kk kernel: e1000e :00:1f.6 tmpeth0: renamed from eth0 Aug 18 09:17:13 kk kernel: r8169 :02:00.0 tmpeth1: renamed from eth2 Stage 3: Now my script is called and it renames interfaces to eth0, eth2 and eth1. Aug 18 09:17:13 kk kernel: e1000e :00:1f.6 eth0: renamed from tmpeth0 Aug 18 09:17:14 kk kernel: r8169 :02:00.0 eth1: renamed from tmpeth1 Aug 18 09:17:14 kk kernel: 8139too :04:00.0 eth2: renamed from tmpeth2 Effectively original interface eth1 and eth2 are swapped. While eth0 remains eth0. All these happened before systemd-networkd started and interface renaming was over by 9:17:14. Stage 4: Now systemd-networkd starts, 2 seconds after all interface have been assigned their final names. Aug 18 09:17:16 kk systemd[1]: Starting Network Configuration... Aug 18 09:17:17 kk systemd-networkd[426]: lo: Link UP Aug 18 09:17:17 kk systemd-networkd[426]: lo: Gained carrier Aug 18 09:17:17 kk systemd-networkd[426]: Enumeration completed Aug 18 09:17:17 kk systemd[1]: Started Network Configuration. Aug 18 09:17:17 kk systemd-networkd[426]: eth2: Interface name change detected, renamed to eth1. Aug 18 09:17:17 kk systemd-networkd[426]: Could not process link message: File exists Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Failed Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Interface name change detected, renamed to eth2. Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Interface name change detected, renamed to tmpeth2. Aug 18 09:17:17 kk systemd-networkd[426]: eth0: Interface name change detected, renamed to tmpeth0. Aug 18 09:17:17 kk systemd-networkd[426]: eth2: Interface name change detected, renamed to tmpeth1. Aug 18 09:17:17 kk systemd-networkd[426]: tmpeth0: Interface name change detected, renamed to eth0. Aug 18 09:17:17 kk systemd-networkd[426]: tmpeth1: Interface name change detected, renamed to eth1. Aug 18 09:17:17 kk systemd-networkd[426]: tmpeth2: Interface name change detected, renamed to eth2. Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Link UP Aug 18 09:17:17 kk systemd-networkd[426]: eth0: Link UP Aug 18 09:17:20 kk systemd-networkd[426]: eth0: Gained carrier This is when eth0 and eth1 interfaces are up and configured by systemd-networkd but eth2 is down and not configured. *None of the .network configuration files match by interface names. They all match just by MAC address. *# sample .network file. [Match] MACAddress=e0:d5:5e:8d:7f:2f Type=ether [Network] IgnoreCarrierLoss=yes LinkLocalAddressing=no IPv6AcceptRA=no ConfigureWithoutCarrier=true Address=192.168.25.2/24 * * Above error message "eth1: failed", was not showing earlier version of systemd. So recent version of systemd-networkd is doing something different and this is where something is going wrong. Stage 5: (my workaround for this issue) I wrote a new service file which restarts systemd-networkd after waiting for 10 seconds. Aug 18 09:17:27 kk systemd[1]: Stopping Network Configuration... Aug 18 09:17:27 kk systemd[1]: systemd-networkd.service: Deactivated successfully. Aug 18 09:17:27 kk systemd[1]: Stopped Network Configuration. Aug 18 09:17:27 kk systemd[1]: Starting Network Configuration... Aug 18 09:17:27 kk systemd-networkd[579]: eth1: Link UP Aug 18 09:17:27 kk systemd-networkd[579]: eth0: Link UP Aug 18 09:17:27 kk systemd-networkd[579]: eth0: Gained carrier Aug 18 09:17:27 kk systemd-networkd[579]: lo: Link UP Aug 18 09:17:27 kk systemd-networkd[579]:
Re: [systemd-devel] Upgraded multiple systems to systemd 249.3 and all had eth1 not started / configured
On 18/08/21 12:24 pm, Amish wrote: Hello Further to my previous email: I see that there is already an *extremely similar issue* reported on July 12, 2021 and it has been fixed. https://github.com/systemd/systemd/issues/20203 But I do not know if this fix exists in systemd v249.3 (Arch Linux) If it exists that means that fix is breaking my system. And if it does not exist that means, I can expect it to fix my issue. systemd v249.4 seems to have fixed the issue. (Arch Linux) Regards Amish Regards, Amish. On 18/08/21 11:42 am, Amish wrote: Hello, Thank you for your reply. I can understand that there can be race. *But when I check logs, there is no race happening*. *Let us see and analyze the logs.* Stage 1: System boots, and kernel assigns eth0, eth1 and eth2 as interface names. Aug 18 09:17:13 kk kernel: e1000e :00:1f.6 eth0: (PCI Express:2.5GT/s:Width x1) e0:d5:5e:8d:7f:2f Aug 18 09:17:13 kk kernel: e1000e :00:1f.6 eth0: Intel(R) PRO/1000 Network Connection Aug 18 09:17:13 kk kernel: e1000e :00:1f.6 eth0: MAC: 13, PHY: 12, PBA No: FF-0FF Aug 18 09:17:13 kk kernel: 8139too :04:00.0 eth1: RealTek RTL8139 at 0x0e8fc9bb, 00:e0:4d:05:ee:a2, IRQ 19 Aug 18 09:17:13 kk kernel: r8169 :02:00.0 eth2: RTL8168e/8111e, 50:3e:aa:05:2b:ca, XID 2c2, IRQ 129 Aug 18 09:17:13 kk kernel: r8169 :02:00.0 eth2: jumbo features [frames: 9194 bytes, tx checksumming: ko] Stage 2: Now udev rules are triggered and the interfaces are renamed to tmpeth0, tmpeth2 and tmpeth1. Aug 18 09:17:13 kk kernel: 8139too :04:00.0 tmpeth2: renamed from eth1 Aug 18 09:17:13 kk kernel: e1000e :00:1f.6 tmpeth0: renamed from eth0 Aug 18 09:17:13 kk kernel: r8169 :02:00.0 tmpeth1: renamed from eth2 Stage 3: Now my script is called and it renames interfaces to eth0, eth2 and eth1. Aug 18 09:17:13 kk kernel: e1000e :00:1f.6 eth0: renamed from tmpeth0 Aug 18 09:17:14 kk kernel: r8169 :02:00.0 eth1: renamed from tmpeth1 Aug 18 09:17:14 kk kernel: 8139too :04:00.0 eth2: renamed from tmpeth2 Effectively original interface eth1 and eth2 are swapped. While eth0 remains eth0. All these happened before systemd-networkd started and interface renaming was over by 9:17:14. Stage 4: Now systemd-networkd starts, 2 seconds after all interface have been assigned their final names. Aug 18 09:17:16 kk systemd[1]: Starting Network Configuration... Aug 18 09:17:17 kk systemd-networkd[426]: lo: Link UP Aug 18 09:17:17 kk systemd-networkd[426]: lo: Gained carrier Aug 18 09:17:17 kk systemd-networkd[426]: Enumeration completed Aug 18 09:17:17 kk systemd[1]: Started Network Configuration. Aug 18 09:17:17 kk systemd-networkd[426]: eth2: Interface name change detected, renamed to eth1. Aug 18 09:17:17 kk systemd-networkd[426]: Could not process link message: File exists Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Failed Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Interface name change detected, renamed to eth2. Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Interface name change detected, renamed to tmpeth2. Aug 18 09:17:17 kk systemd-networkd[426]: eth0: Interface name change detected, renamed to tmpeth0. Aug 18 09:17:17 kk systemd-networkd[426]: eth2: Interface name change detected, renamed to tmpeth1. Aug 18 09:17:17 kk systemd-networkd[426]: tmpeth0: Interface name change detected, renamed to eth0. Aug 18 09:17:17 kk systemd-networkd[426]: tmpeth1: Interface name change detected, renamed to eth1. Aug 18 09:17:17 kk systemd-networkd[426]: tmpeth2: Interface name change detected, renamed to eth2. Aug 18 09:17:17 kk systemd-networkd[426]: eth1: Link UP Aug 18 09:17:17 kk systemd-networkd[426]: eth0: Link UP Aug 18 09:17:20 kk systemd-networkd[426]: eth0: Gained carrier This is when eth0 and eth1 interfaces are up and configured by systemd-networkd but eth2 is down and not configured. *None of the .network configuration files match by interface names. They all match just by MAC address. *# sample .network file. [Match] MACAddress=e0:d5:5e:8d:7f:2f Type=ether [Network] IgnoreCarrierLoss=yes LinkLocalAddressing=no IPv6AcceptRA=no ConfigureWithoutCarrier=true Address=192.168.25.2/24 * * Above error message "eth1: failed", was not showing earlier version of systemd. So recent version of systemd-networkd is doing something different and this is where something is going wrong. Stage 5: (my workaround for this issue) I wrote a new service file which restarts systemd-networkd after waiting for 10 seconds. Aug 18 09:17:27 kk systemd[1]: Stopping Network Configuration... Aug 18 09:17:27 kk systemd[1]: systemd-networkd.service: Deactivated successfully. Aug 18 09:17:27 kk systemd[1]: Stopped Network Configuration. Aug 18 09:17:27 kk systemd[1]: Starting Network Configuration... Aug 18 09:17:27 kk systemd-networkd[579]: eth1: Link UP Aug 18 09:17:27 kk systemd-networkd[579]: eth0: Link UP Aug 18 09:17:27 kk systemd-networkd[
Re: [systemd-devel] Antw: [EXT] Upgraded multiple systems to systemd 249.3 and all had eth1 not started / configured
On 16/08/21 5:09 pm, Ulrich Windl wrote: Hi! Actually I wonder (even before the upgrade) what that nonsense is about: eth1: Interface name change detected, eth1 has been renamed to eth0. No. If you see two journal logs that I posted. This message was not coming before upgrade. Issue seems to be related to this message. Regards, Amish. Amish schrieb am 16.08.2021 um 12:39 in Nachricht <83597df0-fef1-049e-3707-2aa2a3819...@gmail.com>: Hello everyone, So I have around seven Arch Linux based systems. All systems have 2 or 3 network cards. eth0 is LAN side (192.168.x.x/24 range). eth1 and eth2 has WAN (public internet) connectivity. Today I upgraded all systems to systemd 249.3 and Linux kernel 5.13.10.arch1-1. Everything worked fine before upgrading. And to my horror I started getting complaints from all sites that internet is not working. *Then I realized that all machines have interface eth1 down.* Here is the journal log showing error after upgrading (journalctl -b 0 -u systemd-networkd) Aug 16 09:30:18 kk systemd[1]: Starting Network Configuration... Aug 16 09:30:18 kk systemd-networkd[429]: lo: Link UP Aug 16 09:30:18 kk systemd-networkd[429]: lo: Gained carrier Aug 16 09:30:18 kk systemd-networkd[429]: Enumeration completed Aug 16 09:30:18 kk systemd[1]: Started Network Configuration. *Aug 16 09:30:18 kk systemd-networkd[429]: eth1: Interface name change detected, renamed to eth0.** **Aug 16 09:30:18 kk systemd-networkd[429]: Could not process link message: File exists** **Aug 16 09:30:18 kk systemd-networkd[429]: eth0: Failed** *Aug 16 09:30:18 kk systemd-networkd[429]: eth2: Interface name change detected, renamed to eth1. Aug 16 09:30:18 kk systemd-networkd[429]: eth0: Interface name change detected, renamed to tmpeth1. Aug 16 09:30:18 kk systemd-networkd[429]: eth1: Interface name change detected, renamed to tmpeth2. Aug 16 09:30:18 kk systemd-networkd[429]: eth0: Interface name change detected, renamed to tmpeth0. Aug 16 09:30:18 kk systemd-networkd[429]: tmpeth0: Interface name change detected, renamed to eth0. Aug 16 09:30:18 kk systemd-networkd[429]: tmpeth1: Interface name change detected, renamed to eth1. Aug 16 09:30:18 kk systemd-networkd[429]: tmpeth2: Interface name change detected, renamed to eth2. Aug 16 09:30:19 kk systemd-networkd[429]: eth0: Link UP Aug 16 09:30:19 kk systemd-networkd[429]: eth2: Link UP Aug 16 09:30:19 kk systemd-networkd[429]: eth2: Gained carrier Aug 16 09:30:22 kk systemd-networkd[429]: eth0: Gained carrier Explanation about tmpeth* naming is below but that is probably not related to this issue. So can be ignored. Notice how there is an error about renaming eth1 to eth0. I dont know what is doing this renaming of eth1 to eth0. This renaming didn't happen before upgrade. (see journal log below) And also notice that there is no line stating eth1: Link UP. *Here is the journal log when systems worked perfectly.** * Aug 13 09:17:20 kk systemd[1]: Starting Network Service... Aug 13 09:17:21 kk systemd-networkd[421]: Enumeration completed Aug 13 09:17:21 kk systemd[1]: Started Network Service. Aug 13 09:17:21 kk systemd-networkd[421]: eth0: Interface name change detected, eth0 has been renamed to tmpeth0. Aug 13 09:17:21 kk systemd-networkd[421]: eth2: Interface name change detected, eth2 has been renamed to eth0. Aug 13 09:17:21 kk systemd-networkd[421]: eth0: Interface name change detected, eth0 has been renamed to tmpeth2. Aug 13 09:17:21 kk systemd-networkd[421]: eth1: Interface name change detected, eth1 has been renamed to eth0. Aug 13 09:17:21 kk systemd-networkd[421]: eth0: Interface name change detected, eth0 has been renamed to tmpeth1. Aug 13 09:17:21 kk systemd-networkd[421]: tmpeth1: Interface name change detected, tmpeth1 has been renamed to eth1. Aug 13 09:17:21 kk systemd-networkd[421]: tmpeth2: Interface name change detected, tmpeth2 has been renamed to eth2. Aug 13 09:17:21 kk systemd-networkd[421]: tmpeth0: Interface name change detected, tmpeth0 has been renamed to eth0. Aug 13 09:17:21 kk systemd-networkd[421]: eth1: Link UP Aug 13 09:17:21 kk systemd-networkd[421]: eth2: Link UP Aug 13 09:17:21 kk systemd-networkd[421]: eth2: Gained carrier Aug 13 09:17:21 kk systemd-networkd[421]: eth0: Link UP Aug 13 09:17:26 kk systemd-networkd[421]: eth0: Gained carrier Notice how there was no attempt to rename eth1 to eth0 at the beginning (i.e. when everything worked fine) And notice how all interfaces showed Link UP. So something changed either in systemd or in Linux kernel. Any idea what is wrong where? And which process is trying to rename eth1 to eth0 at system startup? All systems are production systems and after today's long downtime, I can not downgrade any system to check what is wrong as management would be on fire if there is another downtime. Thank you in advance, Amish PS: Little about tmpeth* naming. Some old scripts that we have expect interface names starting with eth. But those
Re: [systemd-devel] Upgraded multiple systems to systemd 249.3 and all had eth1 not started / configured
On 16/08/21 5:39 pm, Lennart Poettering wrote:
On Mo, 16.08.21 17:31, Amish (anon.am...@gmail.com) wrote:
On 16/08/21 5:25 pm, Lennart Poettering wrote:
On Mo, 16.08.21 16:09, Amish (anon.am...@gmail.com) wrote:
Some old scripts that we have expect interface names starting with eth. But
those names are not predictable.
So to get predictable names starting with eth*, first I temporarily rename
all interface with tmpeth*. This is done via udev rules.
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:XX",
NAME="tmpeth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:YY",
NAME="tmpeth1"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:ZZ",
NAME="tmpeth2"
Then I have a small service (script) which runs before network-pre.target to
convert these names back to eth*
#search for network interface with name starting from "tmpeth" and rename
them to "eth"
/usr/bin/find /sys/class/net -maxdepth 1 -name "tmpeth[0-9]" -type l -printf
"%f\n" | while read tmpiface; do /usr/bin/ip link set dev "$tmpiface" name
"$(echo $tmpiface | sed s/tmpeth/eth/)"; done
This ensures that I have predictable names starting with eth*. And it is
working fine from 2-3 years. Even with current issue, name assignment is
working fine.
This cannot work and is necesarily race. Stay out of the ethXYZ
namespace, that's the kernel's namespace. Pick any other names,
i.e. "foobar0", "foobar1", but otherwise you just have a racy racy
mess, because the kernel might take the name whenever it pleases.
No I dont think this is race. Because my script runs after Udev has finished
assigning the interfaces names.
device probing can take any time it wants. there isn't a point in time
where everything is probed.
These are internal PCI LAN cards. I believe these gets probed (and
named) sufficiently early.
And then we can expect names assigned by Udev to remain same.
And I can see in the logs that names are not changed after my script runs.
Also this has been working successfully for me from 2 or more years.
But after today's update, something is breaking all the systems.
Additionally just now on other system I see eth2 (instead of eth1) being
renamed to eth0.
I just want to know what changed and where? (Kernel or Systemd?).
*Also another point is, I have set ConfigureWithoutCarrier=yes in
network files and all are static IPs, so systemd-networkd should have
configured the devices even if links are not up. But its not doing that
anymore either after today's update.*
Regards
Amish.
Lennart
--
Lennart Poettering, Berlin
Re: [systemd-devel] Upgraded multiple systems to systemd 249.3 and all had eth1 not started / configured
On 16/08/21 5:25 pm, Lennart Poettering wrote:
On Mo, 16.08.21 16:09, Amish (anon.am...@gmail.com) wrote:
Some old scripts that we have expect interface names starting with eth. But
those names are not predictable.
So to get predictable names starting with eth*, first I temporarily rename
all interface with tmpeth*. This is done via udev rules.
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:XX",
NAME="tmpeth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:YY",
NAME="tmpeth1"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:ZZ",
NAME="tmpeth2"
Then I have a small service (script) which runs before network-pre.target to
convert these names back to eth*
#search for network interface with name starting from "tmpeth" and rename
them to "eth"
/usr/bin/find /sys/class/net -maxdepth 1 -name "tmpeth[0-9]" -type l -printf
"%f\n" | while read tmpiface; do /usr/bin/ip link set dev "$tmpiface" name
"$(echo $tmpiface | sed s/tmpeth/eth/)"; done
This ensures that I have predictable names starting with eth*. And it is
working fine from 2-3 years. Even with current issue, name assignment is
working fine.
This cannot work and is necesarily race. Stay out of the ethXYZ
namespace, that's the kernel's namespace. Pick any other names,
i.e. "foobar0", "foobar1", but otherwise you just have a racy racy
mess, because the kernel might take the name whenever it pleases.
No I dont think this is race. Because my script runs after Udev has
finished assigning the interfaces names.
Otherwise if kernel changes name again (back to eth*) after udev has
finished renaming the device then persistent naming will never work.
Regards,
Amish.
[systemd-devel] Upgraded multiple systems to systemd 249.3 and all had eth1 not started / configured
Hello everyone,
So I have around seven Arch Linux based systems.
All systems have 2 or 3 network cards.
eth0 is LAN side (192.168.x.x/24 range). eth1 and eth2 has WAN (public
internet) connectivity.
Today I upgraded all systems to systemd 249.3 and Linux kernel
5.13.10.arch1-1.
Everything worked fine before upgrading. And to my horror I started
getting complaints from all sites that internet is not working.
*Then I realized that all machines have interface eth1 down.*
Here is the journal log showing error after upgrading (journalctl -b 0
-u systemd-networkd)
Aug 16 09:30:18 kk systemd[1]: Starting Network Configuration...
Aug 16 09:30:18 kk systemd-networkd[429]: lo: Link UP
Aug 16 09:30:18 kk systemd-networkd[429]: lo: Gained carrier
Aug 16 09:30:18 kk systemd-networkd[429]: Enumeration completed
Aug 16 09:30:18 kk systemd[1]: Started Network Configuration.
*Aug 16 09:30:18 kk systemd-networkd[429]: eth1: Interface name change
detected, renamed to eth0.**
**Aug 16 09:30:18 kk systemd-networkd[429]: Could not process link
message: File exists**
**Aug 16 09:30:18 kk systemd-networkd[429]: eth0: Failed**
*Aug 16 09:30:18 kk systemd-networkd[429]: eth2: Interface name change
detected, renamed to eth1.
Aug 16 09:30:18 kk systemd-networkd[429]: eth0: Interface name change
detected, renamed to tmpeth1.
Aug 16 09:30:18 kk systemd-networkd[429]: eth1: Interface name change
detected, renamed to tmpeth2.
Aug 16 09:30:18 kk systemd-networkd[429]: eth0: Interface name change
detected, renamed to tmpeth0.
Aug 16 09:30:18 kk systemd-networkd[429]: tmpeth0: Interface name change
detected, renamed to eth0.
Aug 16 09:30:18 kk systemd-networkd[429]: tmpeth1: Interface name change
detected, renamed to eth1.
Aug 16 09:30:18 kk systemd-networkd[429]: tmpeth2: Interface name change
detected, renamed to eth2.
Aug 16 09:30:19 kk systemd-networkd[429]: eth0: Link UP
Aug 16 09:30:19 kk systemd-networkd[429]: eth2: Link UP
Aug 16 09:30:19 kk systemd-networkd[429]: eth2: Gained carrier
Aug 16 09:30:22 kk systemd-networkd[429]: eth0: Gained carrier
Explanation about tmpeth* naming is below but that is probably not
related to this issue. So can be ignored.
Notice how there is an error about renaming eth1 to eth0. I dont know
what is doing this renaming of eth1 to eth0. This renaming didn't happen
before upgrade. (see journal log below)
And also notice that there is no line stating eth1: Link UP.
*Here is the journal log when systems worked perfectly.**
*
Aug 13 09:17:20 kk systemd[1]: Starting Network Service...
Aug 13 09:17:21 kk systemd-networkd[421]: Enumeration completed
Aug 13 09:17:21 kk systemd[1]: Started Network Service.
Aug 13 09:17:21 kk systemd-networkd[421]: eth0: Interface name change
detected, eth0 has been renamed to tmpeth0.
Aug 13 09:17:21 kk systemd-networkd[421]: eth2: Interface name change
detected, eth2 has been renamed to eth0.
Aug 13 09:17:21 kk systemd-networkd[421]: eth0: Interface name change
detected, eth0 has been renamed to tmpeth2.
Aug 13 09:17:21 kk systemd-networkd[421]: eth1: Interface name change
detected, eth1 has been renamed to eth0.
Aug 13 09:17:21 kk systemd-networkd[421]: eth0: Interface name change
detected, eth0 has been renamed to tmpeth1.
Aug 13 09:17:21 kk systemd-networkd[421]: tmpeth1: Interface name change
detected, tmpeth1 has been renamed to eth1.
Aug 13 09:17:21 kk systemd-networkd[421]: tmpeth2: Interface name change
detected, tmpeth2 has been renamed to eth2.
Aug 13 09:17:21 kk systemd-networkd[421]: tmpeth0: Interface name change
detected, tmpeth0 has been renamed to eth0.
Aug 13 09:17:21 kk systemd-networkd[421]: eth1: Link UP
Aug 13 09:17:21 kk systemd-networkd[421]: eth2: Link UP
Aug 13 09:17:21 kk systemd-networkd[421]: eth2: Gained carrier
Aug 13 09:17:21 kk systemd-networkd[421]: eth0: Link UP
Aug 13 09:17:26 kk systemd-networkd[421]: eth0: Gained carrier
Notice how there was no attempt to rename eth1 to eth0 at the beginning
(i.e. when everything worked fine)
And notice how all interfaces showed Link UP.
So something changed either in systemd or in Linux kernel.
Any idea what is wrong where? And which process is trying to rename eth1
to eth0 at system startup?
All systems are production systems and after today's long downtime, I
can not downgrade any system to check what is wrong as management would
be on fire if there is another downtime.
Thank you in advance,
Amish
PS:
Little about tmpeth* naming.
Some old scripts that we have expect interface names starting with eth.
But those names are not predictable.
So to get predictable names starting with eth*, first I temporarily
rename all interface with tmpeth*. This is done via udev rules.
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:XX",
NAME="tmpeth0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="XX:XX:XX:XX:XX:YY",
NAME="tmpeth1"
SUBSYSTEM=="n
[systemd-devel] systemd v250 ignoring service.d overrides - service.d directories can no longer be a symlink?
Hello
Something changed in systemd v250 with respect to service.d override
directories.
It seems that these directories can no longer be a symlink to a directory.
And this change broke many of my services because they use overrides and
overrides stopped applying completely.
Scenario:
--
I place all my override files in
/system.d/usr/lib/systemd/system/foo.service.d/{10-custom1.conf,20-custom2.conf,...}
This makes it easy for me to mange them in git as well as easy to manage
multiple overrides.
Then I create symlink /usr/lib/systemd/system/foo.service.d pointing to
/system.d/usr/lib/systemd/system/foo.service.d
This worked till systemd 249.
But it stopped working in systemd 250.
Systemd ignores the foo.service.d completely, if it is a symlink.
Is this a bug or a known change? (I could not locate mention of it in
NEWS file)
If a known change then is there any configuration which I can tweak to
allow foo.service.d as symlinks?
Otherwise I will have to replan whole structure and create symlinks for
each 10-custom1.conf, 20-custom2.conf, so on.
I use Arch Linux.
Regards,
Amish.
Re: [systemd-devel] systemd v250 ignoring service.d overrides - service.d directories can no longer be a symlink?
Just an update, this bug was reported on github (by someone else)
https://github.com/systemd/systemd/issues/21920
And related PR for the fix is at:
https://github.com/systemd/systemd/pull/21925
Amish
On 28/12/21 09:32, Amish wrote:
Hello
Something changed in systemd v250 with respect to service.d override
directories.
It seems that these directories can no longer be a symlink to a
directory.
And this change broke many of my services because they use overrides
and overrides stopped applying completely.
Scenario:
--
I place all my override files in
/system.d/usr/lib/systemd/system/foo.service.d/{10-custom1.conf,20-custom2.conf,...}
This makes it easy for me to mange them in git as well as easy to
manage multiple overrides.
Then I create symlink /usr/lib/systemd/system/foo.service.d pointing
to /system.d/usr/lib/systemd/system/foo.service.d
This worked till systemd 249.
But it stopped working in systemd 250.
Systemd ignores the foo.service.d completely, if it is a symlink.
Is this a bug or a known change? (I could not locate mention of it in
NEWS file)
If a known change then is there any configuration which I can tweak to
allow foo.service.d as symlinks?
Otherwise I will have to replan whole structure and create symlinks
for each 10-custom1.conf, 20-custom2.conf, so on.
I use Arch Linux.
Regards,
Amish.
