Re: [systemd-devel] Question about OnUnitInactiveSec= directive

2016-07-08 Thread Andrei Borzenkov
09.07.2016 01:37, Mikhail Kasimov пишет:
> Hello!
> 
> Have a .timer service like:
> 
> ==
> 
> [Unit]
> Description=Runs VBA32 Update Hourly
> Requires=timers.target
> 
> [Timer]
> OnBootSec=2min
> OnUnitInactiveSec=1h
> 
> [Install]
> WantedBy=timers.target
> 
> ==
> 
> to run vba32update.service in 1 hour after previous update-session is
> over (OnUnitInactiveSec=1h).
> 
> From man-page: "|OnUnitInactiveSec=| defines a timer relative to when
> the unit the timer is activating was last deactivated."
> 
> Ok, here is log-snippet:
> ==
> Июл 08 22:05:00 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update
> Service...
> Июл 08 22:05:00 linux-mk500 vbacl[14768]: Vba32 console scanner update
> process started
> Июл 08 22:05:00 linux-mk500 vbacl[14768]: Reading configuration options
> from ./vbacl.ini
> Июл 08 22:05:00 linux-mk500 vbacl[14768]: Using direct connection for
> update
> Июл 08 22:05:02 linux-mk500 vbacl[14768]: Current dir is ./
> Июл 08 22:05:02 linux-mk500 vbacl[14768]: Start update from
> http://anti-virus.by/update
> Июл 08 22:05:02 linux-mk500 vbacl[14768]: Receiving file list
> Июл 08 22:05:02 linux-mk500 vbacl[14768]: File list received
> Июл 08 22:05:02 linux-mk500 vbacl[14768]: Update is not needed
> Июл 08 22:05:02 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update
> Service.
> 
...

> 
> We see 22:05:02 (end of update-session) --> 23:05:13 (start of next
> update-session) --> 23:05:17 (end of update-session) --> 00:05:20 (start
> of next update-session) --> 00:05:24 (end of update-session) -->
> 01:05:50 (start of next update-session) --> 01:05:55 (end of
> update-session).
> 
> Question: Why time of new update-session is *not* equal to time of end
> of previous update-session + 1h in section of seconds, e.g. 23:05:17 +1h
> = 00:05:17; 00:05:24 + 1h = 01:05:24 and so on? Is here a way to reach
> this precise coincidence?
> 

Please check with "systemctl status" or "systemctl show" when unit was
actually deactivated. Also see "AccuracySec" timer parameter.

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


[systemd-devel] Question about OnUnitInactiveSec= directive

2016-07-08 Thread Mikhail Kasimov

Hello!

Have a .timer service like:

==

[Unit]
Description=Runs VBA32 Update Hourly
Requires=timers.target

[Timer]
OnBootSec=2min
OnUnitInactiveSec=1h

[Install]
WantedBy=timers.target

==

to run vba32update.service in 1 hour after previous update-session is 
over (OnUnitInactiveSec=1h).


From man-page: "|OnUnitInactiveSec=| defines a timer relative to when 
the unit the timer is activating was last deactivated."


Ok, here is log-snippet:
==
Июл 08 22:05:00 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update 
Service...
Июл 08 22:05:00 linux-mk500 vbacl[14768]: Vba32 console scanner update 
process started
Июл 08 22:05:00 linux-mk500 vbacl[14768]: Reading configuration options 
from ./vbacl.ini

Июл 08 22:05:00 linux-mk500 vbacl[14768]: Using direct connection for update
Июл 08 22:05:02 linux-mk500 vbacl[14768]: Current dir is ./
Июл 08 22:05:02 linux-mk500 vbacl[14768]: Start update from 
http://anti-virus.by/update

Июл 08 22:05:02 linux-mk500 vbacl[14768]: Receiving file list
Июл 08 22:05:02 linux-mk500 vbacl[14768]: File list received
Июл 08 22:05:02 linux-mk500 vbacl[14768]: Update is not needed
Июл 08 22:05:02 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update 
Service.


Июл 08 23:05:13 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update 
Service...
Июл 08 23:05:13 linux-mk500 vbacl[15289]: Vba32 console scanner update 
process started
Июл 08 23:05:13 linux-mk500 vbacl[15289]: Reading configuration options 
from ./vbacl.ini

