[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#225465: debian-policy: packages must give choice to notstart at boot, via debconf



Hi John,

John Hasler wrote:
I wrote:

Try:
. /etc/default/package # this contains "RUN_package_AT_BOOT" test -z "$RUN_package_AT_BOOT" && echo $0 | grep -q '^S' && exit 0


Joel writes:

hmm I try also try this example but failed to me


It should read:
test -z "$RUN_package_AT_BOOT" && echo $(basename $0) | grep -q '^S' && exit 0

Ah ok I better understand ;)

It was just an untested example fragment.  The idea is to check to see if
the script is being called via one of the sysvinit 'S' symlinks.  This lets
you call '/etc/init.d/$PACKAGE' from the command line even if
/etc/default/package is set to prevent startup at boot.
Yes we share the same idea :)

 It doesn't fix the
problem of daemons being started on reinstallation, though.

hmm in general (at least for an upgrade) the install process check if the file exists and ask for the action to take?


Now I not quite sure how startup scripts are launched: I mean if
/etc/rci.d is added in the PATH then ok "echo $0 | grep -q '^S'" would
work OTC not?


I don't understand what you are asking.

The actual question was actualy:
if the process was launch by /etc/rci.d/Siipackage then "echo $0" never start by S.
But you answer above ( $(basename $0) )

Its major inconvience: not applicable for all shell


If you disable all the K links the daemon won't be shut down properly on
halt or reboot and won't be stopped when entering init 1.
Well see, thanks

 I also don't see
why the absence of StartCfgFile should completely disable the script.

just usefull to avoid any restart (an action of a collegue who ignores that you are working on a pkg, ...):
rename /etc/default/$PACKAGE into /etc/default/$PACKAGE.sav

I also put it outside the context of manual or automatic startup because it could also contains some other interesting parameter (the number of process to start, ...)

Thanks for your remarks and attention,
	Joel



Reply to: