Re: [systemd-devel] systemd unit timer

[Lennart Poettering]

On Mo, 10.08.20 20:19, Dave Howorth (syst...@howorth.org.uk) wrote:

> > It kinda makes sense to invoke cronjobs the same way as any other
> > piece of system code in userspace: as a service, so that you can take
> > benefit of deps management, priv handling, logging, sandboxing and so
> > on, so that you can run stuff either manually or by timers or by any
> > other kind of activation, and so on, and it always ends up in exactly
> > one instance. And there's tons of other stuff too.
> >
> > i.e. it unifies how system programs are invoked, and that's a good
> > thing. it turns time-based activation into "just another type of
> > activation".
>
> Most of that has gone over my head so some examples would probably help
> me to understand. Perhaps they're in the git logs?
>
> But I'm not normally running system code in cronjobs. I usually run
> either scripts I have written myself, or backup commands and the
> like.

Well, by "system code" in this context I mean code running in system
code, i.e. not associated with a specific "human" user. i.e. all code
traditionally run from /etc/crontab and related dirs is in "system
context".

> If I wanted to run a service, presumably I could just write a 'manual'
> invocation as a cron or at job? I'm not seeing the big imperative to
> create another new bunch of code to learn and maintain. I expect I'm
> blind.

I mean, you don't have to use systemd timers+services, that's entirely
up to you. cron continues to work after all.

However, there's a ton of stuff in it for you if you do bother running
stuff as timer. For example, let's say you wrote your own backup
script, that streams your whole OS backup to some server. Stuff like
that you want resource manage a bit, i.e. use CPUShares=100 or so to
make sure it doesn't take as much resources. You want to lock it down,
since it's interacting with the netwokr, and it's bad enough it needs
to be able to read all your files, but it sure as hell shouldn't also
be able to change them, so you could lock it down with ProtectSystem=
and so on. And sometimes you want to start a backup manually, outside
of your usual schedule, so there's "systemctl start" of the backup
script to do so in a way that won't conflict if the schedule hits
while the backup is still running. Then, maybe you need some service
to be up while you are doing your backup (or a mount), and it might be
used by something else too, but should go away when not used. You can
pull it in cleanly from your timer's service now, and mark it
StopWhenUnneeded= so that it goes away when no service uses it. And so
on and so on.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd unit timer

[Uoti Urpala]

On Mon, 2020-08-10 at 20:19 +0100, Dave Howorth wrote:
> On Mon, 10 Aug 2020 20:21:51 +0200
> Lennart Poettering  wrote:
> > i.e. it unifies how system programs are invoked, and that's a good
> > thing. it turns time-based activation into "just another type of
> > activation".
> 
> Most of that has gone over my head so some examples would probably help
> me to understand. Perhaps they're in the git logs?
> 
> But I'm not normally running system code in cronjobs. I usually run
> either scripts I have written myself, or backup commands and the like.