Июл 08 23:05:13 linux-mk500 vbacl[15289]: Using direct connection for update
Июл 08 23:05:17 linux-mk500 vbacl[15289]: Current dir is ./
Июл 08 23:05:17 linux-mk500 vbacl[15289]: Start update from 
http://anti-virus.by/update

Июл 08 23:05:17 linux-mk500 vbacl[15289]: Receiving file list
Июл 08 23:05:17 linux-mk500 vbacl[15289]: File list received
Июл 08 23:05:17 linux-mk500 vbacl[15289]: Update is not needed
Июл 08 23:05:17 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update 
Service.


Июл 09 00:05:20 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update 
Service...
Июл 09 00:05:20 linux-mk500 vbacl[16050]: Vba32 console scanner update 
process started
Июл 09 00:05:20 linux-mk500 vbacl[16050]: Reading configuration options 
from ./vbacl.ini

Июл 09 00:05:20 linux-mk500 vbacl[16050]: Using direct connection for update
Июл 09 00:05:24 linux-mk500 vbacl[16050]: Current dir is ./
Июл 09 00:05:24 linux-mk500 vbacl[16050]: Start update from 
http://anti-virus.by/update

Июл 09 00:05:24 linux-mk500 vbacl[16050]: Receiving file list
Июл 09 00:05:24 linux-mk500 vbacl[16050]: File list received
Июл 09 00:05:24 linux-mk500 vbacl[16050]: Update is not needed
Июл 09 00:05:24 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update 
Service.


Июл 09 01:05:50 linux-mk500 systemd[1]: Starting VBA32 Anti-Virus Update 
Service...
Июл 09 01:05:50 linux-mk500 vbacl[16528]: Vba32 console scanner update 
process started
Июл 09 01:05:50 linux-mk500 vbacl[16528]: Reading configuration options 
from ./vbacl.ini

Июл 09 01:05:50 linux-mk500 vbacl[16528]: Using direct connection for update
Июл 09 01:05:55 linux-mk500 vbacl[16528]: Current dir is ./
Июл 09 01:05:55 linux-mk500 vbacl[16528]: Start update from 
http://anti-virus.by/update

Июл 09 01:05:55 linux-mk500 vbacl[16528]: Receiving file list
Июл 09 01:05:55 linux-mk500 vbacl[16528]: File list received
Июл 09 01:05:55 linux-mk500 vbacl[16528]: Update is not needed
Июл 09 01:05:55 linux-mk500 systemd[1]: Started VBA32 Anti-Virus Update 
Service.

==

We see 22:05:02 (end of update-session) --> 23:05:13 (start of next 
update-session) --> 23:05:17 (end of update-session) --> 00:05:20 (start 
of next update-session) --> 00:05:24 (end of update-session) --> 
01:05:50 (start of next update-session) --> 01:05:55 (end of 
update-session).


Question: Why time of new update-session is *not* equal to time of end 
of previous update-session + 1h in section of seconds, e.g. 23:05:17 +1h 
= 00:05:17; 00:05:24 + 1h = 01:05:24 and so on? Is here a way to reach 
this precise coincidence?


Thanks!

Platform: x64, openSUSE Leap 42.1, systemd 210.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread David Timothy Strauss
On Fri, Jul 8, 2016 at 9:07 AM Lennart Poettering 
wrote:

> Ultimately it's really a design decision: tabular file formats have
> the benefit of being a lot more dense, but are neither particularly
> extensible nor self-explanatory (as you need to know what each column
> means). Unit files are a bit longer to write, but more extensible and
> self-explanatory. When we designed this we preferred the latter two
> properties over the density property.
>

Tabular file formats are also much harder to manage with configuration
tools like Chef, Puppet, and Ansible. They almost always require some
"generator" to handle the composition from multiple sources.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Michał Zegan
the only reason to add such a thing at all is that making one file is
easier/faster. There is no other reason beside this one, so if it is not
considered a good one, then this feature is othervise useless. Also,
some time after proposing this I realized that it would be very easy to
implement what I say for new timer units, but you would need extra logic
to handle changing and reloading those timer units, or removing them
maybe, so hmm well, may be more complicated than I thought.

