Currently, luci is quite far away from what is suggested at [1].

These differences/pitfalls are (not exhausting):
- restart != reload
- no system/standard start/stop success/failure pretty messages
  (using sourced "functions" library)
- strange start/stop priority
  - luci starts saslauthd service with 65 10 priorities while luci
    originally defines 25 78
  - proposed priorities are 99 01 (rationale: luci is user application
    so even if it is configured to start automatically with the start of
    system, it can be clearly amongs services that are started last and
    stopped amongs first)
- "if [ $? -ne 0 ]; then return $?; fi" construct is a coding mistake
- for files that shouldn't be ever exposed to each system user for reading
  (even few miliseconds or so is not desired!) and are created dynamically
  by the initscript, it is better to touch them and set required attributes
  and ownership first and then to have their content generated
  (rather then to generate the content and to change attributes and ownership
  as this attitude will create a short gap in which the file is readable
  by any user -- writing to file usually doesn't affect its attributes a/o
  ownership)
- lock file is not currently utilized which makes rmplint reporting an error:

luci.x86_64: E: subsys-not-used /etc/rc.d/init.d/luci
While your daemon is running, you have to put a lock file in
/var/lock/subsys/. To see an example, look at this directory on your machine
and examine the corresponding init scripts.

----
[1] http://fedoraproject.org/wiki/Packaging:SysVInitScript


Note: this was fixed in the context of work on pkg-update upstream
      branch which means the fix ties closely to the major change
      brought from this branch into main-line upstream code
      in connection with bug #660446