Bug 928447

Summary: automount: lookup_read_master: lookup(sss): getautomntent_r: No such file or directory
Product: [Fedora] Fedora Reporter: Orion Poplawski <orion>
Component: sssdAssignee: Jakub Hrozek <jhrozek>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 18CC: igeorgex, ikent, jhrozek, pbrezina, sbose, sgallagh, ssorce
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-19 04:50:48 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:

Description Orion Poplawski 2013-03-27 16:37:57 UTC
Description of problem:

I'm using sssd for automount maps.  There appears to be some kind of race condition so that sometimes on boot automount fails to read the maps from sssd.  I get:

Mar 27 10:23:12 amakihi automount[959]: lookup_read_master: lookup(sss): getautomntent_r: No such file or directory

With:

[autofs]
debug_level = 5

in sssd.conf I don't get much:

(Wed Mar 27 10:23:03 2013) [sssd[autofs]] [sbus_init_connection] (0x0200): Adding connection 7F3B98147150
(Wed Mar 27 10:23:03 2013) [sssd[autofs]] [monitor_common_send_id] (0x0100): Sending ID: (autofs,1)
(Wed Mar 27 10:23:03 2013) [sssd[autofs]] [sss_names_init] (0x0100): Using re [(?P<name>[^@]+)@?(?P<domain>[^@]*$)].
(Wed Mar 27 10:23:03 2013) [sssd[autofs]] [sbus_init_connection] (0x0200): Adding connection 7F3B98144150
(Wed Mar 27 10:23:03 2013) [sssd[autofs]] [dp_common_send_id] (0x0100): Sending ID to DP: (1,autofs)
(Wed Mar 27 10:23:03 2013) [sssd[autofs]] [sysdb_domain_init_internal] (0x0200): DB File for default: /var/lib/sss/db/cache_default.ldb
(Wed Mar 27 10:23:03 2013) [sssd[autofs]] [id_callback] (0x0100): Got id ack and version (1) from Monitor
(Wed Mar 27 10:23:03 2013) [sssd[autofs]] [dp_id_callback] (0x0100): Got id ack and version (1) from DP
(Wed Mar 27 10:23:11 2013) [sssd[autofs]] [sss_cmd_get_version] (0x0200): Received client version [1].
(Wed Mar 27 10:23:11 2013) [sssd[autofs]] [sss_cmd_get_version] (0x0200): Offered version [1].
(Wed Mar 27 10:23:11 2013) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): name 'auto.master' matched without domain, user is auto.master
(Wed Mar 27 10:23:11 2013) [sssd[autofs]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)]
(Wed Mar 27 10:23:12 2013) [sssd[autofs]] [client_recv] (0x0200): Client disconnected!

I'll try again with debug_level = 10 and turn on autofs debugging, although it seems like that affects the race somehow.

Restarting autofs fixes it.

Version-Release number of selected component (if applicable):
autofs-5.0.7-12.fc18.x86_64
sssd-1.9.4-5.fc18.x86_64

How reproducible:
Sometimes

Comment 1 Ian Kent 2013-03-28 01:47:49 UTC
Jakub, any ideas what might cause this?

Comment 2 Jakub Hrozek 2013-03-28 10:03:29 UTC
https://fedorahosted.org/sssd/ticket/1739 perhaps. It would hit you if the automounter map contained a largish number of maps. I'll build a test package.

Comment 3 Jakub Hrozek 2013-03-28 10:22:40 UTC
Orion, can you try this package?

http://koji.fedoraproject.org/koji/taskinfo?taskID=5183730

It is the latest F18 + the fix for upstream #1739.

Comment 4 Orion Poplawski 2013-03-28 16:13:59 UTC
Will do - I'll let you know how it goes.  Unfortunately the problem only happens occasionally.

Comment 5 JM 2013-04-09 16:50:53 UTC
I have the same problem, how can I download a RPM from 

http://koji.fedoraproject.org/koji/taskinfo?taskID=5183730

to test the fix?

Comment 6 Jakub Hrozek 2013-04-10 10:57:43 UTC
(In reply to comment #5)
> I have the same problem, how can I download a RPM from 
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5183730
> 
> to test the fix?

I built the package again for f18-candidate we should get the bug fixed in Fedora anyway:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5236919

Comment 7 Jakub Hrozek 2013-04-10 10:58:16 UTC
(In reply to comment #4)
> Will do - I'll let you know how it goes.  Unfortunately the problem only
> happens occasionally.

Hi Orion, did the problem ever reappear?

Comment 8 Orion Poplawski 2013-04-10 14:51:10 UTC
I don't believe it has.

Comment 9 Jakub Hrozek 2013-04-10 14:55:49 UTC
I'm reasonably certain that the problem was in the SSSD and the fix is correct. 

I'm reassigning the bug to the SSSD and will issue an F-17 and F-18 update. (it's already fixed in F-19).

Comment 10 Fedora Update System 2013-04-10 15:19:16 UTC
sssd-1.9.4-8.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/sssd-1.9.4-8.fc18

Comment 11 Fedora Update System 2013-04-10 15:19:30 UTC
sssd-1.9.4-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/sssd-1.9.4-2.fc17

Comment 12 Fedora Update System 2013-04-11 09:58:55 UTC
Package sssd-1.9.4-8.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sssd-1.9.4-8.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5343/sssd-1.9.4-8.fc18
then log in and leave karma (feedback).

Comment 13 Fedora Update System 2013-04-19 04:50:50 UTC
sssd-1.9.4-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Fedora Update System 2013-04-19 04:51:44 UTC
sssd-1.9.4-8.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.