Das ist ein sehr gutes Beispiel, warum man den Befehl service seit der Einführung von systemd (und damit systemctl) nicht mehr verwenden sollte.
Du kannst dir den Quelltext des service-Befehls anschauen (/usr/sbin/service). Mit der Option --status-all wechselt dieses Skript nach /etc/init.d und führt jede dort liegende ausführbare Datei mit einer vorher definierten Umgebung und dem Argument status aus. Von diesem Aufruf werden der Rückgabewert und die Ausgabe gespeichert.
Den Marker [ + ] erhält ein Dienst, wenn der Rückgabewert des ausgeführten Programms 0 ist und die Länge der erfassten Ausgabe nicht null. Zuvor wird noch getestet, ob die Ausgabe der ausgeführten Datei die Zeichenkette usage: (Groß- und Kleinschreibung wird ignoriert) enthält, um den Marker [ ? ] zu setzen. Für alle anderen Fälle ergibt sich dann [ - ].
Nun ein Beispiel am Lebenden Objekt
/etc/init.d$ ls
acpid console-setup.sh grub-common lvm2 mdadm-waitidle plymouth-log ssh
apache2 cron hwclock.sh lvm2-lvmetad networking procps udev
apache-htcacheclean cryptdisks irqbalance lvm2-lvmpolld nfs-common rpcbind ufw
apparmor cryptdisks-early iscsid lxcfs open-iscsi rsync uuidd
apport dbus keyboard-setup.sh lxd open-vm-tools rsyslog
atd ebtables kmod mdadm plymouth screen-cleanup
/etc/init.d$ ./apache-htcacheclean status
* apache-htcacheclean is not running
/etc/init.d$ echo $?
0
Fragst du service direkt nach dem status eines Dienstes, wird dieser stattdessen ein systemctl durchgereicht, welches die dann eine wesentlich richtigere Antwort geben kann.