Bug 1558690 - Restarting ctdb.service causes nmb.service to fail
Summary: Restarting ctdb.service causes nmb.service to fail
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: samba
Version: rhgs-3.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: Development Freeze
: RHGS 3.5.z Async Update
Assignee: Anoop C S
QA Contact: Aditya Ramteke
URL:
Whiteboard:
Depends On:
Blocks: 1888638
TreeView+ depends on / blocked
 
Reported: 2018-03-20 19:42 UTC by Dustin Black
Modified: 2020-10-29 06:27 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, NMB deamon was uninitialized within 50.samba legacy event script. Due to this, even if the CTDB service was restarted, it failed to start the NMB deamon. With this update, NMB service related parts were seperated into the new 48.netbios event script with CTDB_SERVICE_NMB initialized as "nmb" (enabled via "ctdb event script enable legacy 48.netbios").Now, restarting CTDB service brings up NMB daemon provided 48.netbios legacy script is enabled.
Clone Of:
: 1888638 (view as bug list)
Environment:
Last Closed: 2020-10-29 06:27:25 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gitlab samba-team samba merge_requests 1151 0 None None None 2020-02-27 09:21:55 UTC
Red Hat Product Errata RHBA-2020:4403 0 None None None 2020-10-29 06:27:39 UTC

Description Dustin Black 2018-03-20 19:42:06 UTC
Description of problem:
When using CTDB with Samba, if the ctdb and nmb services are both enabled, restarting ctdb.service will cause nmb.service to fail and not recovery.

There should be an 'After' and 'Requires' dependency in the nmb.service systemd file for ctdb.service.

Version-Release number of selected component (if applicable):
219-42.el7_4.4

How reproducible:
Consistently

Steps to Reproduce:
1. Configure and enable both the CTDB and NMB services
2. Start both services
3. Restart the CTDB service

Actual results:
The NMB service is in a failed state requiring manual intervention

Expected results:
The NMB service recovers correctly based on systemd dependency

Additional info:

Comment 2 Michal Sekletar 2018-03-21 14:07:27 UTC
Dependencies should be fixed in the respective service. Reassigning to samba.

Comment 3 Dustin Black 2018-03-21 20:15:59 UTC
Note that my solution of setting the nmb.service to require ctdb.service only works if ctdb is in use, and would break things if it was not. I'm not sure of the actual best solution for this problem.

Comment 4 Andreas Schneider 2018-04-04 13:47:01 UTC
What exactly stops working. nmbd doesn't talk to ctdb at all.

Comment 6 Dustin Black 2018-04-05 14:03:03 UTC
(In reply to Andreas Schneider from comment #4)
> What exactly stops working. nmbd doesn't talk to ctdb at all.

The problem may actually be because CTDB is set to control the Samba service. So when CTDB restarts, so does Samba. Would restarting Samba outside of systemd cause the nmbd service to fail?

Comment 8 Anoop C S 2018-04-13 06:01:48 UTC
(In reply to Dustin Black from comment #6)
> (In reply to Andreas Schneider from comment #4)
> > What exactly stops working. nmbd doesn't talk to ctdb at all.
> 
> The problem may actually be because CTDB is set to control the Samba
> service.

Why do you think it is a problem?

> So when CTDB restarts, so does Samba.

This dependency is configured via the parameter CTDB_MANAGES_SAMBA. When set to 'yes' CTDB will try to bring up and monitor smbd.

> Would restarting Samba outside of systemd cause the nmbd service to fail?

Do you have journal entries, nmbd, smbd and ctdb logs which indicate the error?

(In reply to Dustin Black from comment #0)
> Steps to Reproduce:
> 1. Configure and enable both the CTDB and NMB services
> 2. Start both services
> 3. Restart the CTDB service

I have ctdbd, smbd and nmbd running in my environment with following parameters set in /etc/sysconfig/ctdb after performing the above steps:
# cat /etc/sysconfig/ctdb 
CTDB_RECOVERY_LOCK=/gluster/lock/lockfile
CTDB_PUBLIC_ADDRESSES=/etc/ctdb/public_addresses
CTDB_MANAGES_SAMBA=yes
CTDB_SAMBA_SKIP_SHARE_CHECK=yes

Comment 17 Anoop C S 2020-01-03 05:27:16 UTC
Pasting the suggestion from Martin:

"""
The script is currently/still based on RHEL versions <= 6.  In those
versions /etc/init.d/smb appears to be the only Samba initscript and it
starts nmbd if necessary (i.e. if disable netbios != Yes).

In RHEL 7 (I have 7.2 handy right now) it appears that this has
changed, with both:

  /usr/lib/systemd/system/nmb.service
  /usr/lib/systemd/system/smb.service

. . .

I think the real fix is to separate out nmbd support into its own event
script.  Would 48.netbios (or similar) provide the right start order
between nmbd, winbindd (via 49.winbind) and smbd (via 50.samba)?  The
new script could be enabled for those that need it on RHEL >= 7 and on
other platforms.  RHEL <= 6 could just depend on the existing script
implicitly starting nmbd when required.
"""

Comment 18 Anoop C S 2020-02-27 09:21:55 UTC
(In reply to Anoop C S from comment #17)
> Pasting the suggestion from Martin:
> 
> """
> The script is currently/still based on RHEL versions <= 6.  In those
> versions /etc/init.d/smb appears to be the only Samba initscript and it
> starts nmbd if necessary (i.e. if disable netbios != Yes).
> 
> In RHEL 7 (I have 7.2 handy right now) it appears that this has
> changed, with both:
> 
>   /usr/lib/systemd/system/nmb.service
>   /usr/lib/systemd/system/smb.service
> 
> . . .
> 
> I think the real fix is to separate out nmbd support into its own event
> script.  Would 48.netbios (or similar) provide the right start order
> between nmbd, winbindd (via 49.winbind) and smbd (via 50.samba)?  The
> new script could be enabled for those that need it on RHEL >= 7 and on
> other platforms.  RHEL <= 6 could just depend on the existing script
> implicitly starting nmbd when required.
> """

Meanwhile above separation for managing nmbd has been implemented upstream.

Comment 38 errata-xmlrpc 2020-10-29 06:27:25 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (samba bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4403


Note You need to log in before you can comment on or make changes to this bug.