On Mon, Jul 29, 2024 at 9:33 AM Windl, Ulrich <u.wi...@ukr.de> wrote:
> Hi! > > > > I tried to use my first systemd timer, but failed: Either I don’t > understand it correctly, or there is a bug in systemd (228 of SLES12 SP5): > > (See also https://unix.stackexchange.com/q/779714/320598) > > > > It seems it’s not enough to “enable” the timer, but also “start” it (well, > it may seem logical from the systemd point of view, but from a cron user’s > point of view enabling should be enough) > "Start" is the primary action in systemd. Starting a .service runs it; starting a .mount mounts it; starting a .timer schedules it; starting a .socket listens on it. > Furthermore it seems to be necessary to run the service unit itself, too > (assuming it must be enabled also, right?) > No. The purpose of the timer is to start the service, so starting the service manually (or "enabling" it, to be started on boot) would be redundant. > But the biggest thing is that systemd seems to lose the point-in-time of > the last activation, so the timer won’t fire any more (e.g. after package > upgrade when everything enabled would be re-enabled, and everything started > would be re-started). > > But most of all if the system reboots, the timer also won’t fire any more. > > > > So can anybody explain how things should work? > > > > My expectation was that an OnUnitInactiveSec timer would fire immediately if > it never ran, and then every day from that. > > > > Kind regards, > > Ulrich > > > > > -- Mantas Mikulėnas
