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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