W dniu 08.07.2016 o 21:04, Andrei Borzenkov pisze:
> 08.07.2016 21:40, Michał Zegan пишет:
>> Well, I also came with another idea. of course if you do not want to
>> have two different ways to do one thing it is a stopper, but I will tell
>> about it for completeness as it may or may not be easier to implement.
>> Instead of creating a timer unit on service file installation or
>> something, you could have service and similar sections in the timer
>> unit, so the other way around. then, if service name is not explicitly
>> set in the unit and the service file with appropriate name does not
>> exist, it could just create it using information found in the timer unit
>> file, if such information can be found. The service file will be
>> generated in /run/systemd/system for example and it will work normally.
> 
> So you just added one more step and end up in with exactlythe same - you
> have separate timer and service units. How is it an improvement? If you
> need to have separate service unit anyway, what advantage defining it
> somewhere else offers?
> 
>> So, except the reason about not wanting to have two different ways of
>> doing one thing, it does not have other problems of the approach
>> mentioned first unless you also have another reasons not to generate
>> service units this way.
>>
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Depending on services from a service unit template

2016-07-08 Thread Andrei Borzenkov
08.07.2016 22:01, Lennart Poettering пишет:
> On Fri, 01.07.16 06:37, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> 
>> In principle, I do not see why we cannot have WantedBy and RequiredBy as
>> first class directives under [Unit] to spare all these hoops.
> 
> systemd loads unit files as they are requested, by following
> dependencies. i.e. when we see Wants=foobar.service in a file
> quux.service, and quux.service is loaded because it shall be started
> then we'll load foobar.service too. systemd does not load unit files
> that are not referenced by any other unit. It hence minimizes what it
> loads, and it does *not* iterate through the unit dirs loading
> everything it finds there.
> 
> Now, if we would permit WantedBy= in [Unit], this would mean that if a
> unit file waldo.service carries WantedBy=miau.service in [Unit], then
> when miau.service is requested to be started we would somehow have to
> determine that waldo.service is to be loaded and started too. But how
> could we do that without loading all possible unit files as boot? i
> mean, how would we efficiently detect that waldo.service needs to be
> loaded when just looking at miau.service if the latter does not carry
> in anyway information about the former?
> 

I see, yes, I did not consider it. Thank you for explanation.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Depending on services from a service unit template

2016-07-08 Thread Lennart Poettering
On Mon, 27.06.16 08:25, Paul Menzel (paulepan...@users.sourceforge.net) wrote:

> Dear systemd folks,
> 
> 
> having a template for a service unit like `example@.service`, and
> starting several services from it, is there a way, to let another
> service unit require all services started from that template?

Well, what does "all instances" even mean? Note that instances can be
instantiated dynamically. i.e. without having a unit file
foo@bar.service on disk you can simply by having foo@.service on disk
make "systemctl start foo@bar.service" work. Hence, if you want some
other service to have deps onto "all" instances of foo@.service, then
this would mean you'd have to add deps for really all theoretically
possible instance strings, and those are quite a few...

Now, what would make more sense if by "all" you just mean "all *enabled*
instances". if that's what you mean then RequiredBy= in [Install]
should do what you need.

Alternatively, if by "all" you mean "all *running" instances", then
you could use PartOf= in the instance unit file instead of
Requires=. The effective difference is that only stops are propagated,
but not starts.

Hope this makes some sense,

Lennart

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


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Andrei Borzenkov
08.07.2016 21:40, Michał Zegan пишет:
> Well, I also came with another idea. of course if you do not want to
> have two different ways to do one thing it is a stopper, but I will tell
> about it for completeness as it may or may not be easier to implement.
> Instead of creating a timer unit on service file installation or
> something, you could have service and similar sections in the timer
> unit, so the other way around. then, if service name is not explicitly
> set in the unit and the service file with appropriate name does not
> exist, it could just create it using information found in the timer unit
> file, if such information can be found. The service file will be
> generated in /run/systemd/system for example and it will work normally.

So you just added one more step and end up in with exactlythe same - you
have separate timer and service units. How is it an improvement? If you
need to have separate service unit anyway, what advantage defining it
somewhere else offers?

