Bug 1657349
| Summary: | Winbind doesn't get restarted on package upgrade | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | joel <jwooten> | ||||
| Component: | samba | Assignee: | Andreas Schneider <asn> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | sssd-qe <sssd-qe> | ||||
| Severity: | urgent | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 7.6 | CC: | asn, bugzilla.redhat.com, gdeschner, grajaiya, jarrpa, jhrozek, jstephen, jwooten, lmiksik, lslebodn, mzidek, pbrezina, thalman, tscherf | ||||
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | samba-4.10.4-10.el7 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2021-10-20 09:26:23 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
joel
2018-12-07 17:51:04 UTC
This sounds more like that when the new rpm got installed, the post script of the RPM did not restart winbind through systemd. Restarting winbind manually with systemd fixed the issue. Is that correct? If yes, we need to look at yum logs and systemd logs why systemd was not able to restart winbindd. Hello, Yes rebooting the system fixed the issue. I have attached the yum logs, customer does not have "systemd" logs. Can you tell me how to set that up debugging to capture that? Created attachment 1515424 [details]
yum logs
The log doesn't show any error. Andreas, After winbind is updated it's files seem to loose their nodes(not sure if that is the correct way to say it) root@RDRE1-DALEX01:~ # ls -l /usr/lib64/libwbclient.so.0 lrwxrwxrwx. 1 root root 19 Dec 6 14:35 /usr/lib64/libwbclient.so.0 -> libwbclient.so.0.14 root@RDRE1-DALEX01:~ # ls -l /usr/lib64/libwbclient.so.0.14 lrwxrwxrwx. 1 root root 40 Dec 6 14:35 /usr/lib64/libwbclient.so.0.14 -> /etc/alternatives/libwbclient.so.0.14-64 root@RDRE1-DALEX01:~ # ls -l /etc/alternatives/libwbclient.so.0.14-64 lrwxrwxrwx. 1 root root 45 Dec 6 14:35 /etc/alternatives/libwbclient.so.0.14-64 -> /usr/lib64/samba/wbclient/libwbclient.so.0.14 root@RDRE1-DALEX01:~ # ls -l /usr/lib64/samba/wbclient/libwbclient.so.0.14 -rwxr-xr-x. 1 root root 57472 Aug 9 09:41 /usr/lib64/samba/wbclient/libwbclient.so.0.14 This is strange. Does reinstalling the libwbclient package fix it? At this point the cu found that restarting winbind solved his issue: 1) All our RHEL7.5 machines use winbind to talk to AD (and allow people to login with windows credentials) 2) When I do a "yum update" to 7.6, right after it installs the new winbind packages, SSH just times out and so does the console login. They hang for 30+ seconds and then reset. 3) So after the binbind packages are installed, no one can access the machine. IF however, I ssh in with a couple shells, and run "yum update", ssh and console logins still break, but the existing logins are still valid. If at that time I restart winbind, SSH and Console logins work again. cu has implemented his own work around of adding stop|start winbind commands to his scripts, but doesn't feel this is the best solution as he has to cut all existing connections. Moving to sssd per Sumits request. Found the issue in our spec file. 1. Winbind isn't restarted on package upgrade that means that the system is in a non-functional state after the upgrade and users are not able to login. 2. This is just a package change that winbind gets probably restarted, there is not code change and no risk that anything breaks! 3. - Fails for us when upgrading from 7.7->7.8 packages in CR repo, causing all authentication to fail until rebooted or the winbind service is restarted. Please update the upgrade scripts as this is a major bug which will break all our hosts (which use winbind for AD authentication and user info) when the 7.8 update is released. I don't think this is just because winbind isn't getting restarted, as it *is* getting restarted! I believe instead that this is a problem with it not being restarted after other packages which contain libraries on which it is dependent are upgraded. For example, the output of `lsof` on the running winbind process using : `lsof -p $(pidof -s /usr/sbin/winbindd) | grep lib | grep DEL` ..contains various libraries. Picking one at random as `/usr/lib64/libsamba-passdb.so*` we can find that this is in the package samba-client-libs, which has also been upgraded. However, the winbindd processes started a couple of minutes *before* the new libsamba-passdb.so* files were created, so it's not getting kicked when these upgrade. On Debian-based distros there is a `needrestart` command which is used to check which services need restarting after package upgrades (or possibly before, judging by the files which are contained in the packages?) and then the restart is scheduled for once all the dependent upgrades are complete. How can we achieve the same on RHEL/CentOS during samba upgrades? Ignore the first line of my previous comment -- it isn't getting restarted but the same subsequent query applies. (I thought it was, judging by the process start time, but I had rebooted the test host just before performing the upgrade, oops! :) `needrestart` handles this correctly when installed and set to automatically restart services when updates are installed. Is this the intended fix and that winbind and other daemons are *not* supposed to restart themselves automatically when they upgrade? If so this should be documented as required. (Can't see how `needs-restarting` can do the same at present, as needrestart as a yum plugin to support this) After a flurry of upgrades, it turns out that smbd also doesn't restart cleanly when upgraded, and needs a kick... Hello, Has there been any progress on this issue? *** This bug has been marked as a duplicate of bug 1878205 *** |