Description of problem:

When SERVICE=no is set in /etc/sysconfig/man-db, the one-shot systemd job will fail.

Version-Release number of selected component (if applicable):

man-db-2.7.6.1-9.fc27.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Set SERVICE=no in /etc/sysconfing/man-db
2. Reload systemd
3. Reboot

Actual results:

Perusing systemd logs after the reboot reports that the job has failed.

This can also be reproduced without rebooting by starting the one-shot job manually with "systemctl start":

● man-db-cache-update.service
   Loaded: loaded (/usr/lib/systemd/system/man-db-cache-update.service; static; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sat 2017-12-16 11:11:36 EST; 5min ago
  Process: 2856 ExecStart=/bin/sh -c [ "$SERVICE" != "no" ] && /usr/bin/mandb $OPTS (code=exited, status=1/FAILURE)
 Main PID: 2856 (code=exited, status=1/FAILURE)

Dec 16 11:11:36 thinkpad systemd[1]: Starting man-db-cache-update.service...
Dec 16 11:11:36 thinkpad systemd[1]: man-db-cache-update.service: Main process exited, code=exited, status=1/FAILURE
Dec 16 11:11:36 thinkpad systemd[1]: Failed to start man-db-cache-update.service.
Dec 16 11:11:36 thinkpad systemd[1]: man-db-cache-update.service: Unit entered failed state.
Dec 16 11:11:36 thinkpad systemd[1]: man-db-cache-update.service: Failed with result 'exit-code'.

Expected results:

When configured thusly, the oneshot job should just do nothing and quietly go away.

Additional info:

The command line results in the executed command exiting with a non-zero exit status, when SERVICE=no. This gets interpreted as a failed job.