> So, except the reason about not wanting to have two different ways of
> doing one thing, it does not have other problems of the approach
> mentioned first unless you also have another reasons not to generate
> service units this way.
> 


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


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Michał Zegan
Well, I also came with another idea. of course if you do not want to
have two different ways to do one thing it is a stopper, but I will tell
about it for completeness as it may or may not be easier to implement.
Instead of creating a timer unit on service file installation or
something, you could have service and similar sections in the timer
unit, so the other way around. then, if service name is not explicitly
set in the unit and the service file with appropriate name does not
exist, it could just create it using information found in the timer unit
file, if such information can be found. The service file will be
generated in /run/systemd/system for example and it will work normally.
So, except the reason about not wanting to have two different ways of
doing one thing, it does not have other problems of the approach
mentioned first unless you also have another reasons not to generate
service units this way.

W dniu 08.07.2016 o 20:29, Lennart Poettering pisze:
> On Fri, 08.07.16 18:17, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> well, that makes sense, thanks. about a timer section shortcut, could it
>> be done in a different way? like, it is a shortcut and systemd should
>> somehow generate the corresponding timer file automatically? although
>> still it would need a little special logic when loading the service
>> first.
> 
> I am not convinced that providing two redundant ways to do the same
> thing is a good idea. It's bad enough we support both /etc/fstab and
> .mount for defining mounts. "Compatibility" is certainly a good enough
> excuse to do this anyway in this case. However, if we have two
> different ways to configure the same thing with systemd-native file
> formats then that's a very different thing and I am very conservative
> about really.
> 
> And as mentioned in the other mail: the load logic would become quite
> different as we'd have to look for all kinds of unit files if we try
> to load a .timer unit.
> 
> Lennart
> 



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] *argh* Re: systemd-devel Digest, Vol 75, Issue 19

2016-07-08 Thread Clemens Gruber
On Fri, Jul 08, 2016 at 06:51:13PM +0300, Mantas Mikulėnas wrote:
> On Fri, Jul 8, 2016 at 6:23 PM, Reindl Harald 
> wrote:
> 
> > > There can be many instances of a application without being related in
> > > any way (parent and children) so niceness won't be inherited
> >
> > that is nonsense - niceness *is* inherited
> >
> > BTW:
> > wow - and after you recently found the answer-button you start to reply to
> > digest-mails without a sensible subject - what's wrong with you and the way
> > you handle your mail client?
> >
> 
> Looks like you didn't inherit any niceness, though. Could you please stop
> attacking every new poster here? Go outside and yell at a cloud instead.

Full ACK!

This is NOT a good attitude towards newbies. And this is not the first
time I noticed such behavior from him on mailing lists:
https://fedorahosted.org/council/ticket/6

Be excellent to each other!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread One Infinite Loop
As I said before, I don't want to replace .service+.timer combination. I
just think there are cases when .service file (containing, for example,
ExecStart followed by many ExecStartPost) can have a [Crontab] section with
.timer syntax. The two formats (service+timer and [Crontab] inside a
service file) can coexist. It's just a suggestion.

On Fri, Jul 8, 2016 at 7:16 PM, Lennart Poettering 
wrote:

> On Fri, 08.07.16 16:35, One Infinite Loop (6po...@gmail.com) wrote:
>
> > A few usecases:
> > 1) I want to delete specific files once a day
>
> For this you probably should be using tmpfiles' "aging" logic, and not
> define your own timer.
>
> > 2)I want to free RAM using sync command and `echo 3 >
> > /proc/sys/vm/drop_caches` every 15 seconds
>
> Uh. Oh. I don't see why anyone would want to do this...
>
> > 3)I want to make sure certain processes always run using a specific nice
> > value like -15. I know control groups are invented but it's not the same
> > thing.
>
> Doing this with a service timer appears very strange to me. Simply set
> "Nice=-15" in the unit file starting your service and the nice level will
> be properly inherited by all processes of your services.
>
> But, in general, you could do all of the above with a combination of
> .timer and .service file just fine already. These usecases are
> perfectly covered, the only difference between what you are proposing
> and what has been implemented is whether it's adding two unit files
> per item instead of one, which I don't think is too bad...
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] *argh* Re: systemd-devel Digest, Vol 75, Issue 19

