> Nope. No simple way to run a single simple script on boot, which lived in /etc/rc.local for decades.
Have you tried?
At least on Debian and Ubuntu, if /etc/rc.local exists and is executable, systemd-rc-local-generator will auto-generate an rc-local.service unit that will run rc.local.
If the unit isn't visible for you, create an /etc/rc.local file. chmod +x it. Then run "sudo systemctl enable rc-local.service". Then try "systemctl status rc-local.service".
If your distro has the relevant generator, you'll see something with a line saying "Drop-In: [some path]". If so, "systemctl start rc-local" should run your /etc/rc.local, and/or it will run after reboot.
In other words, you can easily have /etc/rc.local running on boot.
On Debian and Ubuntu, you can do ls /usr/lib/systemd/system/rc* to see the compatibility options for SysV init that are available to you.
If your distro doesn't ship with an rc.local drop-in and generator, then put this in /etc/systemd/system/rc-local.service:
Then run "systemctl enable rc-local.service". Now, as long as /etc/rc.local is executable, it will be run on startup after your network has come up (you can change the "After" if you want to trigger it based on another condition instead)
> clear that cron, which served us perfectly well for decades is now cubersome and seriously lacking.
Cron is severely limited compared to systemd timers, but nothing stops you from also running a cron. I have anacron running on my systemd setup because I agree it serves a lot of needs perfectly well. It coexists just fine and lets me use a cron for the simple stuff, and systemd timers for things that requires conditions cron can't handle, such as e.g. advanced preconditions.
I believe that last time I tried, systemd had different semantics (no mask/unmask, etc), but memory might fail me here.
Thing is, I don't want to do any of those things. It is not looking healthy to me that a simple unix instance needs dancing around to execute /etc/rc.local. The only solution that looks sane to me is "if /etc/rc.local is present and executable - run it". Yeah, I can understand the security implications of that.
> but nothing stops you from also running a cron
For now. Apple already deprecated and banned cron from running on macOS instances in favor of their absolutely batshit insane launchd (which was the inspiration for systemd, hence the inherited brain damage).
Before long Ubuntu will ship with no cron installed and then just a bit later it won't even be available in packages. Not even as a rust rewrite.
Only if you're running a distro that lacks basic defaults from Systemd. Are you a distro like that? Have you tried just creating /etc/rc.local and seen if it gets executed?
It's not systemd's fault if your distro ships with a broken systemd install.
> "if /etc/rc.local is present and executable - run it". Yeah, I can understand the security implications of that.
That is indeed what happens if you're on a distro with a non-broken systemd install.
> Before long Ubuntu will ship with no cron installed and then just a bit later it won't even be available in packages. Not even as a rust rewrite.
> It's not systemd's fault if your distro ships with a broken systemd install
Technically yes. Realistically systemd fosters insane decisions like ssh socket activation or killing of cron by providing features. Useless, unnecessary, unwanted, unrequested features that solves no real problems.
Wait until they start from scratch by rewriting everything in Rust. This absolutely will happen one day.
We're never going to agree on this. I have plenty of issues with systemd, but as I've shown you, the rc.local support you claimed isn't there, is in fact there, and doesn't require you to do anything, and then the goal posts moved to pure fear over features you don't like and the hypothetical removal of things they have no control over.
Have you tried?
At least on Debian and Ubuntu, if /etc/rc.local exists and is executable, systemd-rc-local-generator will auto-generate an rc-local.service unit that will run rc.local.
If the unit isn't visible for you, create an /etc/rc.local file. chmod +x it. Then run "sudo systemctl enable rc-local.service". Then try "systemctl status rc-local.service".
If your distro has the relevant generator, you'll see something with a line saying "Drop-In: [some path]". If so, "systemctl start rc-local" should run your /etc/rc.local, and/or it will run after reboot.
In other words, you can easily have /etc/rc.local running on boot.
On Debian and Ubuntu, you can do ls /usr/lib/systemd/system/rc* to see the compatibility options for SysV init that are available to you.
If your distro doesn't ship with an rc.local drop-in and generator, then put this in /etc/systemd/system/rc-local.service:
```
```Then run "systemctl enable rc-local.service". Now, as long as /etc/rc.local is executable, it will be run on startup after your network has come up (you can change the "After" if you want to trigger it based on another condition instead)
> clear that cron, which served us perfectly well for decades is now cubersome and seriously lacking.
Cron is severely limited compared to systemd timers, but nothing stops you from also running a cron. I have anacron running on my systemd setup because I agree it serves a lot of needs perfectly well. It coexists just fine and lets me use a cron for the simple stuff, and systemd timers for things that requires conditions cron can't handle, such as e.g. advanced preconditions.