rc.local runs earlier than cloud-init.service

> Generally speaking people expect rc.local to be run as "the last thing in boot".

This can't be taken literally, as services can and do come and go (stop and start) all the time, and as any service can declare dependencies to run after "your thing" this can't be enforced either.

For example, could-final.service has an "After=rc-local.service" which I assume is deliberate. So we can't do a thing like "run rc-local.service after multi-user.target" as that would be an unresolvable ordering with cloud-final.service.

Thus I suggest to add an After=rc-local.service to cloud-init.service. This is explicit and unambiguous.

Martin,

I dont think your suggestion is correct solution. Independent of cloud-init, things in rc.local should be run as "the last thing in boot". rc.local came from a simpler time. sysvinit ran rc.local as the last thing, and that was that last thing that would run.

Many people will do:
 a.) install Ubuntu
 b.) add some script to /usr/local/bin
 c.) add /usr/local/bin/myscript to /etc/rc.local
and expect that their script will run "at the end of boot"

It may be simplistic, but it is extremely useful and many users expect that functionality.

Breaking this expectation and functionality is not helpful. upstart successfully maintained a useful resemblance to the original rc.local functionality. I personally would expect systemd to also.

> Independent of cloud-init, things in rc.local should be run as "the last thing in boot".

So now we have "last thing except cloud-init" :-) There are other services which order themselves after it, like getty@, plymouth-quit and others, to avoid disturbing init.d/rc.local scripts with allocated VTs or plymouth going away. This was more or less the same case with upstart.

But nevertheless it should run at least after the init.d scripts (and their unit counterparts), to maintain backwards compatibility with that. This still isn't robust (if you need to run after something it's always correct to actually declare it), but might help in some situations.

A simple fix is something like this:

Create the /etc/systemd/system/rc-local.service file with the following contents:

[Unit]
Description=/etc/rc.local Compatibility

[Service]
Type=idle
ExecStart=/etc/rc.systemd
TimeoutSec=0
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Create a file /etc/rc.systemd with whatever you want to run, set it to executable.
Delete everything you added from rc.local until this gets properly fixed

run systemctl daemon-reload

Reboot to test it.

Working for me at the moment

Tiago, your service file has even weaker dependencies like the standard rc-local.service, so it'll run even earlier. It's not good advice to create blanket "wrappers" around shell scripts without specifying any dependency.

As I explained, the notion of "the last thing during boot" is not well-defined with a partially ordered and parallel init system like systemd or upstart (or even sysvinit+startpar).

So as long as cloud-init.service declares itself to run after rc-local.service, then rc-local.service necessarily can't be "the" last thing even accidentally. This is something to decide in cloud-init.service.

> So as long as cloud-init.service declares itself to run after rc-local.service

Sorry, I meant cloud-final.service.

>the notion of "the last thing during boot" is not well-defined with a partially ordered and parallel init system like systemd or upstart (or even sysvinit+startpar).

systemd needs to be fixed then.
because rc.local worked well with upstart.

Please see comment #7 -- cloud-final.service declares to run *after* rc-local.service. Thus it is not possible that rc-local.service "runs last" as that would be a contradiction to what cloud-final wants and says. There is nothing to "fix" and this was no different in upstart either -- if something said "start on started rc-local" (the upstart equivalent) it would of course run after /etc/init/rc-local as well.

Please give up on "the last thing" -- this concept hasn't existed in upstart and systemd, and hasn't existed any more in SysV init with startpar either for many years now.

I'm closing this as "Won't Fix" for cloud-init now as this behavior has been established and now expected.