-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi list,

I got hit by this, too.

On Mon, 17 Aug 2020, Eli Schwartz via arch-general wrote:
On 8/17/20 5:25 PM, David C. Rankin wrote:


By "subservice" I think you mean ".include" stanzas?

Your analysis is correct, this got removed from systemd here:
https://github.com/systemd/systemd/commit/7ade8982ca1969e251a29589ae918c3b5c595afb

and systemd 246 is the first release with its removal.

However, netctl migrated over to *.d dropins here:
https://git.archlinux.org/netctl.git/commit/?id=04d39b2573bd34d4159837afdb4793a0990bd44a

So I think you should be fine if you've re-enabled the netctl profile
with 1.18 or higher (released on 2018-08-07). That's 2 years. Granted,
if it's been working for years, why would anyone care about manually
re-enabling their netctl profile... but...

There should also probably have been a warning logged in journalctl for
this, if your service was still using the old method.

That's true, however, when this warning first appeared, `netctl reenable my-profile` did not help - same was true several days later (probably also weeks/months). So I forgot about the warning (I'm not keen to put `for profile in $list; do netctl reenable $profile; done` into my common update routine for all my arch boxes).


netctl@rlf_network\x2dstatic.service.d/
└── profile.conf

However, there is no note or warning during update that any manual
intervention will be needed. That will leave anyone adminning a remote arch
install with netctl with a box that is unreachable and has no network.

Shouldn't there be a warning about this change generated on update? Arch is
always pretty good about warning when manual interaction is required -- and
this is a biggie.

I'm not sure it merits a news post for something that old which is only
now becoming fatal.

In my opinion, a news post would have been appropriate. But now it's "too late" (see below).


Hopefully anyone with remotely adminned boxes caught this while
monitoring journalctl logs.

Logs were unhelpful at that time, see above.


But, thanks for posting this to the list -- at the very least, people in
the same situation will be able to figure out what happened by reading
here. And hopefully they will see this *before* upgrading.

Additionally, people on the list might catch this issue in advance (if they don't update too often and have not yet been hit by this issue). This makes a news post obsolete, now, I believe.


Couldn't there also be a post install that does a reenable for each netctl
profile found in /etc/systemd/system as another option to avoid this SNAFU?
That might have been an interesting precautionary measure for netctl
1.18, at least for printing a message advising people to reenable the
service.

I'm not sure it makes sense to do that automatically, since disabling a
profile removes customizations and the netctl manpage explicitly warns
you to be careful about doing so.

I think, it's not arch's way to do such things. Arch rather says "your config is broken/old, run `xyz` to fix it" than simply running `xyz`.


--
Eli Schwartz
Bug Wrangler and Trusted User


regards,
Erich

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl87ZzQACgkQCu7JB1Xa
e1qq7w/+KHd/vyL9AloIgirCeEcYf/+JxcCOngmROoxbM/Gs3rtxynewpwqV6iCi
VJGIlrH5Xl2/NasKONRQuzNyGD0qqIMMRbAiNOZq3r37RAb8vmWmRxJmY5rkymO7
yoG4ox4HSgfeTyCvQhUnMZWE8Qm7INjcI/nHvs//wIwqB5ppeLkkFLHK9LCWBpaF
+dkKP5vrsvjrD9785RjjMg46iHDCJ3AEAPuZmWes7IgUR161MD7Ujf07YMDfit8u
1SrdtxsncPSR0OX/m4DKC31tBP5WjS4kGL61NjUfQm354YtkjhyULQ7ecobRNBqA
xQ4i6nLpbbZJSx38S0jfOgsAqKxM5HV6pFXRUR1GTT6a0MTxXG9bERmVm6oaFQeN
9cm3b4MbeBDVXp5x7MI2VGlG2mmNaIxZWpMKtUufQwBOxSkDSp5rifqy+NUgPhLX
H/WcdK8pCQfIVfiopENVA9aNrb25/ST79io0KfUNmON3HHEnCWaJGHmCFMB/yOe7
2frLccn6TP17KkSSL5cJev5tpB+epH9k3BUxln7BT9ZDGVNJwbhlksaKXWncj8Hg
OEvt6vqHCuswwvcrAvTJwDeCVtQRU4dt3cqSqCHuJjKzNg6egE1gU9KOxvFkZE0T
5dNq9DrcixQoXbG59DhNsOkM8b186HvvXOxTVBJvsFwS46Nnn4g=
=/I9c
-----END PGP SIGNATURE-----

Reply via email to