Project

General

Profile

Bug #5611

Some RPC services do not re-register on rpcbind restart

Added by Marcel Telka almost 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
smf
Start date:
2015-02-11
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

Both ktkt_warnd and fmd_adm RPC services do not re-register after the rpcbind is restarted:

# rpcinfo -s | sort -n
   program version(s) netid(s)                         service     owner
    100000  2,3,4     udp6,tcp6,udp,tcp,ticlts,ticotsord,ticots rpcbind     superuser
    100011  1         udp6,udp,ticlts                  rquotad     superuser
    100021  4,3,2,1   udp6,tcp6,udp,tcp,ticotsord      nlockmgr    1
    100024  1         ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 status      superuser
    100133  1         ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 nsm_addr    superuser
    100134  1         ticotsord                        ktkt_warnd  superuser
    100155  1         tcp6,tcp,ticotsord,ticots        smserverd   superuser
    100169  1         ticots,ticotsord,ticlts          fmd_adm     superuser
    100234  1         ticotsord                        gssd        superuser
1073741824  1         tcp,tcp6                         -           1
# svcadm restart rpc/bind
# sleep 10
# rpcinfo -s | sort -n
   program version(s) netid(s)                         service     owner
    100000  2,3,4     udp6,tcp6,udp,tcp,ticlts,ticotsord,ticots rpcbind     superuser
    100011  1         udp6,udp,ticlts                  rquotad     superuser
    100021  4,3,2,1   udp6,tcp6,udp,tcp,ticotsord      nlockmgr    1
    100024  1         ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 status      superuser
    100133  1         ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 nsm_addr    superuser
    100155  1         tcp6,tcp,ticotsord,ticots        smserverd   superuser
    100234  1         ticotsord                        gssd        superuser
1073741824  1         tcp,tcp6                         -           1
#

Related issues

Related to illumos gate - Bug #5615: fmd should make sure it is registered with rpcbindNew2015-02-13

Actions
#1

Updated by Marcel Telka almost 6 years ago

  • Subject changed from ktkt_warnd and fmd_adm do not re-register on rpcbind restart to Some TPC services do not re-register on rpcbind restart

There are some other similarly affected RPC services:

# rpcinfo -s
   program version(s) netid(s)                         service     owner
    100000  2,3,4     udp6,tcp6,udp,tcp,ticlts,ticotsord,ticots rpcbind     superuser
    100230  1         tcp6,tcp                         metamhd     superuser
    100242  1         tcp6,tcp                         metamedd    superuser
    100229  2,1       tcp6,tcp                         metad       superuser
    100422  2         tcp6,tcp                         -           superuser
# svcadm restart rpc/bind
# sleep 10
# rpcinfo -s
   program version(s) netid(s)                         service     owner
    100000  2,3,4     udp6,tcp6,udp,tcp,ticlts,ticotsord,ticots rpcbind     superuser
#
#2

Updated by Marcel Telka almost 6 years ago

  • Subject changed from Some TPC services do not re-register on rpcbind restart to Some RPC services do not re-register on rpcbind restart
#3

Updated by Marcel Telka almost 6 years ago

  • Status changed from In Progress to Pending RTI

Based on the discussion during the code review I decided to leave the fmd_adm RPC service as is, since the fmd service seems to be critical and we do not want to restart it, unless absolutely necessary.

#4

Updated by Marcel Telka almost 6 years ago

Filed new bug for fmd: #5615

#5

Updated by Electric Monk almost 6 years ago

  • Status changed from Pending RTI to Closed
  • % Done changed from 0 to 100

git commit f770199a45a8893d2f1615ff4e2d13e041992dc3

commit  f770199a45a8893d2f1615ff4e2d13e041992dc3
Author: Marcel Telka <marcel.telka@nexenta.com>
Date:   2015-02-14T18:40:14.000Z

    5611 Some RPC services do not re-register on rpcbind restart
    Reviewed by: Richard Elling <richard.elling@gmail.com>
    Reviewed by: Robert Mustacchi <rm@joyent.com>
    Approved by: Gordon Ross <gwr@nexenta.com>

Also available in: Atom PDF