Even many of the simplest scripts will most likely benefit from basic
systemd unit functionality like having correct journal metadata
("something logged from foo.service" as opposed to "something logged
from (child process of) cron.service").


> If I wanted to run a service, presumably I could just write a 'manual'
> invocation as a cron or at job? I'm not seeing the big imperative to
> create another new bunch of code to learn and maintain. I expect I'm
> blind.

You can view "running code at a specified time" as having two parts:
choosing the time when to start it, and the general ability to run code
in a specified environment (user, sandboxing, resource limits,
dependencies, etc). Cron does the first, but systemd units do the
second a lot better. If you want to have support for both, you either
need to add most of the stuff in systemd units to cron, or timer units
to systemd. The second is a much saner option.

Basically, you want to have support for everything in unit files also
for code that is started based on time. This means that having cron
directly running code is not a real option. And having cron running
"systemctl start" commands is kludgey and has enough problems to
justify native timer units.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd unit timer

[Kenneth Porter]

On 8/10/2020 12:19 PM, Dave Howorth wrote:

Most of that has gone over my head so some examples would probably help
me to understand. Perhaps they're in the git logs?


The key word is "activation". Modern systems are event-driven. Events 
include hardware plugging in, powering up, another program starting, or 
a point on the calendar. systemd launches programs when events happen. 
That's activation. In the past, activation was handled by lots of 
independent subsystems (initscripts, xinetd, cron) and they had the 
potential to conflict. Now it's all handled in one place and one way. 
Which eliminates a lot of duplication of effort. It means you don't need 
to fix the same bug in multiple subsystems.




___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd unit timer

[Dave Howorth]

On Mon, 10 Aug 2020 20:21:51 +0200
Lennart Poettering  wrote:
> On So, 09.08.20 15:56, Dave Howorth (syst...@howorth.org.uk) wrote:
> 
> > Is there anywhere that explains the rationale for systemd timers?  
> 
> Probably somewhere in the git logs.

Thanks, Lennart. I'll happily poke through the logs to try to find it,
but I've no idea where to start. A starting point URL for the logs would
be helpful to me.
 
> > What's their USP? Why was it necessary to invent the facility?  
> 
> It kinda makes sense to invoke cronjobs the same way as any other
> piece of system code in userspace: as a service, so that you can take
> benefit of deps management, priv handling, logging, sandboxing and so
> on, so that you can run stuff either manually or by timers or by any
> other kind of activation, and so on, and it always ends up in exactly
> one instance. And there's tons of other stuff too.
> 
> i.e. it unifies how system programs are invoked, and that's a good
> thing. it turns time-based activation into "just another type of
> activation".

Most of that has gone over my head so some examples would probably help
me to understand. Perhaps they're in the git logs?

But I'm not normally running system code in cronjobs. I usually run
either scripts I have written myself, or backup commands and the like.

If I wanted to run a service, presumably I could just write a 'manual'
invocation as a cron or at job? I'm not seeing the big imperative to
create another new bunch of code to learn and maintain. I expect I'm
blind.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd unit timer

[Lennart Poettering]

On So, 09.08.20 00:20, Vini Harimoorthy (vini6...@gmail.com) wrote:

> Hi Team,
>
>
> Is there a way to specify the "start  date & time" of the timer unit with
> calendar timer  ?
>
> For example, the below timer units runs every weekly from the service is
> activated.My requirement is that I need to run the timer unit only after
> the 10th month i.e."2020-10-1"

We currently have no nice mechanism for that. You can hack something up
though: define three timer units: the first one runs the service the
first time, the second one starts it then regularly. And  the third
one then stops the second one.

e.g.

first-start.timer:
[Timer]
OnCalendar=2020-10-1
Unit=myservice.service

regular-start.timer:
[Timer]
OnCalendar=weekly
Unit=myservice.service

myservice.service:
[Unit]
Wants=regular-start.timer final.timer

[Service]
…

final.timer
[Timer]
OnCalendar=2021-8-1
Unit=stop-final.service

stop-final.service
[Service]
ExecStart=/usr/bin/systemctl --no-block stop final.timer
Type=oneshot

Or something like that. You get the idea.

That said, I think adding a new concept of NotBefore= and NotAfter= to
.timer units would make a ton of sense. Please file an RFE issue on
github asking for this to be added. With a concept like this we could
then just have a new syntax:

 [Timer]
 NotBefore=2020-10-1
 NotAfter=2021-8-1
 OnCalendar=weekly

I think such an addition would make a ton of sense.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd unit timer

[Lennart Poettering]

On So, 09.08.20 15:56, Dave Howorth (syst...@howorth.org.uk) wrote:

> Is there anywhere that explains the rationale for systemd timers?

Probably somewhere in the git logs.

> What's their USP? Why was it necessary to invent the facility?

It kinda makes sense to invoke cronjobs the same way as any other
piece of system code in userspace: as a service, so that you can take
benefit of deps management, priv handling, logging, sandboxing and so
on, so that you can run stuff either manually or by timers or by any
other kind of activation, and so on, and it always ends up in exactly
one instance. And there's tons of other stuff too.

i.e. it unifies how system programs are invoked, and that's a good
thing. it turns time-based activation into "just another type of activation".

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd unit timer

[Tom Ryder]

On Sun, Aug 09, 2020 at 06:42:36PM +0200, Jérémy ROSEN wrote:

You could create a timer that starts another timer...


Or something like an `at` job:

$ sudo at 'midnight 2021-01-01'
at> systemctl enable myservice.timer
at> systemctl start myservice.timer
at> 
job 1 at Fri Jan 1 00:00:00 2021

--
Tom Ryder 
Maybe we can bring back the light.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd unit timer

[Dave Howorth]

Sorry Jérémy ROSEN had munged the headers so a reply went only to
him :( :(

Here's a copy for the list.


Begin forwarded message:

Date: Sun, 9 Aug 2020 20:16:19 +0100
From: Dave Howorth 
To: Jérémy ROSEN 
Subject: Re: [systemd-devel] systemd unit timer


On Sun, 9 Aug 2020 18:42:36 +0200
Jérémy ROSEN  wrote:
> You could create a timer that starts another timer...  

Sorry, are you answering my question? (Top-posting makes it difficult
to understand without context)

If so, why might I want to do that and why couldn't I do it using cron?

If you're answering the OP's question then perhaps make that clear, but
again why couldn't that be done using cron?

Why invent yet another mechanism?

> Le dim. 9 août 2020 à 16:56, Dave Howorth  a
> écrit :
>   
> > On Sun, 9 Aug 2020 15:54:55 +0300
> > Andrei Borzenkov  wrote:
> > > 09.08.2020 13:40, Vini Harimoorthy пишет:
> > > > In that case, it will run only in Oct,Nov, & Dec. But, I want to
> > > > run the timer unit weekly after a specific calendar date & time.
> > > > How to specify if I want to run some task on every 12 hours
> > > > after Jan'2021 (start from future date & time)
> > > >
> > >
> > > That's not possible using systemd timer as of now. There was
> > > similar discussion just recently (a week or two ago).
> >
> > Is there anywhere that explains the rationale for systemd timers?
> >
> > What's their USP? Why was it necessary to invent the facility?
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> >
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd unit timer

[Jérémy ROSEN]

You could create a timer that starts another timer...


Le dim. 9 août 2020 à 16:56, Dave Howorth  a écrit :

> On Sun, 9 Aug 2020 15:54:55 +0300
> Andrei Borzenkov  wrote:
> > 09.08.2020 13:40, Vini Harimoorthy пишет:
> > > In that case, it will run only in Oct,Nov, & Dec. But, I want to
> > > run the timer unit weekly after a specific calendar date & time.
> > > How to specify if I want to run some task on every 12 hours after
> > > Jan'2021 (start from future date & time)
> > >
> >
> > That's not possible using systemd timer as of now. There was similar
> > discussion just recently (a week or two ago).
>
> Is there anywhere that explains the rationale for systemd timers?
>
> What's their USP? Why was it necessary to invent the facility?
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd unit timer

[Dave Howorth]

On Sun, 9 Aug 2020 15:54:55 +0300
Andrei Borzenkov  wrote:
> 09.08.2020 13:40, Vini Harimoorthy пишет:
> > In that case, it will run only in Oct,Nov, & Dec. But, I want to
> > run the timer unit weekly after a specific calendar date & time.
> > How to specify if I want to run some task on every 12 hours after
> > Jan'2021 (start from future date & time)
> >   
> 
> That's not possible using systemd timer as of now. There was similar
> discussion just recently (a week or two ago).

Is there anywhere that explains the rationale for systemd timers?

What's their USP? Why was it necessary to invent the facility?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd unit timer

[Andrei Borzenkov]

09.08.2020 13:40, Vini Harimoorthy пишет:
> In that case, it will run only in Oct,Nov, & Dec. But, I want to run the
> timer unit weekly after a specific calendar date & time.
> How to specify if I want to run some task on every 12 hours after Jan'2021
> (start from future date & time)
> 

That's not possible using systemd timer as of now. There was similar
discussion just recently (a week or two ago).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd unit timer

[Vini Harimoorthy]

In that case, it will run only in Oct,Nov, & Dec. But, I want to run the
timer unit weekly after a specific calendar date & time.
How to specify if I want to run some task on every 12 hours after Jan'2021
(start from future date & time)

Are the below requirements possible with a systemd timer ?

Let say, Current  date & time is :   2020-08-09 12:00:00
1) Run the task  every 1 hr starting from tomorrow
2) Run the task every 1 hr after  2020-08-09 15:00:00
3) Run the task on 2nd & 3rd day of the month after 2020-10-01

