Bug 1100752

Summary:	Bad boot order of crond and sssd breaks crond @reboot actions for LDAP users
Product:	[Fedora] Fedora	Reporter:	Rolf Fokkens <rolf>
Component:	sssd	Assignee:	Jakub Hrozek <jhrozek>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	20	CC:	abokovoy, jhrozek, jsiero, lslebodn, pbonzini, pbrezina, pmatilai, rolf, sbose, sgallagh, ssorce
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	sssd-1.11.7-2.fc20	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-12-18 10:47:55 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 Rolf Fokkens 2014-05-23 11:42:49 UTC

Description of problem:
For LDAP user @reboot cron entries are not executed.

Version-Release number of selected component (if applicable):
sssd-1.11.5.1-1.fc20.x86_64
cronie-1.4.11-4.fc20.x86_64

How reproducible:
100%

Steps to Reproduce:
1. create a @reboot cron entry as an LDAP user
2. reboot the system
3. note that the @reboot entry has not been executed

Actual results:
Failing @reboot entries for LDAP users

Expected results:
Successful @reboot entries for LDAP users

Additional info:
Adding a "Before=" line to /usr/lib/systemd/system/sssd.service solves the issue, e.g.:
[Unit]
Description=System Security Services Daemon
# SSSD will not be started until syslog is
After=syslog.target
Before=crond.service

[Service]
EnvironmentFile=-/etc/sysconfig/sssd
ExecStart=/usr/sbin/sssd -D -f
# These two should be used with traditional UNIX forking daemons
# consult systemd.service(5) for more details
Type=forking
PIDFile=/var/run/sssd.pid

[Install]
WantedBy=multi-user.target

Comment 1 Jakub Hrozek 2014-05-23 14:36:20 UTC

I think the request makes sense, sssd users must be available to crond.

I checked with systemd maintainers and the order doesn't matter, but I personally like to have Before=crond.service in sssd.service better than the other way around.

But I think there is also a more generic question -- since sssd provides user accounts, *any* service that needs user accounts must be started after sssd.

I wonder if we should start sssd before the basic target..but I need to do a bit more research..

Comment 2 Jakub Hrozek 2014-05-23 14:42:42 UTC

Sorry, I was ambiguous earlier. When I said 'order doesn't matter', I meant it doesn't matter whether we use Before=crond.service in sssd or After=sssd.service in crond.

Comment 3 Panu Matilainen 2014-09-05 04:26:20 UTC

(In reply to Jakub Hrozek from comment #1)
> But I think there is also a more generic question -- since sssd provides
> user accounts, *any* service that needs user accounts must be started after
> sssd.

FWIW, a similar situation exists with systemd-user-sessions.service, causing a long delay on shutdown (see bug 1088619, especially comment 44 onwards).

Comment 4 Paolo Bonzini 2014-09-05 09:45:46 UTC

Since order doesn't matter, perhaps it would make sense to have a standard users.target unit.  Cron and systemd-user-sessions.service can be After=users.target, sssd (or any other daemon that provides user accounts) can be Before=users.target.

Comment 5 Jakub Hrozek 2014-09-05 11:41:05 UTC

(In reply to Paolo Bonzini from comment #4)
> Since order doesn't matter, perhaps it would make sense to have a standard
> users.target unit.  Cron and systemd-user-sessions.service can be
> After=users.target, sssd (or any other daemon that provides user accounts)
> can be Before=users.target.

I am testing a package update with what has been suggested by the systemd developers:

Before=nss-user-lookup.target 
Wants=nss-user-lookup.target

Comment 6 Jakub Hrozek 2014-09-05 12:39:08 UTC

Here is a scratch build implementing what I said in comment #5:
https://bugzilla.redhat.com/show_bug.cgi?id=1100752#c5

I think crond should now add after=nss-user-lookup.target

Comment 7 Jakub Hrozek 2014-09-05 12:39:34 UTC

Of course that was a wrong link, sorry:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7530061

Comment 8 Lukas Slebodnik 2014-10-03 07:44:37 UTC

This problem should be fixed in sssd-1.11.7-2.fc20, which is in update-testing.
Could you test that package and provide karma?

Comment 9 Rolf Fokkens 2014-10-04 06:41:21 UTC

I dit some testing and I can confirm the issue is solved.