On 21 June 2013 11:24, Chow Loong Jin <[email protected]> wrote: > On Fri, Jun 21, 2013 at 10:34:54AM +0100, Dmitrijs Ledkovs wrote: >> On 20 June 2013 18:26, Russ Allbery <[email protected]> wrote: >> > Dmitrijs Ledkovs <[email protected]> writes: >> > >> >> Thus in a bug report 712763 [4], included below, I instead propose >> >> instead shipping slightly larger block of code in the upstart package >> >> which is sourced by /lib/lsb/init-functions from init-functions.d >> >> directory. Something along the lines of: >> > >> >> if init_is_upstart; then >> >> upstart_job=/etc/init/$(basename ${0:-}).conf >> >> if [ -f ${upstart_job:-} ] && [ ! -L ${upstart_job:-} ]; then >> >> case "${1:-}" in >> >> start|restart|force-reload) >> >> exit 1 >> >> ;; >> >> stop) >> >> exit 0 >> >> ;; >> >> esac >> >> fi >> >> fi >> > >> > Libraries, even shell libraries, should generally not call exit. It's >> > very surprising behavior. The overall program flow should remain under >> > the control of the main program. >> >> In general I agree, and I think this was one of points of including >> helper-free check in the policy & including a helper in the >> init-functions, which one can call as appropriate. >> >> Another fundamental question is: should direct invocation of >> /etc/init.d/ be outright deprecated? and thus even stronger >> safe-guards put in place (e.g. something at the scale of chmod -x >> /etc/init.d/*) >> or shall we allow people shooting themselves in the foot and allow >> init.d scripts not to have upstart-safeguard if a maintainer does not >> wish to include one? E.g. update-rc.d / incoke-rc.d >> / service works correctly with sysv-init & upstart, but if one invokes >> init.d scripts directly and they happen to be managed by upstart, >> leave those users on their own? At the moment policy is a must: "SysV >> init scripts for which an equivalent upstart job is available __must__ >> query the output of the..." > > I think printing out a noisy warning and allowing people to shoot themselves > in > the foot would be good. I reckon a significant number of legacy > (custom/proprietary) scripts currently attempt to poke /etc/init.d/foo > directly. > Perhaps allowing the sysadmin to choose the desired behaviour via debconf > would > do.. >
I'm not sure I understand you. > One point of concern that just occurred to me is that on an Upstart-booted, > running system that was just upgraded to include this init-functions snippet, > Upstart wouldn't know about init.d-started services, and wouldn't be able to > stop them. Additionally, due to the `exit 0' that occurs if [ $1 = stop ], you > wouldn't be able to stop the process using the traditional sysvinit script > either. You'd end up needing to kill the service manually or trawl through the > init script to figure out how to kill it properly. > Only if both are present: /etc/init/myservice.conf /etc/init.d/myservice The /etc/init.d/myservice, should exit/do nothing if and only if PID1 is upstart, since upstart is managing myservice via a native upstart job. If there is no equivalent upstart job (as I think is the case in your example above), the init.d script must continue to function correctly as per debian policy (including start/stop/restart). Thus the init-functions.d snippet above does a check of if upstart is PID1 and the '/etc/init/myservice.conf' exists, and only then adds the appropriate exit 1/0. And in the case of upstart-booted system it will indeed be managing "myservice". Are you talking about a case where a package is upgraded from sysv-init.d only to an upstart&sysv-init.d capable version? As per current recommendations, such services are stopped in preinst (cleanly via init.d script) & started in postinst (potentially by upstart). [1] Maybe I didn't understand the scenario you described. Can you please elaborate? [1] https://wiki.ubuntu.com/UpstartCompatibleInitScripts Regards, Dmitrijs. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/canbhlugvkssirjxadahg+bgycgtz1berqstyeyqkpyiub+m...@mail.gmail.com