Basically, I want to specify the future time as start time of the timer
unit and the other specifications mentioned in onCalender has to be
executed after the start time


Thanks,
Vinitha

On Sun, Aug 9, 2020 at 1:34 PM Ronnie Thomas  wrote:

>
> On Sun, Aug 9, 2020 at 12:20 AM Vini Harimoorthy 
> wrote:
>
>> Hi Team,
>>
>>
>> Is there a way to specify the "start  date & time" of the timer unit with
>> calendar timer  ?
>>
>> For example, the below timer units runs every weekly from the service is
>> activated.My requirement is that I need to run the timer unit only after
>> the 10th month i.e."2020-10-1"
>>
>> [Unit]
>> Description=Run foo weekly
>>
>> [Timer]
>> OnCalendar=weekly
>> Persistent=true
>>
>> [Install]
>> WantedBy=timers.target
>>
>>
>>
> The "weekly" expression is just a shorthand for "Mon *-*-* 00:00:00". So,
> instead of
> using weekly, you could explicitly specify October, November and December
> in your
> OnCalendar= statement.  i.e
>
> OnCalendar=Mon *-10,11,12-* 00:00:00
>
> Regards,
> Ronnie P. Thomas
>
>


-- 
*Regards,*
*Vinitha H*
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd unit timer

[Ronnie Thomas]

On Sun, Aug 9, 2020 at 12:20 AM Vini Harimoorthy  wrote:

> Hi Team,
>
>
> Is there a way to specify the "start  date & time" of the timer unit with
> calendar timer  ?
>
> For example, the below timer units runs every weekly from the service is
> activated.My requirement is that I need to run the timer unit only after
> the 10th month i.e."2020-10-1"
>
> [Unit]
> Description=Run foo weekly
>
> [Timer]
> OnCalendar=weekly
> Persistent=true
>
> [Install]
> WantedBy=timers.target
>
>
>
The "weekly" expression is just a shorthand for "Mon *-*-* 00:00:00". So,
instead of
using weekly, you could explicitly specify October, November and December
in your
OnCalendar= statement.  i.e

OnCalendar=Mon *-10,11,12-* 00:00:00

Regards,
Ronnie P. Thomas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd unit timer

[Vini Harimoorthy]

Hi Team,


Is there a way to specify the "start  date & time" of the timer unit with
calendar timer  ?

For example, the below timer units runs every weekly from the service is
activated.My requirement is that I need to run the timer unit only after
the 10th month i.e."2020-10-1"

[Unit]
Description=Run foo weekly

[Timer]
OnCalendar=weekly
Persistent=true

[Install]
WantedBy=timers.target


-- 
*Regards,*
*Vinitha H*
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel