Bug 612728

This sounds like it would break *way* too much backwards compatibility, automated scripts, etc.

We could certainly change the /sbin/service script to poke systemd if it's running.

Well, the thing is that nobody uses /sbin/service...

In my experience, it's about 60/40 in favor of people who use /sbin/service. Certainly, a good chunk of random online documentation refers to it.

Could you please elaborate what uses you think this would break? Would this change be acceptable to you if we'd ensure that $0 starts with /etc/init.d before we do this? Or would it be acceptable to you if we'd just print the warning to stderr in big letters but would still go on running this? Or would it be acceptable if we'd turn the direct invocations into systemctl invocations?

Either of the latter two; I don't like it being a hard error.

As you intimate, there are some scripts that source /etc/init.d/functions that aren't init scripts, and we'd need to make sure that still works without errors as well.

Ok, here's my second try:

<snip>
if [ $PPID -ne 1 ] && /bin/mountpoint -q /cgroup/systemd ; then

        case "$0" in

        /etc/init.d/*|/etc/rc.d/init.d/*)

                BASENAME="$(/bin/basename $0)"

                echo "Please do not invoke this init script ($0) directly!" > /dev/stderr
                echo -e "Use commands like the following instead:\n"
                echo -e "\t$ systemctl start $BASENAME.service"
                echo -e "\t$ systemctl stop $BASENAME.service"
                echo -e "\t$ systemctl status $BASENAME.service"
                echo -e "\t...\n"
                echo -e "See systemctl(1) for more information.\n"

                if  [ "x$1" = xstart -o \
                        "x$1" = xstop -o \
                        "x$1" = xrestart -o \
                        "x$1" = xreload -o \
                        "x$1" = xstatus ] ; then

                        COMMAND=$1

                        # systemctl's native status command is more verbose than the classic
                        # SysV 'status', hence we turn this into 'check' here.
                        [ $COMMAND = status ] && COMMAND=check

                        echo -e "For compatibility the following command will now be invoked:\n"
                        echo -e "\t$ systemctl -q $COMMAND $BASENAME.service\n"
                        exec /bin/systemctl -q $COMMAND "$BASENAME.service"
                fi
                ;;

        esac
fi
</snip>

This now verifies the executed script is indeed an init script, and then tries to convert the command into systemctl if possible, and otherwise go on with the normal script.

Is this acceptible?

I'd want to set up a machine and do some verification, but it sounds good in theory.

ping?

One independent thing I think we should have done 10 years ago is make the /etc/init.d/foo scripts, if run directly by an admin, transparently redirect to /sbin/service foo "$@".

This would fix several bugs - namely that /etc/init.d/foo often doesn't e.g. clean the environment, and so you can end up with weird crud from the current root shell in the running daemon.

Maybe have /etc/init.d/functions do:

if test -z "$__MAGIC_SERVICE_ENVIRONMENT"; then
  exec /sbin/service $0 "$@"
fi

and /sbin/service does setenv("__MAGIC_SERVICE_ENVIRONMENT", "1") and runs the /etc/init.d script (which in turn unsets the environment variable before execing the daemon).

Hm, if we do that, then we might want to do the redirection as:

init.d/functions -> /sbin/service -> systemctl.

This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Bill, what are your plans on this?

My original patch could use various updates before you merge this if you decide to merge it, i.e. we now support a number of additional sysv-comaptible verbs (i.e. "condrestart" and suchlike), so if you decide to merge this my patch would need more updating.

I am not too concerned by the issues Colin pointed out given that if we start things from systemd the environment will be guaranteed to be cleaned. systemd is much more thorough in providing a clean execution context to start things in then even /sbin/service could offer.

Still in favor of the concept, so updated versions would be nice.

Will be this and bug #616857 supported indefinitely? Or should applications that enable and start services like system-config-date support both chkconfig/service and systemctl?

chkconfig should be modified to support poking systemctl, so that downstream things don't require guessing where a service is configured.

Besides, chkconfig is the well-known, documented way to do things on Red Hat systems. A large chunk of documentation and user knowledge will otherwise need to be rewritten to ensure people know about systemd.

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

initscripts-9.17-1.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/initscripts-9.17-1.fc14

initscripts-9.17-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update initscripts'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/initscripts-9.17-1.fc14

systemd-8-2.fc14,initscripts-9.17-2.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/systemd-8-2.fc14,initscripts-9.17-2.fc14

initscripts-9.17-2.fc14, systemd-8-3.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to Lennart Poettering from comment #2)
> Well, the thing is that nobody uses /sbin/service...

This got pushed to RHEL 7 and broke jenkins - so yes people use it.