Hi, this would normally be just a linux distribution bug, and it is, but it looks like the systemd service files and targets all come from upstream. While testing the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1419280 in Ubuntu, I noticed that rpc.gssd was not being restarted in post (same thing happens in debian). It looks like the nfs-utils.service service was created for this task, but it has no [install] section, so it can't be enabled. Long story short, in ubuntu/debian it's only restarted in post if it was started before. I then checked Fedora 33, 34 and rawhide, and saw that there it's also not restarted, but with a tweak: the rpms try to restart nfs-client.target, which also doesn't seem to work on a running system, but maybe I did something wrong in enabling nfs there in the first place (maybe I forgot to enable one of the services?). In any case, I filed https://bugzilla.redhat.com/show_bug.cgi?id=1961322 for that with more details. In ubuntu I'll probably work around it by just calling "systemctl start nfs-utils.service" in post, before the restart routines kick in (still testing that for side effects), but since the service files come from upstream, and the intention seemed to be for this exact purpose (restart on pkg upgrade), I'm sending this email here looking for guidance on how it was intended for packagers to restart all the myriad of nfs v2/v3/v4 services on upgrade. Thanks!