2016-07-08 Thread Reindl Harald



Am 08.07.2016 um 17:51 schrieb Mantas Mikulėnas:

On Fri, Jul 8, 2016 at 6:23 PM, Reindl Harald > wrote:

> There can be many instances of a application without being related in
> any way (parent and children) so niceness won't be inherited

that is nonsense - niceness *is* inherited

BTW:
wow - and after you recently found the answer-button you start to
reply to digest-mails without a sensible subject - what's wrong with
you and the way you handle your mail client?

Looks like you didn't inherit any niceness, though. Could you please
stop attacking every new poster here? Go outside and yell at a cloud
instead


sorry, but i have asked often enough to write mails like every other 
human does and after "i don't know how to quote" this *was nice*




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Michał Zegan
well, that makes sense, thanks. about a timer section shortcut, could it
be done in a different way? like, it is a shortcut and systemd should
somehow generate the corresponding timer file automatically? although
still it would need a little special logic when loading the service first.

W dniu 08.07.2016 o 18:06, Lennart Poettering pisze:
> On Fri, 08.07.16 15:42, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> 
>> One thing to say: I heard, at least once, that systemd's timer are more
>> complicated because in order to make a timer you need two files instead
>> of creating one, especially in comparison to cron where you need just
>> one line although I always forget the order of fields. I would say a
>> timer section in the service file could be a nice shortcut to create
>> timers for services quickly.
> 
> Yes, cron lines are much more condensed than .timer unit files, and
> /etc/fstab lines are more condensed than .mount unit files. But I also
> believe that unit files due to their relatively uniform and
> self-describing format are much easier to read at least, as well as a
> lot more extensible. After all, we do expose a number of options for
> timer units that I wouldn't even know how one could condense into a
> cron line... /etc/fstab files are a bit more extensible than cron
> lines, since the options part allows adding in additional, new
> settings, but it isn't really that pretty to write them all into the
> fourth column of a single line, without any whitespace and so on.
> 
> Ultimately it's really a design decision: tabular file formats have
> the benefit of being a lot more dense, but are neither particularly
> extensible nor self-explanatory (as you need to know what each column
> means). Unit files are a bit longer to write, but more extensible and
> self-explanatory. When we designed this we preferred the latter two
> properties over the density property.
> 
> I hope this makes sense,
> 
> Lennart
> 



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Lennart Poettering
On Fri, 08.07.16 15:42, Michał Zegan (webczat_...@poczta.onet.pl) wrote:

> One thing to say: I heard, at least once, that systemd's timer are more
> complicated because in order to make a timer you need two files instead
> of creating one, especially in comparison to cron where you need just
> one line although I always forget the order of fields. I would say a
> timer section in the service file could be a nice shortcut to create
> timers for services quickly.

Yes, cron lines are much more condensed than .timer unit files, and
/etc/fstab lines are more condensed than .mount unit files. But I also
believe that unit files due to their relatively uniform and
self-describing format are much easier to read at least, as well as a
lot more extensible. After all, we do expose a number of options for
timer units that I wouldn't even know how one could condense into a
cron line... /etc/fstab files are a bit more extensible than cron
lines, since the options part allows adding in additional, new
settings, but it isn't really that pretty to write them all into the
fourth column of a single line, without any whitespace and so on.

Ultimately it's really a design decision: tabular file formats have
the benefit of being a lot more dense, but are neither particularly
extensible nor self-explanatory (as you need to know what each column
means). Unit files are a bit longer to write, but more extensible and
self-explanatory. When we designed this we preferred the latter two
properties over the density property.

I hope this makes sense,

Lennart

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


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Lennart Poettering
On Fri, 08.07.16 19:00, One Infinite Loop (6po...@gmail.com) wrote:

> No, I understand perfectly why 2 files are needed. All I am saying is that,
> in some cases, a section like [Crontab] in a .service file (where you set a
> few commands to run every 15 seconds) would be very useful.

Well, but that would mean quite a redundancy in our most core file format, and I
am not a fan of that I must say. After all this way you'd have two
ways to define a time-triggered service: via a pair of timer+service
unit file, or via a service file with embedded timer section...

