timerĬreated symlink /etc/systemd/system//uptime-limiter.timer → /etc/systemd/system/uptime-limiter.timer. The timer service as /etc/systemd/system/uptime-limiter.timer, in this case allows for 6 hours of uptime (plus the extra 5 minutes given by the main service): ĭescription=Timer for Limit uptime serviceĪnd enable it: # systemctl enable uptime-limiter. So the way to ensure that the shutdown command is respected is to trigger it off with a timer service. I should mention that adding After=multi-user.target in the unit file didn’t help. Most likely because systemd somehow cancels pending shutdown requests when it reaches the ultimate target. Well, it does work when started manually, but when this service starts as part of the system bringup, the shutdown request is registered but later ignored. The naïve approach is to just enable the service and expect it to work. So the main service is this file as /etc/systemd/system/rvice: ĮxecStart=/sbin/shutdown -h +5 "System it taken down by rvice" I went for two services: One that calls /sbin/shutdown with a five minute delay (so I get a chance to cancel it) and then second is a timer for the uptime limit. The examples here are based upon systemd 241 on Debian GNU/Linux 10. So this is the cloud computing parallel to “did I lock the door?”. And sane cloud provider does that except for, possibly, costs for storing the VM’s disk image. Just make sure that a shutdown by the machine itself accounts for cutting the costs. And if the intended use is short sessions anyhow, make sure that the machine shuts down by itself after a given amount of time. I don’t want to forget one of those running, just to get a fat bill at the end of the month. This post was written by eli on January 31, 2021
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |