On Tue, 24 Jan 2017, Ryan Harper wrote: > On Tue, Jan 24, 2017 at 1:33 AM, Michael Felt <[email protected]> wrote: > > > So, if I now, more clearly understand the basics of 'generator' and > > http://cloudinit.readthedocs.io/en/latest/topics/boot.html > > I take this to mean cloud-init is always 'enabled' because the file > > /etc/cloud/cloud-init.disabled > > is only "valid" > > when (quote from docs) "When booting under systemd..." > > > > That's correct; more specifically, the various stage scripts don't > themselves check for things like the above file directly; they rely on the > generator > to enable or disable them as needed.
They don't now, but I don't think I'm opposed to having the sysvinit scripts do such checks. The real value of the generator in systemd, is that if it determines that cloud-init does not need to run, then there is no change in the systemd boot ordering to accommodate cloud-init. Since there isn't really a boot-time analog in sysvinit (to my knowledge), I'm fine to have the scripts do nothing if cloud-init is disabled via the mechanisms that would disable it in the generator. > For /etc/intitab, it's likely that you'll want to add such a check (which > can rely on the same file path for consistency) directly to the start > of each stage script. > > > > I don't think there is a direct equivalent in sysvinit; rather at > > install-time cloud-init packaging would have setup the symlinks in various > > rc.X directories (at least on Linux) > > > > Ah - "the plot thickens" - systemd 'generator' - generates the > > 'sysvinit-like' list of programs to run (i.e., the loop within /etc/rc.d/rc > > that finds and sorts all the scripts with 'S' as first letter, and then > > executes these scripts sequentially) > > > -- Mailing list: https://launchpad.net/~cloud-init Post to : [email protected] Unsubscribe : https://launchpad.net/~cloud-init More help : https://help.launchpad.net/ListHelp
