3 ms·

> you can adopt systemd without losing functionality Nope. No simple way to run a single simple script on boot, which lived in /etc/rc.local for decades. Creat

> you can adopt systemd without losing functionality Nope. No simple way to run a single simple script on boot, which lived in /etc/rc.local for decades. Create a unit instead. It's not much but systemd is full of little annoyances like this one. > [] offering useful additional capabilities without taking away the old. Once they introduce capabilities, the old quickly becomes irrelevant due to sheer mass of systemd crowd. After they have introduced timers, it suddenly became clear that cron, which served us perfectly well for decades is now cubersome and seriously lacking. The same can be said about syslog/journald drama. Now they decided they want sudo replaced. Up next: something else that you cannot even think of, is already on their radar.

vidarh 1y ago
> 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: ``` [Unit] Description=/etc/rc.local compatibility ConditionFileIsExecutable=/etc/rc.local After=network.target [Service] Type=forking ExecStart=/etc/rc.local start TimeoutSec=0 RemainAfterExit=yes GuessMainPID=no StandardOutput=journal+console StandardError=journal+console ``` 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.
- egorfine 1y ago
  > Have you tried? Then: > Then run [...] Then try [...] 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.
  - vidarh 1y ago
    >> Then: 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. Then don't use Ubuntu. Still not systemd's fault.
    - egorfine 1y ago
      > 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.
      - vidarh 1y ago

vidarh 1y ago

> 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: ``` [Unit] Description=/etc/rc.local compatibility ConditionFileIsExecutable=/etc/rc.local After=network.target [Service] Type=forking ExecStart=/etc/rc.local start TimeoutSec=0 RemainAfterExit=yes GuessMainPID=no StandardOutput=journal+console StandardError=journal+console ``` 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.

egorfine 1y ago
> Have you tried? Then: > Then run [...] Then try [...] 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.
- vidarh 1y ago
  >> Then: 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. Then don't use Ubuntu. Still not systemd's fault.
  - egorfine 1y ago
    > 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.
    - vidarh 1y ago