Besides that: systemd's loading logic is pretty simply right now:
essentially, if you start a unit "foobar.quux", then we look for a
file named "foobar.quux" on disk, and load it. If you could however
embedd the definition of "foobar.timer" in "foobar.service", then
finding the definitions becomes a lot different because for every
request for "foobar.timer" you'd need to look for "foobar.timer" *and*
"foobar.service" and probably similar for the other triggering unit
types and possible unit types that may be triggered, in any
combination... And I am really not sure I'd like such lookup logic.

Hope this makes sense,

Lennart

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


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread One Infinite Loop
No, I understand perfectly why 2 files are needed. All I am saying is that,
in some cases, a section like [Crontab] in a .service file (where you set a
few commands to run every 15 seconds) would be very useful.

On Fri, Jul 8, 2016 at 6:54 PM, Lennart Poettering 
wrote:

> On Fri, 08.07.16 16:03, One Infinite Loop (6po...@gmail.com) wrote:
>
> > If you want to disable timer alone or do something else, then you could
> use
> > .timer file. If not, instead of [Install] section in  .service file, you​
> > could have a [Timer] section.
>
> The reason timer definitions and service definitions are separate is
> that timers may be in effect independently of the services they
> trigger, and services may be active independently of any timers they
> are triggered by. Thus, as the lifecycle of both is pretty much
> independent of each other, and independent object should have their
> own 1:1 unit files on disk we chose to have the timer and service unit
> files separate on disk too.
>
> Why I do acknowledge your PoV on this, and can see why it appears
> suprising at first why you have to have two files on disk for this
> instead of just one, I think ultimately it's more uniform and easier
> to grok if independent objects with independent lifecycles map to
> independent files on disk.
>
> Hope that makes sense.
>
> (Also, your email/quoting program appears very broken)
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Lennart Poettering
On Fri, 08.07.16 16:03, One Infinite Loop (6po...@gmail.com) wrote:

> If you want to disable timer alone or do something else, then you could use
> .timer file. If not, instead of [Install] section in  .service file, you​
> could have a [Timer] section.

The reason timer definitions and service definitions are separate is
that timers may be in effect independently of the services they
trigger, and services may be active independently of any timers they
are triggered by. Thus, as the lifecycle of both is pretty much
independent of each other, and independent object should have their
own 1:1 unit files on disk we chose to have the timer and service unit
files separate on disk too.

Why I do acknowledge your PoV on this, and can see why it appears
suprising at first why you have to have two files on disk for this
instead of just one, I think ultimately it's more uniform and easier
to grok if independent objects with independent lifecycles map to
independent files on disk.

Hope that makes sense.

(Also, your email/quoting program appears very broken)

Lennart

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


Re: [systemd-devel] *argh* Re: systemd-devel Digest, Vol 75, Issue 19

2016-07-08 Thread Mantas Mikulėnas
On Fri, Jul 8, 2016 at 6:23 PM, Reindl Harald 
wrote:

> > There can be many instances of a application without being related in
> > any way (parent and children) so niceness won't be inherited
>
> that is nonsense - niceness *is* inherited
>
> BTW:
> wow - and after you recently found the answer-button you start to reply to
> digest-mails without a sensible subject - what's wrong with you and the way
> you handle your mail client?
>

Looks like you didn't inherit any niceness, though. Could you please stop
attacking every new poster here? Go outside and yell at a cloud instead.

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


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Reindl Harald


Am 08.07.2016 um 16:21 schrieb One Infinite Loop:

I want like my browser processes, for example, to run at a nice value of
-15. That's why I want to run '/usr/bin/zsh -c '/usr/bin/renice -15 -p
$(/usr/bin/pgrep -f /opt/google/chrome/chrome)'` every 15 seconds, for
example


well, nice -15 means nearly real time and is for a browser similar 
*censored* than `echo 3 > /proc/sys/vm/drop_caches` every 15 minutes 
because under load combined with a hanging javascript your computer will 
no longer respond to anything


for a real usecase not allowing your browser to eat all ressources when 
you visit a buggy website "nice -n 15" in the .desktop file which starts 
your browser would be the way to go


think about a better example - don't get me wrong but that and "i don't 
know how to reply" togehter don't qualify you for any technical proposal




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread One Infinite Loop
I want crontab gone and I want to delete specific files once a day and 6
minutes after I opened my computer.

