Bug 842357

I've tested it on a just installed minimal installation + all updates +
dhcp-server package kvm VM [with two eth0 with dhcp-client on it, eth1
for the server not yet configured, but this IMO does not mater here,
network starts fine].

I guess this report is about a start of an unconfigured (see bnc#842360,
perhaps also a not enabled) service, but the systemd-195-13.40.1.x86_64
behaviour is IMO wrong to change into "active (exited)" state:

trinity9:~ # systemctl status dhcpd.service
dhcpd.service - LSB: ISC DHCP 4.x Server
	  Loaded: loaded (/etc/init.d/dhcpd)
	  Active: inactive (dead)
	  CGroup: name=systemd:/system/dhcpd.service

trinity9:~ # systemctl start dhcpd.service
trinity9:~ # systemctl status dhcpd.service
dhcpd.service - LSB: ISC DHCP 4.x Server
	  Loaded: loaded (/etc/init.d/dhcpd)
	  Active: active (exited) since Thu, 2013-09-26 12:09:49 CEST; 14s ago
	 Process: 2243 ExecStart=/etc/init.d/dhcpd start (code=exited, status=6)
	  CGroup: name=systemd:/system/dhcpd.service

Sep 26 12:09:49 trinity9.lab31.mat-home.net systemd[1]: Starting LSB: ISC DHCP 4.x Server...
Sep 26 12:09:49 trinity9.lab31.mat-home.net dhcpd[2243]: Starting ISC DHCPv4 4.x Server ... set DHCPD_INTERFACE in /etc/sysconfig/dhcpd..skipped
Sep 26 12:09:49 trinity9.lab31.mat-home.net systemd[1]: Started LSB: ISC DHCP 4.x Server.
# systemctl show dhcp.service | grep -i remain
RemainAfterExit=no

The LSB header in the init script does not have X-SystemdRemainAfterExit flag.

LSB code 6, that is "program is not configured"

should result in an error and not in "active (exited)".

I think, that the bugs bnc#842356 and bnc#842358 are just results of this.

the dhcp server is configured, see my last comment in bnc#842360.

For completness: same happens with enabled service:

trinity9:~ # systemctl stop dhcpd.service
trinity9:~ # systemctl status dhcpd
dhcpd.service - LSB: ISC DHCP 4.x Server
	  Loaded: loaded (/etc/init.d/dhcpd)
	  Active: inactive (dead) since Thu, 2013-09-26 12:23:36 CEST; 9s ago
	 Process: 2796 ExecStop=/etc/init.d/dhcpd stop (code=exited, status=0/SUCCESS)
	 Process: 2243 ExecStart=/etc/init.d/dhcpd start (code=exited, status=6)
	  CGroup: name=systemd:/system/dhcpd.service
trinity9:~ # systemctl enable dhcpd.service
dhcpd.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig dhcpd on
trinity9:~ # systemctl status dhcpd.service
dhcpd.service - LSB: ISC DHCP 4.x Server
	  Loaded: loaded (/etc/init.d/dhcpd)
	  Active: active (exited) since Thu, 2013-09-26 12:24:23 CEST; 4s ago
	 Process: 2796 ExecStop=/etc/init.d/dhcpd stop (code=exited, status=0/SUCCESS)
	 Process: 2817 ExecStart=/etc/init.d/dhcpd start (code=exited, status=6)
	  CGroup: name=systemd:/system/dhcpd.service

Sep 26 12:24:23 trinity9.lab31.mat-home.net dhcpd[2817]: Starting ISC DHCPv4 4.x Server ... set DHCPD_INTERFACE in /etc/sysconfig/dhcpd..skipped
Sep 26 12:24:23 trinity9.lab31.mat-home.net systemd[1]: Started LSB: ISC DHCP 4.x Server.

BTW: The behavior is also not modified by e.g. SuccessExitStatus & Co:

trinity9:~ # systemctl show dhcpd.service | grep ExitStatus

