On Tue, 12 Jul 2016, Stefan Monnier wrote: > >> I often need something like this when running inside a chroot and > >> always have trouble finding the clean&easy way to do it > > Here's one example that mk-sbuild uses: > > (jessie-amd64)$ cat /usr/sbin/policy-rc.d > > #!/bin/sh > > while true; do > > case "$1" in > > -*) shift ;; > > makedev) exit 0;; > > x11-common) exit 0;; > > *) exit 101;; > > esac > > done > > Pretty far from my ideal of having some boolean setting under /etc somewhere.
You could potentially just use the policyrcd-script-zg2 package, and then your boolean setting would be: echo -e "#!/bin/sh\nexit101;" > /etc/policy-rc.d. Or something similar. [Or if you really just want a boolean, you could potentially write your own package which plugged into policy-rc.d which just checked if /etc/no_daemons or something existed to determine whether it should exit 101 or not; you could possibly even figure out if you were running under dpkg, and just block starting/restarting daemons during package install/remove time.] > It's actually worse: in some of my chroots (such as LilDebi's) I do > want daemons to be started&stopped, while in others (typically when I > mount some external disk that holds some other machine's (broken) root > filesystem, in order to fix it) I don't. > > So even if we could reliably identify that we're in a chroot jail, it > wouldn't tell us whether daemons should be started/stopped. Yep. This problem is exactly why the policy-rc.d framework exists; it's way too difficult to figure out in what circumstances which daemons should be started/stopped. Chroot-specific configuration is pretty much the only way. [Or, using systemd, which handles things slightly more elegantly using systemctl enable|disable.] -- Don Armstrong https://www.donarmstrong.com -tommorow is our permanent address and there they'll scarcely find us(if they do, we'll move away still further:into now -- e.e. cummings "XXXIX" _1 x 1_
