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
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..
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.
(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).
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.
(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
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
Of course that was a wrong link, sorry: http://koji.fedoraproject.org/koji/taskinfo?taskID=7530061
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?
I dit some testing and I can confirm the issue is solved.