| 2021-05-12 20:15:35 |
Andreas Hasenack |
bug |
|
|
added bug |
| 2021-05-12 21:19:01 |
Andreas Hasenack |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988430 |
|
| 2021-05-12 21:19:01 |
Andreas Hasenack |
bug task added |
|
nfs-utils (Debian) |
|
| 2021-05-12 21:27:18 |
Pedro Principeza |
bug |
|
|
added subscriber Pedro Principeza |
| 2021-05-13 14:02:21 |
Bug Watch Updater |
nfs-utils (Debian): status |
Unknown |
New |
|
| 2021-05-13 17:53:02 |
Dan Streetman |
bug |
|
|
added subscriber Dan Streetman |
| 2021-05-25 19:13:14 |
Andreas Hasenack |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1961322 |
|
| 2021-05-25 19:13:14 |
Andreas Hasenack |
bug task added |
|
nfs-utils (Fedora) |
|
| 2021-05-25 19:44:23 |
Bug Watch Updater |
nfs-utils (Fedora): status |
Unknown |
Confirmed |
|
| 2021-05-25 19:44:23 |
Bug Watch Updater |
nfs-utils (Fedora): importance |
Unknown |
Undecided |
|
| 2021-05-25 20:49:36 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/403288 |
|
| 2021-05-26 13:59:58 |
Andreas Hasenack |
nfs-utils (Ubuntu): status |
New |
In Progress |
|
| 2021-05-26 14:00:01 |
Andreas Hasenack |
nfs-utils (Ubuntu): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2021-05-26 14:00:12 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Groovy |
|
| 2021-05-26 14:00:12 |
Andreas Hasenack |
bug task added |
|
nfs-utils (Ubuntu Groovy) |
|
| 2021-05-26 14:00:12 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Focal |
|
| 2021-05-26 14:00:12 |
Andreas Hasenack |
bug task added |
|
nfs-utils (Ubuntu Focal) |
|
| 2021-05-26 14:00:12 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Bionic |
|
| 2021-05-26 14:00:12 |
Andreas Hasenack |
bug task added |
|
nfs-utils (Ubuntu Bionic) |
|
| 2021-05-26 14:00:12 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Hirsute |
|
| 2021-05-26 14:00:12 |
Andreas Hasenack |
bug task added |
|
nfs-utils (Ubuntu Hirsute) |
|
| 2021-05-26 14:00:23 |
Andreas Hasenack |
nfs-utils (Ubuntu Bionic): importance |
Undecided |
High |
|
| 2021-05-26 14:00:25 |
Andreas Hasenack |
nfs-utils (Ubuntu Focal): importance |
Undecided |
High |
|
| 2021-05-26 14:00:28 |
Andreas Hasenack |
nfs-utils (Ubuntu Hirsute): importance |
Undecided |
High |
|
| 2021-05-26 14:00:30 |
Andreas Hasenack |
nfs-utils (Ubuntu Groovy): importance |
Undecided |
High |
|
| 2021-06-07 19:02:21 |
Andreas Hasenack |
nfs-utils (Ubuntu Hirsute): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2021-06-07 19:02:23 |
Andreas Hasenack |
nfs-utils (Ubuntu Groovy): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2021-06-07 19:02:25 |
Andreas Hasenack |
nfs-utils (Ubuntu Focal): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2021-06-07 19:02:27 |
Andreas Hasenack |
nfs-utils (Ubuntu Bionic): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2021-06-07 19:02:31 |
Andreas Hasenack |
nfs-utils (Ubuntu Bionic): status |
New |
In Progress |
|
| 2021-06-07 19:02:34 |
Andreas Hasenack |
nfs-utils (Ubuntu Focal): status |
New |
In Progress |
|
| 2021-06-07 19:02:36 |
Andreas Hasenack |
nfs-utils (Ubuntu Groovy): status |
New |
In Progress |
|
| 2021-06-07 19:02:40 |
Andreas Hasenack |
nfs-utils (Ubuntu Hirsute): status |
New |
In Progress |
|
| 2021-06-07 19:40:27 |
Andreas Hasenack |
description |
Upgrading the nfs-common debian package will not restart its services.
Specifically, the package tries to restart "nfs-utils.service", which is a "fake" service meant to coordinate all the other daemons that make up a modern NFS server. This service, however, as it is, cannot be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified
Granted, d/rules of the nfs-utils package doesn't even try:
dh_systemd_enable -p nfs-common nfs-client.target
dh_systemd_enable -p nfs-kernel-server nfs-server.service
dh_installinit -pnfs-common -R
dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service
We can see it tries to start and restart it, but that won't work on disabled or non-started services: deb-systemd-invoke won't do it:
# If the job is disabled and is not currently running, the job is not started or restarted.
# However, if the job is disabled but has been forced into the running state, we *do* stop
# and restart it since this is expected behaviour for the admin who forced the start.
# We don't autostart static units either.
The above can be seen while attempting a fresh install (or even upgrade) of nfs-common:
(...)
Setting up nfs-common (1:1.3.4-2.5ubuntu6) ...
Creating config file /etc/idmapd.conf with new version
Adding system user `statd' (UID 113) ...
Adding new user `statd' (UID 113) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
nfs-utils.service is a disabled or a static unit, not starting it.
^^^^^^^^^^^^^^^^^
$ systemctl status nfs-utils.service
● nfs-utils.service - NFS server and client services
Loaded: loaded (/lib/systemd/system/nfs-utils.service; static)
Active: inactive (dead)
This was found while testing the fix for bug #1927745. In that bug, the affected service is rpc.gssd and it's critical that it be restarted, but it's not happening. It will only be restarted if nfs-utils.service is already "started".
I'm marking this bug as "high" because it prevents valid fixes from being deployed after just upgrading a package. |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Plan]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[Where problems could occur]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
Upgrading the nfs-common debian package will not restart its services.
Specifically, the package tries to restart "nfs-utils.service", which is a "fake" service meant to coordinate all the other daemons that make up a modern NFS server. This service, however, as it is, cannot be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified
Granted, d/rules of the nfs-utils package doesn't even try:
dh_systemd_enable -p nfs-common nfs-client.target
dh_systemd_enable -p nfs-kernel-server nfs-server.service
dh_installinit -pnfs-common -R
dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service
We can see it tries to start and restart it, but that won't work on disabled or non-started services: deb-systemd-invoke won't do it:
# If the job is disabled and is not currently running, the job is not started or restarted.
# However, if the job is disabled but has been forced into the running state, we *do* stop
# and restart it since this is expected behaviour for the admin who forced the start.
# We don't autostart static units either.
The above can be seen while attempting a fresh install (or even upgrade) of nfs-common:
(...)
Setting up nfs-common (1:1.3.4-2.5ubuntu6) ...
Creating config file /etc/idmapd.conf with new version
Adding system user `statd' (UID 113) ...
Adding new user `statd' (UID 113) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
nfs-utils.service is a disabled or a static unit, not starting it.
^^^^^^^^^^^^^^^^^
$ systemctl status nfs-utils.service
● nfs-utils.service - NFS server and client services
Loaded: loaded (/lib/systemd/system/nfs-utils.service; static)
Active: inactive (dead)
This was found while testing the fix for bug #1927745. In that bug, the affected service is rpc.gssd and it's critical that it be restarted, but it's not happening. It will only be restarted if nfs-utils.service is already "started".
I'm marking this bug as "high" because it prevents valid fixes from being deployed after just upgrading a package. |
|
| 2021-06-07 19:50:43 |
Andreas Hasenack |
description |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Plan]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
* if other testing is appropriate to perform before landing this update,
this should also be described here.
[Where problems could occur]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
Upgrading the nfs-common debian package will not restart its services.
Specifically, the package tries to restart "nfs-utils.service", which is a "fake" service meant to coordinate all the other daemons that make up a modern NFS server. This service, however, as it is, cannot be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified
Granted, d/rules of the nfs-utils package doesn't even try:
dh_systemd_enable -p nfs-common nfs-client.target
dh_systemd_enable -p nfs-kernel-server nfs-server.service
dh_installinit -pnfs-common -R
dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service
We can see it tries to start and restart it, but that won't work on disabled or non-started services: deb-systemd-invoke won't do it:
# If the job is disabled and is not currently running, the job is not started or restarted.
# However, if the job is disabled but has been forced into the running state, we *do* stop
# and restart it since this is expected behaviour for the admin who forced the start.
# We don't autostart static units either.
The above can be seen while attempting a fresh install (or even upgrade) of nfs-common:
(...)
Setting up nfs-common (1:1.3.4-2.5ubuntu6) ...
Creating config file /etc/idmapd.conf with new version
Adding system user `statd' (UID 113) ...
Adding new user `statd' (UID 113) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
nfs-utils.service is a disabled or a static unit, not starting it.
^^^^^^^^^^^^^^^^^
$ systemctl status nfs-utils.service
● nfs-utils.service - NFS server and client services
Loaded: loaded (/lib/systemd/system/nfs-utils.service; static)
Active: inactive (dead)
This was found while testing the fix for bug #1927745. In that bug, the affected service is rpc.gssd and it's critical that it be restarted, but it's not happening. It will only be restarted if nfs-utils.service is already "started".
I'm marking this bug as "high" because it prevents valid fixes from being deployed after just upgrading a package. |
[Impact]
In order to get the fixes provided by a package update, the affected services shipped in it need to be restarted. When that restart does not happen, the system remains running the old binaries with the bug(s).
This bug was found while testing the fix for #1927745, which affected rpc.gssd, one of the services shipped in nfs-common. Without the restart, systems that installed the update are still affected by the bug.
[Test Plan]
To make the test simple, we are not going to mount an NFSv4 share using kerberos. We are just going to have a minimal configuration that gets rpc.gssd running to demonstrate the before and after of this bug.
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common
sudo apt install nfs-common -y
# note message about nfs-utils.service being disabled/static:
nfs-utils.service is a disabled or a static unit, not starting it.
# Manually start rpc-gssd. It will start, but since we have an empty
# krb5.keytab file, it won't work. That's ok, we are not actually going to
# mount nfsv4
systemctl start rpc-gssd.service
# Check it's running, and make note of its pid:
pidof rpc.gssd
2994
# reinstall nfs-common
sudo apt install --reinstall nfs-common
# note rpc-gssd wasn't restarted
pidof rpc.gssd
2994
# install the fixed nfs-common package:
sudo apt install nfs-commont
# this time, rpc.gssd is restarted
pidof rpc.gssd
5000
[Where problems could occur]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
Upgrading the nfs-common debian package will not restart its services.
Specifically, the package tries to restart "nfs-utils.service", which is a "fake" service meant to coordinate all the other daemons that make up a modern NFS server. This service, however, as it is, cannot be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified
Granted, d/rules of the nfs-utils package doesn't even try:
dh_systemd_enable -p nfs-common nfs-client.target
dh_systemd_enable -p nfs-kernel-server nfs-server.service
dh_installinit -pnfs-common -R
dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service
We can see it tries to start and restart it, but that won't work on disabled or non-started services: deb-systemd-invoke won't do it:
# If the job is disabled and is not currently running, the job is not started or restarted.
# However, if the job is disabled but has been forced into the running state, we *do* stop
# and restart it since this is expected behaviour for the admin who forced the start.
# We don't autostart static units either.
The above can be seen while attempting a fresh install (or even upgrade) of nfs-common:
(...)
Setting up nfs-common (1:1.3.4-2.5ubuntu6) ...
Creating config file /etc/idmapd.conf with new version
Adding system user `statd' (UID 113) ...
Adding new user `statd' (UID 113) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
nfs-utils.service is a disabled or a static unit, not starting it.
^^^^^^^^^^^^^^^^^
$ systemctl status nfs-utils.service
● nfs-utils.service - NFS server and client services
Loaded: loaded (/lib/systemd/system/nfs-utils.service; static)
Active: inactive (dead)
This was found while testing the fix for bug #1927745. In that bug, the affected service is rpc.gssd and it's critical that it be restarted, but it's not happening. It will only be restarted if nfs-utils.service is already "started".
I'm marking this bug as "high" because it prevents valid fixes from being deployed after just upgrading a package. |
|
| 2021-06-07 20:05:34 |
Andreas Hasenack |
description |
[Impact]
In order to get the fixes provided by a package update, the affected services shipped in it need to be restarted. When that restart does not happen, the system remains running the old binaries with the bug(s).
This bug was found while testing the fix for #1927745, which affected rpc.gssd, one of the services shipped in nfs-common. Without the restart, systems that installed the update are still affected by the bug.
[Test Plan]
To make the test simple, we are not going to mount an NFSv4 share using kerberos. We are just going to have a minimal configuration that gets rpc.gssd running to demonstrate the before and after of this bug.
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common
sudo apt install nfs-common -y
# note message about nfs-utils.service being disabled/static:
nfs-utils.service is a disabled or a static unit, not starting it.
# Manually start rpc-gssd. It will start, but since we have an empty
# krb5.keytab file, it won't work. That's ok, we are not actually going to
# mount nfsv4
systemctl start rpc-gssd.service
# Check it's running, and make note of its pid:
pidof rpc.gssd
2994
# reinstall nfs-common
sudo apt install --reinstall nfs-common
# note rpc-gssd wasn't restarted
pidof rpc.gssd
2994
# install the fixed nfs-common package:
sudo apt install nfs-commont
# this time, rpc.gssd is restarted
pidof rpc.gssd
5000
[Where problems could occur]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
Upgrading the nfs-common debian package will not restart its services.
Specifically, the package tries to restart "nfs-utils.service", which is a "fake" service meant to coordinate all the other daemons that make up a modern NFS server. This service, however, as it is, cannot be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified
Granted, d/rules of the nfs-utils package doesn't even try:
dh_systemd_enable -p nfs-common nfs-client.target
dh_systemd_enable -p nfs-kernel-server nfs-server.service
dh_installinit -pnfs-common -R
dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service
We can see it tries to start and restart it, but that won't work on disabled or non-started services: deb-systemd-invoke won't do it:
# If the job is disabled and is not currently running, the job is not started or restarted.
# However, if the job is disabled but has been forced into the running state, we *do* stop
# and restart it since this is expected behaviour for the admin who forced the start.
# We don't autostart static units either.
The above can be seen while attempting a fresh install (or even upgrade) of nfs-common:
(...)
Setting up nfs-common (1:1.3.4-2.5ubuntu6) ...
Creating config file /etc/idmapd.conf with new version
Adding system user `statd' (UID 113) ...
Adding new user `statd' (UID 113) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
nfs-utils.service is a disabled or a static unit, not starting it.
^^^^^^^^^^^^^^^^^
$ systemctl status nfs-utils.service
● nfs-utils.service - NFS server and client services
Loaded: loaded (/lib/systemd/system/nfs-utils.service; static)
Active: inactive (dead)
This was found while testing the fix for bug #1927745. In that bug, the affected service is rpc.gssd and it's critical that it be restarted, but it's not happening. It will only be restarted if nfs-utils.service is already "started".
I'm marking this bug as "high" because it prevents valid fixes from being deployed after just upgrading a package. |
[Impact]
In order to get the fixes provided by a package update, the affected services shipped in it need to be restarted. When that restart does not happen, the system remains running the old binaries with the bug(s).
This bug was found while testing the fix for #1927745, which affected rpc.gssd, one of the services shipped in nfs-common. Without the restart, systems that installed the update are still affected by the bug.
[Test Plan]
To make the test simple, we are not going to mount an NFSv4 share using kerberos. We are just going to have a minimal configuration that gets rpc.gssd running to demonstrate the before and after of this bug.
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common
sudo apt install nfs-common -y
# note message about nfs-utils.service being disabled/static:
nfs-utils.service is a disabled or a static unit, not starting it.
# Manually start rpc-gssd. It will start, but since we have an empty
# krb5.keytab file, it won't work. That's ok, we are not actually going to
# mount nfsv4
systemctl start rpc-gssd.service
# Check it's running, and make note of its pid:
pidof rpc.gssd
2994
# reinstall nfs-common
sudo apt install --reinstall nfs-common
# note rpc-gssd wasn't restarted
pidof rpc.gssd
2994
# install the fixed nfs-common package:
sudo apt install nfs-commont
# this time, rpc.gssd is restarted
pidof rpc.gssd
5000
[Where problems could occur]
Also known as "I'm doing an unconditional start in postinst, what could go wrong":
- start services that were not started with the previous package on first install
- systemd behavior change or bug and suddenly PartOf units also react to "start", instead of just "restart" and "stop" as documented
- starting services that are not configured, and start fails, breaking postinst (but we have the proverbial || true to avoid that)
[Other Info]
This fix is a bit awkward, but I think it's in line with the SRU spirit of doing the least unpredictable change, and one that is simple and can be better understood.
See the linked MP for an explanation of this fix, why it works, and other tests I did:
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/403288
[Original Description]
Upgrading the nfs-common debian package will not restart its services.
Specifically, the package tries to restart "nfs-utils.service", which is a "fake" service meant to coordinate all the other daemons that make up a modern NFS server. This service, however, as it is, cannot be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified
Granted, d/rules of the nfs-utils package doesn't even try:
dh_systemd_enable -p nfs-common nfs-client.target
dh_systemd_enable -p nfs-kernel-server nfs-server.service
dh_installinit -pnfs-common -R
dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service
We can see it tries to start and restart it, but that won't work on disabled or non-started services: deb-systemd-invoke won't do it:
# If the job is disabled and is not currently running, the job is not started or restarted.
# However, if the job is disabled but has been forced into the running state, we *do* stop
# and restart it since this is expected behaviour for the admin who forced the start.
# We don't autostart static units either.
The above can be seen while attempting a fresh install (or even upgrade) of nfs-common:
(...)
Setting up nfs-common (1:1.3.4-2.5ubuntu6) ...
Creating config file /etc/idmapd.conf with new version
Adding system user `statd' (UID 113) ...
Adding new user `statd' (UID 113) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
nfs-utils.service is a disabled or a static unit, not starting it.
^^^^^^^^^^^^^^^^^
$ systemctl status nfs-utils.service
● nfs-utils.service - NFS server and client services
Loaded: loaded (/lib/systemd/system/nfs-utils.service; static)
Active: inactive (dead)
This was found while testing the fix for bug #1927745. In that bug, the affected service is rpc.gssd and it's critical that it be restarted, but it's not happening. It will only be restarted if nfs-utils.service is already "started".
I'm marking this bug as "high" because it prevents valid fixes from being deployed after just upgrading a package. |
|
| 2021-06-07 20:06:48 |
Andreas Hasenack |
description |
[Impact]
In order to get the fixes provided by a package update, the affected services shipped in it need to be restarted. When that restart does not happen, the system remains running the old binaries with the bug(s).
This bug was found while testing the fix for #1927745, which affected rpc.gssd, one of the services shipped in nfs-common. Without the restart, systems that installed the update are still affected by the bug.
[Test Plan]
To make the test simple, we are not going to mount an NFSv4 share using kerberos. We are just going to have a minimal configuration that gets rpc.gssd running to demonstrate the before and after of this bug.
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common
sudo apt install nfs-common -y
# note message about nfs-utils.service being disabled/static:
nfs-utils.service is a disabled or a static unit, not starting it.
# Manually start rpc-gssd. It will start, but since we have an empty
# krb5.keytab file, it won't work. That's ok, we are not actually going to
# mount nfsv4
systemctl start rpc-gssd.service
# Check it's running, and make note of its pid:
pidof rpc.gssd
2994
# reinstall nfs-common
sudo apt install --reinstall nfs-common
# note rpc-gssd wasn't restarted
pidof rpc.gssd
2994
# install the fixed nfs-common package:
sudo apt install nfs-commont
# this time, rpc.gssd is restarted
pidof rpc.gssd
5000
[Where problems could occur]
Also known as "I'm doing an unconditional start in postinst, what could go wrong":
- start services that were not started with the previous package on first install
- systemd behavior change or bug and suddenly PartOf units also react to "start", instead of just "restart" and "stop" as documented
- starting services that are not configured, and start fails, breaking postinst (but we have the proverbial || true to avoid that)
[Other Info]
This fix is a bit awkward, but I think it's in line with the SRU spirit of doing the least unpredictable change, and one that is simple and can be better understood.
See the linked MP for an explanation of this fix, why it works, and other tests I did:
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/403288
[Original Description]
Upgrading the nfs-common debian package will not restart its services.
Specifically, the package tries to restart "nfs-utils.service", which is a "fake" service meant to coordinate all the other daemons that make up a modern NFS server. This service, however, as it is, cannot be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified
Granted, d/rules of the nfs-utils package doesn't even try:
dh_systemd_enable -p nfs-common nfs-client.target
dh_systemd_enable -p nfs-kernel-server nfs-server.service
dh_installinit -pnfs-common -R
dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service
We can see it tries to start and restart it, but that won't work on disabled or non-started services: deb-systemd-invoke won't do it:
# If the job is disabled and is not currently running, the job is not started or restarted.
# However, if the job is disabled but has been forced into the running state, we *do* stop
# and restart it since this is expected behaviour for the admin who forced the start.
# We don't autostart static units either.
The above can be seen while attempting a fresh install (or even upgrade) of nfs-common:
(...)
Setting up nfs-common (1:1.3.4-2.5ubuntu6) ...
Creating config file /etc/idmapd.conf with new version
Adding system user `statd' (UID 113) ...
Adding new user `statd' (UID 113) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
nfs-utils.service is a disabled or a static unit, not starting it.
^^^^^^^^^^^^^^^^^
$ systemctl status nfs-utils.service
● nfs-utils.service - NFS server and client services
Loaded: loaded (/lib/systemd/system/nfs-utils.service; static)
Active: inactive (dead)
This was found while testing the fix for bug #1927745. In that bug, the affected service is rpc.gssd and it's critical that it be restarted, but it's not happening. It will only be restarted if nfs-utils.service is already "started".
I'm marking this bug as "high" because it prevents valid fixes from being deployed after just upgrading a package. |
[Impact]
In order to get the fixes provided by a package update, the affected services shipped in it need to be restarted. When that restart does not happen, the system remains running the old binaries with the bug(s).
This bug was found while testing the fix for #1927745, which affected rpc.gssd, one of the services shipped in nfs-common. Without the restart, systems that installed the update are still affected by the bug.
[Test Plan]
To make the test simple, we are not going to mount an NFSv4 share using kerberos. We are just going to have a minimal configuration that gets rpc.gssd running to demonstrate the before and after of this bug.
For a more thorough testing, which includes actually mounting an NFSv4 export with kerberos, follow the test instructions of bug #1927745, and you will see that the manual restart included because of this bug here, after the package is updated, is no longer needed.
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common
sudo apt install nfs-common -y
# note message about nfs-utils.service being disabled/static:
nfs-utils.service is a disabled or a static unit, not starting it.
# Manually start rpc-gssd. It will start, but since we have an empty
# krb5.keytab file, it won't work. That's ok, we are not actually going to
# mount nfsv4
systemctl start rpc-gssd.service
# Check it's running, and make note of its pid:
pidof rpc.gssd
2994
# reinstall nfs-common
sudo apt install --reinstall nfs-common
# note rpc-gssd wasn't restarted
pidof rpc.gssd
2994
# install the fixed nfs-common package:
sudo apt install nfs-commont
# this time, rpc.gssd is restarted
pidof rpc.gssd
5000
[Where problems could occur]
Also known as "I'm doing an unconditional start in postinst, what could go wrong":
- start services that were not started with the previous package on first install
- systemd behavior change or bug and suddenly PartOf units also react to "start", instead of just "restart" and "stop" as documented
- starting services that are not configured, and start fails, breaking postinst (but we have the proverbial || true to avoid that)
[Other Info]
This fix is a bit awkward, but I think it's in line with the SRU spirit of doing the least unpredictable change, and one that is simple and can be better understood.
See the linked MP for an explanation of this fix, why it works, and other tests I did:
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/403288
[Original Description]
Upgrading the nfs-common debian package will not restart its services.
Specifically, the package tries to restart "nfs-utils.service", which is a "fake" service meant to coordinate all the other daemons that make up a modern NFS server. This service, however, as it is, cannot be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified
Granted, d/rules of the nfs-utils package doesn't even try:
dh_systemd_enable -p nfs-common nfs-client.target
dh_systemd_enable -p nfs-kernel-server nfs-server.service
dh_installinit -pnfs-common -R
dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service
We can see it tries to start and restart it, but that won't work on disabled or non-started services: deb-systemd-invoke won't do it:
# If the job is disabled and is not currently running, the job is not started or restarted.
# However, if the job is disabled but has been forced into the running state, we *do* stop
# and restart it since this is expected behaviour for the admin who forced the start.
# We don't autostart static units either.
The above can be seen while attempting a fresh install (or even upgrade) of nfs-common:
(...)
Setting up nfs-common (1:1.3.4-2.5ubuntu6) ...
Creating config file /etc/idmapd.conf with new version
Adding system user `statd' (UID 113) ...
Adding new user `statd' (UID 113) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
nfs-utils.service is a disabled or a static unit, not starting it.
^^^^^^^^^^^^^^^^^
$ systemctl status nfs-utils.service
● nfs-utils.service - NFS server and client services
Loaded: loaded (/lib/systemd/system/nfs-utils.service; static)
Active: inactive (dead)
This was found while testing the fix for bug #1927745. In that bug, the affected service is rpc.gssd and it's critical that it be restarted, but it's not happening. It will only be restarted if nfs-utils.service is already "started".
I'm marking this bug as "high" because it prevents valid fixes from being deployed after just upgrading a package. |
|
| 2021-06-07 20:36:25 |
Andreas Hasenack |
description |
[Impact]
In order to get the fixes provided by a package update, the affected services shipped in it need to be restarted. When that restart does not happen, the system remains running the old binaries with the bug(s).
This bug was found while testing the fix for #1927745, which affected rpc.gssd, one of the services shipped in nfs-common. Without the restart, systems that installed the update are still affected by the bug.
[Test Plan]
To make the test simple, we are not going to mount an NFSv4 share using kerberos. We are just going to have a minimal configuration that gets rpc.gssd running to demonstrate the before and after of this bug.
For a more thorough testing, which includes actually mounting an NFSv4 export with kerberos, follow the test instructions of bug #1927745, and you will see that the manual restart included because of this bug here, after the package is updated, is no longer needed.
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common
sudo apt install nfs-common -y
# note message about nfs-utils.service being disabled/static:
nfs-utils.service is a disabled or a static unit, not starting it.
# Manually start rpc-gssd. It will start, but since we have an empty
# krb5.keytab file, it won't work. That's ok, we are not actually going to
# mount nfsv4
systemctl start rpc-gssd.service
# Check it's running, and make note of its pid:
pidof rpc.gssd
2994
# reinstall nfs-common
sudo apt install --reinstall nfs-common
# note rpc-gssd wasn't restarted
pidof rpc.gssd
2994
# install the fixed nfs-common package:
sudo apt install nfs-commont
# this time, rpc.gssd is restarted
pidof rpc.gssd
5000
[Where problems could occur]
Also known as "I'm doing an unconditional start in postinst, what could go wrong":
- start services that were not started with the previous package on first install
- systemd behavior change or bug and suddenly PartOf units also react to "start", instead of just "restart" and "stop" as documented
- starting services that are not configured, and start fails, breaking postinst (but we have the proverbial || true to avoid that)
[Other Info]
This fix is a bit awkward, but I think it's in line with the SRU spirit of doing the least unpredictable change, and one that is simple and can be better understood.
See the linked MP for an explanation of this fix, why it works, and other tests I did:
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/403288
[Original Description]
Upgrading the nfs-common debian package will not restart its services.
Specifically, the package tries to restart "nfs-utils.service", which is a "fake" service meant to coordinate all the other daemons that make up a modern NFS server. This service, however, as it is, cannot be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified
Granted, d/rules of the nfs-utils package doesn't even try:
dh_systemd_enable -p nfs-common nfs-client.target
dh_systemd_enable -p nfs-kernel-server nfs-server.service
dh_installinit -pnfs-common -R
dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service
We can see it tries to start and restart it, but that won't work on disabled or non-started services: deb-systemd-invoke won't do it:
# If the job is disabled and is not currently running, the job is not started or restarted.
# However, if the job is disabled but has been forced into the running state, we *do* stop
# and restart it since this is expected behaviour for the admin who forced the start.
# We don't autostart static units either.
The above can be seen while attempting a fresh install (or even upgrade) of nfs-common:
(...)
Setting up nfs-common (1:1.3.4-2.5ubuntu6) ...
Creating config file /etc/idmapd.conf with new version
Adding system user `statd' (UID 113) ...
Adding new user `statd' (UID 113) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
nfs-utils.service is a disabled or a static unit, not starting it.
^^^^^^^^^^^^^^^^^
$ systemctl status nfs-utils.service
● nfs-utils.service - NFS server and client services
Loaded: loaded (/lib/systemd/system/nfs-utils.service; static)
Active: inactive (dead)
This was found while testing the fix for bug #1927745. In that bug, the affected service is rpc.gssd and it's critical that it be restarted, but it's not happening. It will only be restarted if nfs-utils.service is already "started".
I'm marking this bug as "high" because it prevents valid fixes from being deployed after just upgrading a package. |
[Impact]
In order to get the fixes provided by a package update, the affected services shipped in it need to be restarted. When that restart does not happen, the system remains running the old binaries with the bug(s).
This bug was found while testing the fix for #1927745, which affected rpc.gssd, one of the services shipped in nfs-common. Without the restart, systems that installed the update are still affected by the bug.
[Test Plan]
To make the test simple, we are not going to mount an NFSv4 share using kerberos. We are just going to have a minimal configuration that gets rpc.gssd running to demonstrate the before and after of this bug.
For a more thorough testing, which includes actually mounting an NFSv4 export with kerberos, follow the test instructions of bug #1927745, and you will see that the manual restart included because of this bug here, after the package is updated, is no longer needed.
TEST (A)
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common
sudo apt install nfs-common -y
# note message about nfs-utils.service being disabled/static:
nfs-utils.service is a disabled or a static unit, not starting it.
# Manually start rpc-gssd. It will start, but since we have an empty
# krb5.keytab file, it won't work. That's ok, we are not actually going to
# mount nfsv4
systemctl start rpc-gssd.service
# Check it's running, and make note of its pid:
pidof rpc.gssd
2994
# reinstall nfs-common
sudo apt install --reinstall nfs-common
# note rpc-gssd wasn't restarted
pidof rpc.gssd
2994
# install the fixed nfs-common package. Notice the message about starting a disabled or static unit no longer appears:
sudo apt install nfs-common
# this time, rpc.gssd is restarted
pidof rpc.gssd
5000
TEST (B)
This test is to confirm no new services are started after the fixed package is installed for the first time.
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common that has the bug
sudo apt install nfs-common -y
# take a snapshot of running processes
pstree > pstree.old
# purge the nfs-common package
sudo apt purge nfs-common -y
# install the new nfs-common package
sudo apt purge nfs-common -y
# take a new pstree snapshot and compare with the old one
pstree > pstree.new
diff -u pstree.old pstree.new
Should be no difference.
[Where problems could occur]
Also known as "I'm doing an unconditional start in postinst, what could go wrong":
- start services that were not started with the previous package on first install
- systemd behavior change or bug and suddenly PartOf units also react to "start", instead of just "restart" and "stop" as documented
- starting services that are not configured, and start fails, breaking postinst (but we have the proverbial || true to avoid that)
[Other Info]
This fix is a bit awkward, but I think it's in line with the SRU spirit of doing the least unpredictable change, and one that is simple and can be better understood.
See the linked MP for an explanation of this fix, why it works, and other tests I did:
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/403288
[Original Description]
Upgrading the nfs-common debian package will not restart its services.
Specifically, the package tries to restart "nfs-utils.service", which is a "fake" service meant to coordinate all the other daemons that make up a modern NFS server. This service, however, as it is, cannot be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified
Granted, d/rules of the nfs-utils package doesn't even try:
dh_systemd_enable -p nfs-common nfs-client.target
dh_systemd_enable -p nfs-kernel-server nfs-server.service
dh_installinit -pnfs-common -R
dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service
We can see it tries to start and restart it, but that won't work on disabled or non-started services: deb-systemd-invoke won't do it:
# If the job is disabled and is not currently running, the job is not started or restarted.
# However, if the job is disabled but has been forced into the running state, we *do* stop
# and restart it since this is expected behaviour for the admin who forced the start.
# We don't autostart static units either.
The above can be seen while attempting a fresh install (or even upgrade) of nfs-common:
(...)
Setting up nfs-common (1:1.3.4-2.5ubuntu6) ...
Creating config file /etc/idmapd.conf with new version
Adding system user `statd' (UID 113) ...
Adding new user `statd' (UID 113) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
nfs-utils.service is a disabled or a static unit, not starting it.
^^^^^^^^^^^^^^^^^
$ systemctl status nfs-utils.service
● nfs-utils.service - NFS server and client services
Loaded: loaded (/lib/systemd/system/nfs-utils.service; static)
Active: inactive (dead)
This was found while testing the fix for bug #1927745. In that bug, the affected service is rpc.gssd and it's critical that it be restarted, but it's not happening. It will only be restarted if nfs-utils.service is already "started".
I'm marking this bug as "high" because it prevents valid fixes from being deployed after just upgrading a package. |
|
| 2021-06-07 20:49:03 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/403835 |
|
| 2021-06-07 20:49:57 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/403836 |
|
| 2021-06-07 20:50:41 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/403837 |
|
| 2021-06-07 20:51:18 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/403838 |
|
| 2021-06-08 22:28:05 |
Launchpad Janitor |
nfs-utils (Ubuntu): status |
In Progress |
Fix Released |
|
| 2021-06-11 10:42:55 |
Timo Aaltonen |
nfs-utils (Ubuntu Hirsute): status |
In Progress |
Fix Committed |
|
| 2021-06-11 10:42:57 |
Timo Aaltonen |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2021-06-11 10:43:01 |
Timo Aaltonen |
bug |
|
|
added subscriber SRU Verification |
| 2021-06-11 10:43:08 |
Timo Aaltonen |
tags |
|
verification-needed verification-needed-hirsute |
|
| 2021-06-11 10:43:47 |
Timo Aaltonen |
nfs-utils (Ubuntu Groovy): status |
In Progress |
Fix Committed |
|
| 2021-06-11 10:43:57 |
Timo Aaltonen |
tags |
verification-needed verification-needed-hirsute |
verification-needed verification-needed-groovy verification-needed-hirsute |
|
| 2021-06-11 10:45:54 |
Timo Aaltonen |
nfs-utils (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2021-06-11 10:46:04 |
Timo Aaltonen |
tags |
verification-needed verification-needed-groovy verification-needed-hirsute |
verification-needed verification-needed-focal verification-needed-groovy verification-needed-hirsute |
|
| 2021-06-11 10:47:38 |
Timo Aaltonen |
nfs-utils (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2021-06-11 10:47:48 |
Timo Aaltonen |
tags |
verification-needed verification-needed-focal verification-needed-groovy verification-needed-hirsute |
verification-needed verification-needed-bionic verification-needed-focal verification-needed-groovy verification-needed-hirsute |
|
| 2021-06-11 18:33:56 |
Andreas Hasenack |
tags |
verification-needed verification-needed-bionic verification-needed-focal verification-needed-groovy verification-needed-hirsute |
verification-done-hirsute verification-needed verification-needed-bionic verification-needed-focal verification-needed-groovy |
|
| 2021-06-11 20:00:20 |
Andreas Hasenack |
description |
[Impact]
In order to get the fixes provided by a package update, the affected services shipped in it need to be restarted. When that restart does not happen, the system remains running the old binaries with the bug(s).
This bug was found while testing the fix for #1927745, which affected rpc.gssd, one of the services shipped in nfs-common. Without the restart, systems that installed the update are still affected by the bug.
[Test Plan]
To make the test simple, we are not going to mount an NFSv4 share using kerberos. We are just going to have a minimal configuration that gets rpc.gssd running to demonstrate the before and after of this bug.
For a more thorough testing, which includes actually mounting an NFSv4 export with kerberos, follow the test instructions of bug #1927745, and you will see that the manual restart included because of this bug here, after the package is updated, is no longer needed.
TEST (A)
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common
sudo apt install nfs-common -y
# note message about nfs-utils.service being disabled/static:
nfs-utils.service is a disabled or a static unit, not starting it.
# Manually start rpc-gssd. It will start, but since we have an empty
# krb5.keytab file, it won't work. That's ok, we are not actually going to
# mount nfsv4
systemctl start rpc-gssd.service
# Check it's running, and make note of its pid:
pidof rpc.gssd
2994
# reinstall nfs-common
sudo apt install --reinstall nfs-common
# note rpc-gssd wasn't restarted
pidof rpc.gssd
2994
# install the fixed nfs-common package. Notice the message about starting a disabled or static unit no longer appears:
sudo apt install nfs-common
# this time, rpc.gssd is restarted
pidof rpc.gssd
5000
TEST (B)
This test is to confirm no new services are started after the fixed package is installed for the first time.
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common that has the bug
sudo apt install nfs-common -y
# take a snapshot of running processes
pstree > pstree.old
# purge the nfs-common package
sudo apt purge nfs-common -y
# install the new nfs-common package
sudo apt purge nfs-common -y
# take a new pstree snapshot and compare with the old one
pstree > pstree.new
diff -u pstree.old pstree.new
Should be no difference.
[Where problems could occur]
Also known as "I'm doing an unconditional start in postinst, what could go wrong":
- start services that were not started with the previous package on first install
- systemd behavior change or bug and suddenly PartOf units also react to "start", instead of just "restart" and "stop" as documented
- starting services that are not configured, and start fails, breaking postinst (but we have the proverbial || true to avoid that)
[Other Info]
This fix is a bit awkward, but I think it's in line with the SRU spirit of doing the least unpredictable change, and one that is simple and can be better understood.
See the linked MP for an explanation of this fix, why it works, and other tests I did:
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/403288
[Original Description]
Upgrading the nfs-common debian package will not restart its services.
Specifically, the package tries to restart "nfs-utils.service", which is a "fake" service meant to coordinate all the other daemons that make up a modern NFS server. This service, however, as it is, cannot be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified
Granted, d/rules of the nfs-utils package doesn't even try:
dh_systemd_enable -p nfs-common nfs-client.target
dh_systemd_enable -p nfs-kernel-server nfs-server.service
dh_installinit -pnfs-common -R
dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service
We can see it tries to start and restart it, but that won't work on disabled or non-started services: deb-systemd-invoke won't do it:
# If the job is disabled and is not currently running, the job is not started or restarted.
# However, if the job is disabled but has been forced into the running state, we *do* stop
# and restart it since this is expected behaviour for the admin who forced the start.
# We don't autostart static units either.
The above can be seen while attempting a fresh install (or even upgrade) of nfs-common:
(...)
Setting up nfs-common (1:1.3.4-2.5ubuntu6) ...
Creating config file /etc/idmapd.conf with new version
Adding system user `statd' (UID 113) ...
Adding new user `statd' (UID 113) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
nfs-utils.service is a disabled or a static unit, not starting it.
^^^^^^^^^^^^^^^^^
$ systemctl status nfs-utils.service
● nfs-utils.service - NFS server and client services
Loaded: loaded (/lib/systemd/system/nfs-utils.service; static)
Active: inactive (dead)
This was found while testing the fix for bug #1927745. In that bug, the affected service is rpc.gssd and it's critical that it be restarted, but it's not happening. It will only be restarted if nfs-utils.service is already "started".
I'm marking this bug as "high" because it prevents valid fixes from being deployed after just upgrading a package. |
[Impact]
In order to get the fixes provided by a package update, the affected services shipped in it need to be restarted. When that restart does not happen, the system remains running the old binaries with the bug(s).
This bug was found while testing the fix for #1927745, which affected rpc.gssd, one of the services shipped in nfs-common. Without the restart, systems that installed the update are still affected by the bug.
[Test Plan]
To make the test simple, we are not going to mount an NFSv4 share using kerberos. We are just going to have a minimal configuration that gets rpc.gssd running to demonstrate the before and after of this bug.
For a more thorough testing, which includes actually mounting an NFSv4 export with kerberos, follow the test instructions of bug #1927745, and you will see that the manual restart included because of this bug here, after the package is updated, is no longer needed.
TEST (A)
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common
sudo apt install nfs-common -y
# note message about nfs-utils.service being disabled/static:
nfs-utils.service is a disabled or a static unit, not starting it.
# Manually start rpc-gssd. It will start, but since we have an empty
# krb5.keytab file, it won't work. That's ok, we are not actually going to
# mount nfsv4
sudo systemctl start rpc-gssd.service
# Check it's running, and make note of its pid:
pidof rpc.gssd
2994
# reinstall nfs-common
sudo apt install --reinstall nfs-common
# note rpc-gssd wasn't restarted
pidof rpc.gssd
2994
# install the fixed nfs-common package. Notice the message about starting a disabled or static unit no longer appears:
sudo apt install nfs-common
# this time, rpc.gssd is restarted
pidof rpc.gssd
5000
TEST (B)
This test is to confirm no new services are started after the fixed package is installed for the first time.
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common that has the bug
sudo apt install nfs-common -y
# take a snapshot of running processes
pstree > pstree.old
# purge the nfs-common package
sudo apt purge nfs-common -y
# install the new nfs-common package
sudo apt purge nfs-common -y
# take a new pstree snapshot and compare with the old one
pstree > pstree.new
diff -u pstree.old pstree.new
Should be no difference.
[Where problems could occur]
Also known as "I'm doing an unconditional start in postinst, what could go wrong":
- start services that were not started with the previous package on first install
- systemd behavior change or bug and suddenly PartOf units also react to "start", instead of just "restart" and "stop" as documented
- starting services that are not configured, and start fails, breaking postinst (but we have the proverbial || true to avoid that)
[Other Info]
This fix is a bit awkward, but I think it's in line with the SRU spirit of doing the least unpredictable change, and one that is simple and can be better understood.
See the linked MP for an explanation of this fix, why it works, and other tests I did:
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/403288
[Original Description]
Upgrading the nfs-common debian package will not restart its services.
Specifically, the package tries to restart "nfs-utils.service", which is a "fake" service meant to coordinate all the other daemons that make up a modern NFS server. This service, however, as it is, cannot be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified
Granted, d/rules of the nfs-utils package doesn't even try:
dh_systemd_enable -p nfs-common nfs-client.target
dh_systemd_enable -p nfs-kernel-server nfs-server.service
dh_installinit -pnfs-common -R
dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service
We can see it tries to start and restart it, but that won't work on disabled or non-started services: deb-systemd-invoke won't do it:
# If the job is disabled and is not currently running, the job is not started or restarted.
# However, if the job is disabled but has been forced into the running state, we *do* stop
# and restart it since this is expected behaviour for the admin who forced the start.
# We don't autostart static units either.
The above can be seen while attempting a fresh install (or even upgrade) of nfs-common:
(...)
Setting up nfs-common (1:1.3.4-2.5ubuntu6) ...
Creating config file /etc/idmapd.conf with new version
Adding system user `statd' (UID 113) ...
Adding new user `statd' (UID 113) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
nfs-utils.service is a disabled or a static unit, not starting it.
^^^^^^^^^^^^^^^^^
$ systemctl status nfs-utils.service
● nfs-utils.service - NFS server and client services
Loaded: loaded (/lib/systemd/system/nfs-utils.service; static)
Active: inactive (dead)
This was found while testing the fix for bug #1927745. In that bug, the affected service is rpc.gssd and it's critical that it be restarted, but it's not happening. It will only be restarted if nfs-utils.service is already "started".
I'm marking this bug as "high" because it prevents valid fixes from being deployed after just upgrading a package. |
|
| 2021-06-11 20:21:55 |
Andreas Hasenack |
tags |
verification-done-hirsute verification-needed verification-needed-bionic verification-needed-focal verification-needed-groovy |
verification-done-groovy verification-done-hirsute verification-needed verification-needed-bionic verification-needed-focal |
|
| 2021-06-11 20:34:19 |
Andreas Hasenack |
description |
[Impact]
In order to get the fixes provided by a package update, the affected services shipped in it need to be restarted. When that restart does not happen, the system remains running the old binaries with the bug(s).
This bug was found while testing the fix for #1927745, which affected rpc.gssd, one of the services shipped in nfs-common. Without the restart, systems that installed the update are still affected by the bug.
[Test Plan]
To make the test simple, we are not going to mount an NFSv4 share using kerberos. We are just going to have a minimal configuration that gets rpc.gssd running to demonstrate the before and after of this bug.
For a more thorough testing, which includes actually mounting an NFSv4 export with kerberos, follow the test instructions of bug #1927745, and you will see that the manual restart included because of this bug here, after the package is updated, is no longer needed.
TEST (A)
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common
sudo apt install nfs-common -y
# note message about nfs-utils.service being disabled/static:
nfs-utils.service is a disabled or a static unit, not starting it.
# Manually start rpc-gssd. It will start, but since we have an empty
# krb5.keytab file, it won't work. That's ok, we are not actually going to
# mount nfsv4
sudo systemctl start rpc-gssd.service
# Check it's running, and make note of its pid:
pidof rpc.gssd
2994
# reinstall nfs-common
sudo apt install --reinstall nfs-common
# note rpc-gssd wasn't restarted
pidof rpc.gssd
2994
# install the fixed nfs-common package. Notice the message about starting a disabled or static unit no longer appears:
sudo apt install nfs-common
# this time, rpc.gssd is restarted
pidof rpc.gssd
5000
TEST (B)
This test is to confirm no new services are started after the fixed package is installed for the first time.
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common that has the bug
sudo apt install nfs-common -y
# take a snapshot of running processes
pstree > pstree.old
# purge the nfs-common package
sudo apt purge nfs-common -y
# install the new nfs-common package
sudo apt purge nfs-common -y
# take a new pstree snapshot and compare with the old one
pstree > pstree.new
diff -u pstree.old pstree.new
Should be no difference.
[Where problems could occur]
Also known as "I'm doing an unconditional start in postinst, what could go wrong":
- start services that were not started with the previous package on first install
- systemd behavior change or bug and suddenly PartOf units also react to "start", instead of just "restart" and "stop" as documented
- starting services that are not configured, and start fails, breaking postinst (but we have the proverbial || true to avoid that)
[Other Info]
This fix is a bit awkward, but I think it's in line with the SRU spirit of doing the least unpredictable change, and one that is simple and can be better understood.
See the linked MP for an explanation of this fix, why it works, and other tests I did:
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/403288
[Original Description]
Upgrading the nfs-common debian package will not restart its services.
Specifically, the package tries to restart "nfs-utils.service", which is a "fake" service meant to coordinate all the other daemons that make up a modern NFS server. This service, however, as it is, cannot be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified
Granted, d/rules of the nfs-utils package doesn't even try:
dh_systemd_enable -p nfs-common nfs-client.target
dh_systemd_enable -p nfs-kernel-server nfs-server.service
dh_installinit -pnfs-common -R
dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service
We can see it tries to start and restart it, but that won't work on disabled or non-started services: deb-systemd-invoke won't do it:
# If the job is disabled and is not currently running, the job is not started or restarted.
# However, if the job is disabled but has been forced into the running state, we *do* stop
# and restart it since this is expected behaviour for the admin who forced the start.
# We don't autostart static units either.
The above can be seen while attempting a fresh install (or even upgrade) of nfs-common:
(...)
Setting up nfs-common (1:1.3.4-2.5ubuntu6) ...
Creating config file /etc/idmapd.conf with new version
Adding system user `statd' (UID 113) ...
Adding new user `statd' (UID 113) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
nfs-utils.service is a disabled or a static unit, not starting it.
^^^^^^^^^^^^^^^^^
$ systemctl status nfs-utils.service
● nfs-utils.service - NFS server and client services
Loaded: loaded (/lib/systemd/system/nfs-utils.service; static)
Active: inactive (dead)
This was found while testing the fix for bug #1927745. In that bug, the affected service is rpc.gssd and it's critical that it be restarted, but it's not happening. It will only be restarted if nfs-utils.service is already "started".
I'm marking this bug as "high" because it prevents valid fixes from being deployed after just upgrading a package. |
[Impact]
In order to get the fixes provided by a package update, the affected services shipped in it need to be restarted. When that restart does not happen, the system remains running the old binaries with the bug(s).
This bug was found while testing the fix for #1927745, which affected rpc.gssd, one of the services shipped in nfs-common. Without the restart, systems that installed the update are still affected by the bug.
[Test Plan]
To make the test simple, we are not going to mount an NFSv4 share using kerberos. We are just going to have a minimal configuration that gets rpc.gssd running to demonstrate the before and after of this bug.
For a more thorough testing, which includes actually mounting an NFSv4 export with kerberos, follow the test instructions of bug #1927745, and you will see that the manual restart included because of this bug here, after the package is updated, is no longer needed.
TEST (A)
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common
sudo apt install nfs-common -y
# note message about nfs-utils.service being disabled/static:
nfs-utils.service is a disabled or a static unit, not starting it.
# Manually start rpc-gssd. It will start, but since we have an empty
# krb5.keytab file, it won't work. That's ok, we are not actually going to
# mount nfsv4
sudo systemctl start rpc-gssd.service
# Check it's running, and make note of its pid:
pidof rpc.gssd
2994
# reinstall nfs-common
sudo apt install --reinstall nfs-common
# note rpc-gssd wasn't restarted
pidof rpc.gssd
2994
# install the fixed nfs-common package. Notice the message about starting a disabled or static unit no longer appears:
sudo apt install nfs-common
# this time, rpc.gssd is restarted
pidof rpc.gssd
5000
TEST (B)
This test is to confirm no new services are started after the fixed package is installed for the first time.
# create a VM for the affected ubuntu release under test, login and run:
sudo touch /etc/krb5.keytab
sudo chmod 0600 /etc/krb5.keytab
# install nfs-common that has the bug
sudo apt install nfs-common -y
# take a snapshot of running processes
pstree > pstree.old
# purge the nfs-common package
sudo apt purge nfs-common -y
# install the new nfs-common package
sudo apt install nfs-common -y
# take a new pstree snapshot and compare with the old one
pstree > pstree.new
diff -u pstree.old pstree.new
Should be no difference.
[Where problems could occur]
Also known as "I'm doing an unconditional start in postinst, what could go wrong":
- start services that were not started with the previous package on first install
- systemd behavior change or bug and suddenly PartOf units also react to "start", instead of just "restart" and "stop" as documented
- starting services that are not configured, and start fails, breaking postinst (but we have the proverbial || true to avoid that)
[Other Info]
This fix is a bit awkward, but I think it's in line with the SRU spirit of doing the least unpredictable change, and one that is simple and can be better understood.
See the linked MP for an explanation of this fix, why it works, and other tests I did:
https://code.launchpad.net/~ahasenack/ubuntu/+source/nfs-utils/+git/nfs-utils/+merge/403288
[Original Description]
Upgrading the nfs-common debian package will not restart its services.
Specifically, the package tries to restart "nfs-utils.service", which is a "fake" service meant to coordinate all the other daemons that make up a modern NFS server. This service, however, as it is, cannot be enabled:
$ sudo systemctl enable nfs-utils.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
instance name specified
Granted, d/rules of the nfs-utils package doesn't even try:
dh_systemd_enable -p nfs-common nfs-client.target
dh_systemd_enable -p nfs-kernel-server nfs-server.service
dh_installinit -pnfs-common -R
dh_systemd_start -p nfs-common --restart-after-upgrade nfs-utils.service
dh_systemd_start -p nfs-kernel-server --restart-after-upgrade nfs-server.service
We can see it tries to start and restart it, but that won't work on disabled or non-started services: deb-systemd-invoke won't do it:
# If the job is disabled and is not currently running, the job is not started or restarted.
# However, if the job is disabled but has been forced into the running state, we *do* stop
# and restart it since this is expected behaviour for the admin who forced the start.
# We don't autostart static units either.
The above can be seen while attempting a fresh install (or even upgrade) of nfs-common:
(...)
Setting up nfs-common (1:1.3.4-2.5ubuntu6) ...
Creating config file /etc/idmapd.conf with new version
Adding system user `statd' (UID 113) ...
Adding new user `statd' (UID 113) with group `nogroup' ...
Not creating home directory `/var/lib/nfs'.
Created symlink /etc/systemd/system/multi-user.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
Created symlink /etc/systemd/system/remote-fs.target.wants/nfs-client.target → /lib/systemd/system/nfs-client.target.
nfs-utils.service is a disabled or a static unit, not starting it.
^^^^^^^^^^^^^^^^^
$ systemctl status nfs-utils.service
● nfs-utils.service - NFS server and client services
Loaded: loaded (/lib/systemd/system/nfs-utils.service; static)
Active: inactive (dead)
This was found while testing the fix for bug #1927745. In that bug, the affected service is rpc.gssd and it's critical that it be restarted, but it's not happening. It will only be restarted if nfs-utils.service is already "started".
I'm marking this bug as "high" because it prevents valid fixes from being deployed after just upgrading a package. |
|
| 2021-06-11 20:37:42 |
Andreas Hasenack |
tags |
verification-done-groovy verification-done-hirsute verification-needed verification-needed-bionic verification-needed-focal |
verification-done-focal verification-done-groovy verification-done-hirsute verification-needed verification-needed-bionic |
|
| 2021-06-11 20:56:58 |
Andreas Hasenack |
tags |
verification-done-focal verification-done-groovy verification-done-hirsute verification-needed verification-needed-bionic |
verification-done-bionic verification-done-focal verification-done-groovy verification-done-hirsute verification-needed |
|
| 2021-06-16 18:17:55 |
Mathew Hodson |
tags |
verification-done-bionic verification-done-focal verification-done-groovy verification-done-hirsute verification-needed |
verification-done-bionic verification-done-focal verification-done-groovy verification-done-hirsute |
|
| 2021-06-21 07:35:21 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2021-06-21 07:44:38 |
Launchpad Janitor |
nfs-utils (Ubuntu Hirsute): status |
Fix Committed |
Fix Released |
|
| 2021-06-21 08:21:26 |
Launchpad Janitor |
nfs-utils (Ubuntu Groovy): status |
Fix Committed |
Fix Released |
|
| 2021-06-21 08:32:34 |
Launchpad Janitor |
nfs-utils (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2021-06-21 08:56:52 |
Launchpad Janitor |
nfs-utils (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2022-03-01 06:51:51 |
Bug Watch Updater |
nfs-utils (Debian): status |
New |
Fix Released |
|
| 2022-11-30 20:29:58 |
Dan Streetman |
removed subscriber Dan Streetman |
|
|
|