I do not understand  ... why does /etc/init.d/dhcpd return status 6 (comment #3) if dhcpd is configured (comment #2)

... Beside this SuccessExitStatus is a tag for a systemd service unit to define success exit status:

    SuccessExitStatus=
        Takes a list of exit status definitions that when returned by the 
        main service process will be considered successful termination, in
        addition to the normal successful exit code 0 and the signals SIGHUP,
        SIGINT, SIGTERM and SIGPIPE. Exit status definitions can either be
        numeric exit codes or termination signal names, and are separated by
        spaces. Example: "SuccessExitStatus=1 2 8 SIGKILL", ensures that exit
        codes 1, 2, 8 and the termination signal SIGKILL are considered clean
        service terminations.

And from a look at systemd code, are considered succesfull exit code, in addition to 0, for LSB services, exit code 5 and 6 (and this is wanted, since 2010 at least).

(In reply to comment #5)

Why this is wanted?  From LSB the user should become warned and /etc/rc.status
does this for SysVinit

      -v|-v[1-9]|-v[1-9][0-9])
          local vrt=""
          local out=1
          local opt="en"

          test -n "${i#-v}" && vrt=${esc:+"${esc}[${i#-v}A"} || opt="e"
          case "$_rc_status" in
          0)  vrt="$vrt$rc_done"   ;          ;; # success
          1)  vrt="$vrt$rc_failed" ; out=2    ;; # generic or unspecified error
          2)  vrt="$vrt$rc_failed" ; out=2    ;; # invalid or excess args
          3)  vrt="$vrt$rc_missed" ; out=2    ;; # unimplemented feature
          4)  vrt="$vrt$rc_failed" ; out=2    ;; # insufficient privilege
          5)  vrt="$vrt$rc_skipped"; out=2    ;; # program is not installed
          6)  vrt="$vrt$rc_unused" ; out=2    ;; # program is not configured
          7)  vrt="$vrt$rc_failed" ; out=2    ;; # program is not running
          *)  vrt="$vrt$rc_failed" ; out=2    ;; # unknown (maybe used in future)
          esac
          echo -$opt "$rc_save$vrt$rc_restore" 1>&$out

therefore I'd like to know and understand why systemd does not warn the user.

(In reply to comment #4)
> I do not understand  ... why does /etc/init.d/dhcpd return status 6 (comment
> #3) if dhcpd is configured (comment #2)

In _my_ case it were unconfigured and the script returned code 6.

(In reply to comment #5)
> And from a look at systemd code, are considered succesfull exit code, in
> addition to 0, for LSB services, exit code 5 and 6 (and this is wanted, since
> 2010 at least).

This is IMO nonsense and why I've ressigned it to systemd.

You call "systemctl start X" -- service returns _failure_ because it is not
configured. Then you fix it and call "systemctl start X" again -- no effect,
because it is already in started state -- as systemd assumes wrong [it is
not running -- it reported an error].

So I repat Werners question: Why this is wanted?

(In reply to comment #7)

> You call "systemctl start X" -- service returns _failure_ because it is not
> configured. Then you fix it and call "systemctl start X" again -- no effect,
> because it is already in started state -- as systemd assumes wrong [it is
> not running -- it reported an error].
> 
> So I repat Werners question: Why this is wanted?

I don't know, you would have to ask the systemd folks, I wasn't there when it was designed.

*** Bug 866974 has been marked as a duplicate of this bug. ***

Actually, the return codes of service units were changed with systemd-210.
For reference, please take a look at bsc#901796 .

I've tested with 13.2 and SLES12 and couldn't reproduce the issue:

-->--
# ps aux | grep dhcpd
dhcpd     7643  0.0  0.0  36732  4400 ?        Ss   15:17   0:00 /usr/sbin/dhcpd -4 -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid -chroot /var/lib/dhcp -lf /db/dhcpd.leases -user dhcpd -group nogroup net0 br0
root      7722  0.0  0.0   9256  1624 pts/4    S+   15:22   0:00 grep --color=auto dhcpd

# killall dhcpd

# ps aux | grep dhcpd
root      7746  0.0  0.0   9256  1616 pts/4    S+   15:22   0:00 grep --color=auto dhcpd

# service dhcpd start

# ps aux | grep dhcpd
dhcpd     7931  0.0  0.0  36732  4396 ?        Ss   15:22   0:00 /usr/sbin/dhcpd -4 -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid -chroot /var/lib/dhcp -lf /db/dhcpd.leases -user dhcpd -group nogroup net0 br0
root      7936  0.0  0.0   9256  1572 pts/4    S+   15:22   0:00 grep --color=auto dhcpd
--<--

-> closing as fixed in latest version.