1) If the service is defined with 'simple' type, the result of 'systemctl' is 0 regardless of actual startup result, because it reports success/failure of forking process (even before cupsd is started). This way errors due bad configuration or programming errors are masked during systemctl invocation.
The 'notify' type depends on executable sending a 'Im running' type of message to systemd after successful start and systemctl's return code depends whether this message came or not, which solves the issue.
2) The service needs to be started after all units needed for network.target are activated. This prevents starting cupsd before we have ports ready.
Fedora bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=
1153660 (adding network.target)
https://bugzilla.redhat.com/show_bug.cgi?id=
1088918 (change of the service type)
[Unit]
Description=CUPS Scheduler
Documentation=man:cupsd(8)
-After=sssd.service
+After=network.target sssd.service
Requires=cups.socket
[Service]
ExecStart=@sbindir@/cupsd -l
-Type=simple
+Type=notify
Restart=on-failure
[Install]
#ifdef HAVE_ONDEMAND
if (OnDemand)
+ {
cupsdAddEvent(CUPSD_EVENT_SERVER_STARTED, NULL, NULL, "Scheduler started on demand.");
- else
+# ifdef HAVE_SYSTEMD
+ sd_notifyf(0, "READY=1\n"
+ "STATUS=Scheduler is running...\n"
+ "MAINPID=%lu",
+ (unsigned long) getpid());
+# endif /* HAVE_SYSTEMD */
+ } else
+
#endif /* HAVE_ONDEMAND */
if (fg)
cupsdAddEvent(CUPSD_EVENT_SERVER_STARTED, NULL, NULL, "Scheduler started in foreground.");