My Ubuntu 16.04 runs just fine, thanks for your concern.

I want like my browser processes, for example, to run at a nice value of
-15. That's why I want to run '/usr/bin/zsh -c '/usr/bin/renice -15 -p
$(/usr/bin/pgrep -f /opt/google/chrome/chrome)'` every 15 seconds, for
example.

On Fri, Jul 8, 2016 at 5:06 PM, Mantas Mikulėnas  wrote:

> On Fri, Jul 8, 2016 at 4:35 PM, One Infinite Loop <6po...@gmail.com>
> wrote:
>
>> A few usecases:
>> 1) I want to delete specific files once a day
>>
>
> The existing cronjobs and .timer units work well enough for that. Also,
> systemd even ships with a predefined daily systemd-tmpfiles-clean.timer,
> see the "r" and "R" types in `man tmpfiles.d`.
>
>
>> 2)I want to free RAM using sync command and `echo 3 >
>> /proc/sys/vm/drop_caches` every 15 seconds
>>
>
> Why would you do that? There are better ways to make a computer slower.
>
>
>> 3)I want to make sure certain processes always run using a specific nice
>> value like -15. I know control groups are invented but it's not the same
>> thing.
>>
>
> That's a service option. It's not related to timers.
>
> I don't know how to quote and how to reply because it's my first time when
>> I use a mailing list.
>>
>
> Surely not the first time using Gmail though. Press 'a' or click "Reply to
> all".
>
> --
> Mantas Mikulėnas 
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Tomasz Torcz


  Could you please stop breaking threads?  Every reply you send starts
a new thread, while they all belong to one mail thread.

-- 
Tomasz Torcz"Funeral in the morning, IDE hacking
xmpp: zdzich...@chrome.plin the afternoon and evening." - Alan Cox

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


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Mantas Mikulėnas
On Fri, Jul 8, 2016 at 4:35 PM, One Infinite Loop <6po...@gmail.com> wrote:

> A few usecases:
> 1) I want to delete specific files once a day
>

The existing cronjobs and .timer units work well enough for that. Also,
systemd even ships with a predefined daily systemd-tmpfiles-clean.timer,
see the "r" and "R" types in `man tmpfiles.d`.


> 2)I want to free RAM using sync command and `echo 3 >
> /proc/sys/vm/drop_caches` every 15 seconds
>

Why would you do that? There are better ways to make a computer slower.


> 3)I want to make sure certain processes always run using a specific nice
> value like -15. I know control groups are invented but it's not the same
> thing.
>

That's a service option. It's not related to timers.

I don't know how to quote and how to reply because it's my first time when
> I use a mailing list.
>

Surely not the first time using Gmail though. Press 'a' or click "Reply to
all".

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


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Michał Zegan
One thing to say: I heard, at least once, that systemd's timer are more
complicated because in order to make a timer you need two files instead
of creating one, especially in comparison to cron where you need just
one line although I always forget the order of fields. I would say a
timer section in the service file could be a nice shortcut to create
timers for services quickly.

W dniu 08.07.2016 o 15:14, Reindl Harald pisze:
> 
> 
> Am 08.07.2016 um 15:11 schrieb One Infinite Loop:
>> There are cases when you don't need .timer files but only a [Timer]
>> section. With a well written manual page, systemd users will understand
>> why is useful to have a [Timer] section inside a .service file
> 
> FIRST: learn to quote in email
> 
> second: you need to explain the usecases very well
> third: a good design don't require read manpages all the time
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread One Infinite Loop
OK, I have a new idea: let's not call the section [Timer] but [Crontab].

Of course, the manual page will explain what is its purpose. I expect
feedback.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Reindl Harald



Am 08.07.2016 um 15:35 schrieb One Infinite Loop:

A few usecases:
1) I want to delete specific files once a day


what is the problem?


2)I want to free RAM using sync command and `echo 3 >
/proc/sys/vm/drop_caches` every 15 seconds


besides it's stupid - what is the problem?


3)I want to make sure certain processes always run using a specific nice
value like -15. I know control groups are invented but it's not the same
thing.


what is the problem


