On 01/01/18 06:19, Sam Varshavchik wrote:
Tom Horsley writes:
> On Sun, 31 Dec 2017 23:45:12 +0800
> Ed Greshko wrote:
>
> > Everything went smoothly with no delay
>
> I tend to suspect that the rpcbind delay was caused
> by having NFS exports and the NFS services running
> (not that any NFS clients were using the service).
I do not use NFS. systemd still took its sweet time closing and reopening the
listening socket.
To add to my question about why you're even running rpcbind.....
I have a VM that wasn't using NFS and didn't have rpcbind running. So I did the
following....
1. Updated the kernel on its own
2. Did an update with -downloadonly to just download
3. Enabled and started rpcbind service
4. Ran the update under "time"
[root@f27k system]# dnf history
ID | Command line | Date and time | Action(s) | Altered
-------------------------------------------------------------------------------
20 | update | 2018-01-01 11:09 | I, U | 104 EE
This is what time showed....
Complete!
real 2m21.865s
user 0m15.587s
sys 0m41.364s
Which matches the history
[root@f27k system]# dnf history info 20
Transaction ID : 20
Begin time : Mon 01 Jan 2018 11:09:24 AM CST
Begin rpmdb : 1837:de8f325c4e6704f59bfa249eea36d28640ba7192
End time : Mon 01 Jan 2018 11:11:31 AM CST (127 seconds)
And the socket was recreated....
egreshko@f27k ~]$ ps -eaf | grep rpcbind
rpc 14817 1 0 11:07 ? 00:00:00 /usr/bin/rpcbind -w -f
[egreshko@f27k ~]$ ps -eaf | grep rpcbind
rpc 15256 1 0 11:11 ? 00:00:00 /usr/bin/rpcbind -w -f
No delays.....
I think I'll take some time later today to setup a NFS server and mount a partition
from another system to see if it causes an issue with the update.
--
Fedora Users List - The place to go to speculate endlessly