[opensuse-factory] questions about systemd timers
Bug https://bugzilla.novell.com/show_bug.cgi?id=913421 made me aware that in my factory installation logrotate is also not running. I applied the workaround as described in the bugreport and I have the impression a systemd timer configured as OnCalendar=daily ist started exactly and only at midnight. Is this correct, I could not find documentation about this? The "daily" functionality of cron is quite different, so this could cause a lot of things no longer working as expected when services are migrated if not documented properly. Additional question: if a *.timer configuration file is changed or a local configuration is created, how to trigger systemd to re-read this changed configuration? After "systemctl dameon-reload" "systemctl list-timers" still showed the original schedule of timer execution. Only after a reboot the new values were used. I also found no documentation for this. Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Bug https://bugzilla.novell.com/show_bug.cgi?id=913421 made me aware that in my factory installation logrotate is also not running. I applied the workaround as described in the bugreport and I have the impression a systemd timer configured as OnCalendar=daily ist started exactly and only at midnight. Is this correct, I could not find documentation about this?
I just found systemd.time(7) which clarifies: daily -> *-*-* 00:00:00 This is probably not the desired replacement for cron.daily. Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, 18 Jan 2015 14:08, dieter <d_werner@...> wrote:
Bug https://bugzilla.novell.com/show_bug.cgi?id=913421 made me aware that in my factory installation logrotate is also not running. I applied the workaround as described in the bugreport and I have the impression a systemd timer configured as OnCalendar=daily ist started exactly and only at midnight. Is this correct, I could not find documentation about this?
I just found systemd.time(7) which clarifies: daily -> *-*-* 00:00:00
This is probably not the desired replacement for cron.daily.
Dieter
The 'original' crontab entry for the suse implemented 'run-crons' (running of cron.{hourly,daily,weekly,monthly,yearly}) was this line: [code] -*/15 * * * * root test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1 [/code] /usr/lib/cron/run-crons contains the logic to make sure calls are done, even when the machine was off at the 'normal' calling time. IMHO we should keep the calls to that, and just move the 'caller' from cron to systemd.timers the wanted line for that *.timer-unit-file would be: [code] # run every quarter hour. OnCalendar=*-*-* *:00,15,30,45:00 [/code] - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 18/01/15 a las 10:41, Yamaban escribió:
/usr/lib/cron/run-crons contains the logic to make sure calls are done, even when the machine was off at the 'normal' calling time.
Yes and this logic also exists in timers, the unit I wrote had "Persistent=true" but someone commented it..because it was not a supported option at the time (not implemented in systemd 210) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Cristian Rodríguez <crrodriguez@opensuse.org> [01-18-15 09:08]:
El 18/01/15 a las 10:41, Yamaban escribió:
/usr/lib/cron/run-crons contains the logic to make sure calls are done, even when the machine was off at the 'normal' calling time.
Yes and this logic also exists in timers, the unit I wrote had "Persistent=true" but someone commented it..because it was not a supported option at the time (not implemented in systemd 210)
But systemd 210 is what Tumbleweed has. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 18/01/15 a las 11:19, Patrick Shanahan escribió:
But systemd 210 is what Tumbleweed has.
It was recently updated to a newer version but it still not in yet. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, 18 Jan 2015 15:06, Cristian Rodríguez <crrodriguez@...> wrote:
El 18/01/15 a las 10:41, Yamaban escribió:
/usr/lib/cron/run-crons contains the logic to make sure calls are done, even when the machine was off at the 'normal' calling time.
Yes and this logic also exists in timers, the unit I wrote had "Persistent=true" but someone commented it..because it was not a supported option at the time (not implemented in systemd 210)
That would mean: - Either SLE12 gets a newer systemd that supports "Persistent=true", or - We will have to depend on /usr/lib/cron/run-crons for the whole SLE12 support period. Choose your poison. Nice. (Urgs, that decision will involve more politics than reason) IMHO, using /usr/lib/cron/run-crons for SLE12 is less work, and has no known errors (so far). For OSS.next (Factory / Tumbleweed) the binding point is the support of "Persistent=true" in systemd. Before that is secured, /usr/lib/cron/run-crons is the only valid and user friendly way to go. Whether it is called from cron or from systemd *.timer unit that is an other matter. Question, is there a "replacement" for the "at" command? I mean a front-end for systemd.timers, usable like the "at" command. -- Or could that be a idea for a GSOC mini-project (entry level, shell/perl/python script + man.page)? - Yamaban.
В Sun, 18 Jan 2015 15:34:03 +0100 (CET) Yamaban <foerster@lisas.de> пишет:
Question, is there a "replacement" for the "at" command?
commit 4c213d6cf416917c61f82d8bee795b8f3a4c5372 Author: WaLyong Cho <walyong.cho@samsung.com> Date: Tue Dec 9 16:07:16 2014 +0900 run: introduce timer support option -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, 18 Jan 2015 16:01, Andrei Borzenkov wrote:
В Sun, 18 Jan 2015 15:34:03 +0100 (CET) Yamaban пишет:
Question, is there a "replacement" for the "at" command?
commit 4c213d6cf416917c61f82d8bee795b8f3a4c5372 Author: WaLyong Cho <walyong.cho@samsung.com> Date: Tue Dec 9 16:07:16 2014 +0900
run: introduce timer support option
Thanks for the info, full message @ systemd-commits-list: http://lists.freedesktop.org/archives/systemd-commits/2014-December/007634.h... Now all that is missing, (and that is what I meant) is a wrapper-script to emulate the "at(1)" command and thus rising the acceptance of systemd-run(2), a drop-in replacement, same call, same parameters. (1) http://linux.die.net/man/1/at (2) http://www.freedesktop.org/software/systemd/man/systemd-run.html Be aware, (2) reflects systemd version 218 atm. Factory / Tumbleweed are on version 210 atm. 210 was taken in "Mon Mar 3 13:58:11 UTC 2014 - werner@..." (see systemd.changes) 218 is in some "home" projects, e.g. home:jengelh, where it succeeds for OSS13.2 and Factory. After it makes its way into Base:System and then Factory, maybe enabling a build for SLE12 and testing for regressions there would be the best for the long term solution on the cron.{hourly,daily,weekly,monthly,yearly} situation. - Yamaban.
Additional question: if a *.timer configuration file is changed or a local configuration is created, how to trigger systemd to re-read this changed configuration?
The answer for this seems to be: after changing the *.timer configuration stop/disable and enable/start the timer to run with the new settings. Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Sun, 18 Jan 2015 17:43:20 +0100 dieter <d_werner@gmx.net> пишет:
Additional question: if a *.timer configuration file is changed or a local configuration is created, how to trigger systemd to re-read this changed configuration?
The answer for this seems to be: after changing the *.timer configuration stop/disable and enable/start the timer to run with the new settings.
Small correction. systemd only reads updated configuration from disk when you do "systemctl daemon-reload" (or restart systemd with e.g. daemon-reexec). "systemctl enable ..." will implicitly perform daemon-reload unless used with --no-reload. This can be used to optimize bulk changes by using several "systemctl enable --no-reload ..." followed by single "systemctl daemon-reload". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Andrei Borzenkov -
Cristian Rodríguez -
dieter -
Patrick Shanahan -
Yamaban