I know crontab was invented too but I wanna learn only one syntax:
systemd syntax.


how does that change the fact that it would be broken by design to have 
a timer-section which is implicit active while the unit is disabled 
which is the reason you have both and why don't you just learn it?



I don't know how to quote and how to reply because it's my first time
when I use a mailing list


DAMNED:
it has nothing to do with mailing lists and when you don't know what 
quoting means, even not when compare the mails of others and yours which 
are only contain your response but no part of the previous communication 
go and make your homework first by learn to use your mailclient since 
that is even worser than top-posting with full-quotes


*you really* believe somebody is interested enough that he seeks for 
your previous mails and *guess* to which person you replied at all when 
there where more then one response since your last mail?




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread One Infinite Loop
A few usecases:
1) I want to delete specific files once a day
2)I want to free RAM using sync command and `echo 3 >
/proc/sys/vm/drop_caches` every 15 seconds
3)I want to make sure certain processes always run using a specific nice
value like -15. I know control groups are invented but it's not the same
thing.

I know crontab was invented too but I wanna learn only one syntax: systemd
syntax.

I don't know how to quote and how to reply because it's my first time when
I use a mailing list.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Reindl Harald

AGAIN: learn to write readable communication

* quote waht you refer to
* get rid of html

Am 08.07.2016 um 15:21 schrieb One Infinite Loop:

Why would you create another one? Why are there always people who try to
complicate things?


you try to complicate things since you bring a *third* place besides the 
unit files and the .d/ directoris in the game



The same way you read and edit your sudoers files, your fstab file, you
will read & edit the .service file that your distro is shipping to you


when you edit the .service file the distro ships you make a big mistake 
from the very first start



Let's not forget about the manual page that will document the change


that does not change the fact that a *service* for a timer is *by 
definition* disabled and so it violates the rule of least surprise when 
the timer-section is executed while the unit is disabled


hence the .service is disbaled and the .timer is enabled
that's logical and understandable

what you propose is a bad design and bad deisn can not be repaired with 
writing documentations




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread One Infinite Loop
Why would you create another one? Why are there always people who try to
complicate things?
The same way you read and edit your sudoers files, your fstab file, you
will read & edit the .service file that your distro is shipping to you.
Let's not forget about the manual page that will document the change.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Reindl Harald



Am 08.07.2016 um 15:11 schrieb One Infinite Loop:

There are cases when you don't need .timer files but only a [Timer]
section. With a well written manual page, systemd users will understand
why is useful to have a [Timer] section inside a .service file


FIRST: learn to quote in email

second: you need to explain the usecases very well
third: a good design don't require read manpages all the time



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread One Infinite Loop
There are cases when you don't need .timer files but only a [Timer]
section. With a well written manual page, systemd users will understand why
is useful to have a [Timer] section inside a .service file.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Reindl Harald



Am 08.07.2016 um 15:03 schrieb One Infinite Loop:

If you want to disable timer alone or do something else, then you could
use .timer file. If not, instead of [Install] section in  .service file,
you​ could have a [Timer] section


so and when the distribution package ships one of them and you create 
the other one which wins?


a timer unit has a service with the same name which is expected to be 
*disabled* because it is started by the timer with the same name


so how do you imagine *disable* a timer in the same service file

sorry, but your idea is ill-conceived



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Adding a Timer section to .service files

2016-07-08 Thread Reindl Harald



Am 08.07.2016 um 07:35 schrieb One Infinite Loop:

systemctl start foo.service
systemctl enable foo.service


would enabled timer *and* service
how would you disable the timer alone?
how do you imagine that to work with Type=forking or Type=simple

sorry that is a sonsense idea because it offers the worm of cans 
contradictory



systemd tools must be modified/adjusted​ too

On Fri, Jul 8, 2016 at 8:08 AM, Mantas Mikulėnas > wrote:

On Fri, Jul 8, 2016 at 7:52 AM, One Infinite Loop <6po...@gmail.com
> wrote:

Instead of having a .service file and a .timer file why not
having a [Timer] section inside a .service file? It would be
much more manageable as one file.


More manageable? How would you actually activate/deactivate it
without being able to 'systemctl start foo.timer'?

--
Mantas Mikulėnas >




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel