On Mon, Jan 1, 2018 at 9:42 AM, Patrick O'Callaghan
wrote:
> On Mon, 2018-01-01 at 09:19 -0500, Tom H wrote:
>>
>> rpcbind should not enable itself:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1087951
>
> Thanks, I added a comment to the BZ report and disabled
> rpcbind.service, however it's
Sam Varshavchik:
>> I'm sure that folks running on a UPS would appreciate a system
>> shutdown triggered by a power failure, by a low power alert from
>> the UPS, now having to wait until the man page cache gets updated.
Tom Horsley:
> Or someone trying to shutdown their laptop to board a plane :
On Tue, 2018-01-02 at 04:33 +0800, Ed Greshko wrote:
> On 01/02/18 00:19, Patrick O'Callaghan wrote:
> > On Mon, 2018-01-01 at 23:03 +0800, Ed Greshko wrote:
> > > On 01/01/18 22:42, Patrick O'Callaghan wrote:
> > > > Thanks, I added a comment to the BZ report and disabled
> > > > rpcbind.service,
On 01/02/18 00:19, Patrick O'Callaghan wrote:
> On Mon, 2018-01-01 at 23:03 +0800, Ed Greshko wrote:
>> On 01/01/18 22:42, Patrick O'Callaghan wrote:
>>> Thanks, I added a comment to the BZ report and disabled
>>> rpcbind.service, however it's also necessary to disable and stop
>>> rpcbind.socket.
On Mon, 2018-01-01 at 23:03 +0800, Ed Greshko wrote:
> On 01/01/18 22:42, Patrick O'Callaghan wrote:
> > Thanks, I added a comment to the BZ report and disabled
> > rpcbind.service, however it's also necessary to disable and stop
> > rpcbind.socket.
>
>
> Do you feel a bit strange adding a commen
On Mon, 2018-01-01 at 23:10 +0800, Ed Greshko wrote:
> On 01/01/18 23:03, Ed Greshko wrote:
> > On 01/01/18 22:42, Patrick O'Callaghan wrote:
> > > Thanks, I added a comment to the BZ report and disabled
> > > rpcbind.service, however it's also necessary to disable and stop
> > > rpcbind.socket.
>
On 01/01/18 23:03, Ed Greshko wrote:
> On 01/01/18 22:42, Patrick O'Callaghan wrote:
>> Thanks, I added a comment to the BZ report and disabled
>> rpcbind.service, however it's also necessary to disable and stop
>> rpcbind.socket.
>
> Do you feel a bit strange adding a comment to a BZ that was clos
On 01/01/18 22:42, Patrick O'Callaghan wrote:
> Thanks, I added a comment to the BZ report and disabled
> rpcbind.service, however it's also necessary to disable and stop
> rpcbind.socket.
Do you feel a bit strange adding a comment to a BZ that was closed back in
2014?
:-) :-)
--
Fedora User
On Mon, 2018-01-01 at 09:19 -0500, Tom H wrote:
> On Sun, Dec 31, 2017 at 10:32 PM, Sam Varshavchik
> wrote:
> >
> > My rpcbind service seemed to have been enabled in 2011. Its current vendor
> > preset is "disabled". So, I guess, it wouldn't be enabled today, by default.
> > Was it enabled by d
On Sun, Dec 31, 2017 at 10:32 PM, Sam Varshavchik wrote:
>
> My rpcbind service seemed to have been enabled in 2011. Its current vendor
> preset is "disabled". So, I guess, it wouldn't be enabled today, by default.
> Was it enabled by default in 2011? No idea. What does disabling it would
> mean,
On 01/01/18 22:03, Patrick O'Callaghan wrote:
> On Mon, 2018-01-01 at 21:55 +0800, Ed Greshko wrote:
>>
>> I suppose it may be interesting to know what "rpcinfo" returns.
> $ rpcinfo
>program version netid addressserviceowner
> 104tcp6 ::.0.111
On Mon, 2018-01-01 at 21:55 +0800, Ed Greshko wrote:
> On 01/01/18 20:31, Patrick O'Callaghan wrote:
> > On Mon, 2018-01-01 at 12:04 +0800, Ed Greshko wrote:
> > > On 01/01/18 11:32, Sam Varshavchik wrote:
> > > > My rpcbind service seemed to have been enabled in 2011. Its current
> > > > vendor p
On 01/01/18 20:31, Patrick O'Callaghan wrote:
> On Mon, 2018-01-01 at 12:04 +0800, Ed Greshko wrote:
>> On 01/01/18 11:32, Sam Varshavchik wrote:
>>> My rpcbind service seemed to have been enabled in 2011. Its current vendor
>>> preset
>>> is "disabled". So, I guess, it wouldn't be enabled today,
On Mon, 2018-01-01 at 12:04 +0800, Ed Greshko wrote:
> On 01/01/18 11:32, Sam Varshavchik wrote:
> >
> > My rpcbind service seemed to have been enabled in 2011. Its current vendor
> > preset
> > is "disabled". So, I guess, it wouldn't be enabled today, by default. Was it
> > enabled by default in
On 01/01/18 11:27, Ed Greshko wrote:
> 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.
FWIW, I have enabled the nfs.service on the VM and exported and mounted a
partition
on a remote system
On 01/01/18 11:32, Sam Varshavchik wrote:
>
> My rpcbind service seemed to have been enabled in 2011. Its current vendor
> preset
> is "disabled". So, I guess, it wouldn't be enabled today, by default. Was it
> enabled by default in 2011? No idea. What does disabling it would mean, with
> respect
Ed Greshko writes:
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 r
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 an
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 an
On Sun, 31 Dec 2017 17:18:57 -0500
Sam Varshavchik wrote:
> I'm sure that folks running on a UPS would appreciate a system shutdown
> triggered by a power failure, by a low power alert from the UPS, now having
> to wait until the man page cache gets updated.
Or someone trying to shutdown thei
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. system
Tom Horsley writes:
OK, I just updated my system and got the same
ridiculous delays I saw someone else complain about
That someone else was me, of course, and this was not rpcbind's fault. The
rpcbind package leaves it to systemd to close and reopen its listening
socket. This is, apparentl
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).
___
u
On 12/31/17 23:32, Tom Horsley wrote:
> OK, I just updated my system and got the same
> ridiculous delays I saw someone else complain about
> recently. Not once, but twice. First when
> it installed the new rpcbind, then second
> when it ran the rpcbind scriptlet.
>
> Worse than that, when I reboot
24 matches
Mail list logo
