Description of problem: Presently, if we reboot a machine the services such as pcsd and nfs-ganesha do not start by default, whereas one has to start them manually post reboot. This should be handled using the chkconfig or update some init files for this purpose. Version-Release number of selected component (if applicable): glusterfs-3.7.1-5.el6rhs.x86_64 nfs-ganesha-2.2.0-3.el6rhs.x86_64 How reproducible: always Additional info:
Could you please confirm what the exact commands and services are that need to be enabled so that everything works fine on boot? I think it's like this on RHEL-7: # systemctl enable pacemaker # systemctl enable nfs-ganesha On RHEL-6: # chkconfig enable pacemaker # chkconfig enable nfs-ganesha Thanks!
yes! on RHEL-6, #chkconfig --add pcsd; chkconfig pcsd on; #chkconfig --add pacemaker; chkconfig pacemaker on; #chkconfig --add nfs-ganesha; chkconfig nfs-ganesha on; on RHEL-7, # systemctl enable pcsd # systemctl enable pacemaker # systemctl enable nfs-ganesha
Doc text is edited. Please sign off to be included in Known Issues.
Doc text looks good to me.
Stretch Goal for 3.1.1
The original 'design' was that if ganesha.nfsd stopped — for any reason — the virtIP failed over and no automatic attempt is made to restart it. The system rebooting, either overtly or spontaneously, is another aspect of ganesha.nfsd stopping. Pacemaker will notice that the node is down, fail the virtIP to another node. It has always been the case that manual intervention is required — by design — to restart the ganesha.nfsd. (After which pacemaker will move the virtIP back.) I do agree though with enabling pcsd and pacemaker to automatically restart after a reboot.
(In reply to Kaleb KEITHLEY from comment #10) > The original 'design' was that if ganesha.nfsd stopped — for any reason — > the virtIP failed over and no automatic attempt is made to restart it. > > The system rebooting, either overtly or spontaneously, is another aspect of > ganesha.nfsd stopping. Pacemaker will notice that the node is down, fail the > virtIP to another node. > > It has always been the case that manual intervention is required — by design > — to restart the ganesha.nfsd. (After which pacemaker will move the virtIP > back.) > > I do agree though with enabling pcsd and pacemaker to automatically restart > after a reboot. If my understanding is not wrong then it is related to doing the settings in a manner that post reboot, until pacemaker and pcsd is not up, nfs-ganesha should not come up. Well, I am also not very sure how to set the priorities with systemd.
email discussion about pcsd auto restart on reboot: >>> and bug1251884 documents that "pcsd is not started by default after >>> reboot by design". >> >> Sort of. I don't see anything in 1251884 about pcsd not restarting being >> _by design_. I see only that we have a documentation fix of some kind >> for the known issue that pcsd was not restarting. See below. > > It was mentioned here in another bug (https://bugzilla.redhat.com > /show_bug.cgi?id=1236017#c8). > In fact 1236017 initially talked about pcsd and nfs-ganesha not starting by > default. But from the discussions we had with Meghana, we thought it was pcsd > which shouldn't be started by default as admin starts it explicitly as one of > the pre-requisites. Hence modified the bug title accordingly and bug1251844 > was raised to document the same in the admin guide. My original set up guide has pcsd enabled to restart automatically after a reboot. This is done in the manual set up (the part we want to simplify and minimize, see https://bugzilla.redhat.com/show_bug.cgi?id=1224205 and https://bugzilla.redhat.com/show_bug.cgi?id=1219886, and there is a doc bug and associated fix in the docs to configure it to restart automatically.) It's my opinion that this is a requirement. This is in contrast to deliberately not setting nfs-ganesha to automatically restart. If there's an issue that affects ganesha, by design we want the admin to resolve the issue before restarting. We want to have pcsd automatically restart so that pacemaker and corosync return to full cluster operational state as quickly as possible. There's no reason I can think of for waiting, or requiring admin intervention to initiate this. Closing this bug as NOTABUG (or WONTFIX?). Reopen if further discussion or clarification is needed.