[systemd-devel] Emulate two cron tab entries to start/stop service unit natively?

[John]

Is it possible to use a systemd timer unit to start and stop a service unit 
according to set times of the day?  In my case, openvpn.service is a forking 
type if that matters. I can do this using cron, but am wondering if/how to do 
it with systemd natively.

In cron terms, one could do this like so:
# start at 7 AM
* 7 * * * systemctl start openvpn.service


# stop at 5 PM
* 17 * * * systemctl stop openvnp.service

The syntax of the timer with differential commands (ie start the service at 7 
AM and stop it at 5 PM) isn't clear to me even after consulting `man 
systemd.time` and `man systemd.timer`.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Question about changing systemd target during boot

[Kai Krakow]

Am Mon, 1 Aug 2016 16:09:36 +0300
schrieb Svetoslav Iliev :

> Hi guys,
> 
> Thank you for the prompt reply and your valuable input. Just to let
> you know - I was able to do exactly what I intended. As it turns out
> my mistake was indeed creating contradiction between the WantedBy and
> After sections. Once I introduced a new "change.target" and adjusted
> my services accordingly I was able to isolate successfully either A
> or B targets during boot.
> 
> I also had to split the services in two: one main blocking of type 
> oneshot and one non-blocking of simple type just to switch the
> target. As it seems I cannot call systemctl isolate from onehost type
> of service.

Wouldn't it be easier to simply make your change.target the default
boot target, depending on network-online.target and a service to start
the target you need instead of isolate? Otherwise multi-user.target
starts services you are going to stop just a blink later by using
isolate.

> I just like to say that I followed this guide: 
> https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget where
> I quote "/Alternatively, you can change your service that needs the 
> network to be up, to include After=network-online.target and 
> Wants=network-online.target./"
> 
> Once again thanks all for the help.
> 
> ---
> BR,
> 
> Swetli
> 
> On 08/01/2016 03:38 PM, Andrei Borzenkov wrote:
> > On Mon, Aug 1, 2016 at 2:43 PM, Michael Chapman
> >  wrote:  
> >> On Mon, 1 Aug 2016, Andrei Borzenkov wrote:  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
> >>
> >> I just checked the code, and it looks like systemd explicitly
> >> *skips* these default dependencies if they would create a loop. In
> >> target_add_default_dependencies:
> >>  
> > Yes, of course. It is also described in manual. But the question is
> > what user actually intended? It is more topic of good design.
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/systemd-devel  
> 
> 



-- 
Regards,
Kai

Replies to list-only preferred.

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

Re: [systemd-devel] NOARP support (systemd-networkd)

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jul 31, 2016 at 06:08:32AM +0300, Jukka Aho wrote:
> If there is a supported way of switching the "NOARP" mode on for a
> given interface, or a workaround, I'd be interested in hearing about
> it. If there is no support for this at all, I would suggest adding
> it.
There's no support currently, and no workaround except doing the
configuration externally through some script.

Susant Sahani quite often reacts to RFEs. It'd be best if you open
one at https://github.com/systemd/systemd/issues/new
and mention @ssahani.

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

Re: [systemd-devel] Question about changing systemd target during boot

[Svetoslav Iliev]

Hi guys,

Thank you for the prompt reply and your valuable input. Just to let you 
know - I was able to do exactly what I intended. As it turns out my 
mistake was indeed creating contradiction between the WantedBy and After 
sections. Once I introduced a new "change.target" and adjusted my 
services accordingly I was able to isolate successfully either A or B 
targets during boot.


I also had to split the services in two: one main blocking of type 
oneshot and one non-blocking of simple type just to switch the target. 
As it seems I cannot call systemctl isolate from onehost type of service.


I just like to say that I followed this guide: 
https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget where I 
quote "/Alternatively, you can change your service that needs the 
network to be up, to include After=network-online.target and 
Wants=network-online.target./"


Once again thanks all for the help.

---
BR,

Swetli

On 08/01/2016 03:38 PM, Andrei Borzenkov wrote:

On Mon, Aug 1, 2016 at 2:43 PM, Michael Chapman  wrote:

On Mon, 1 Aug 2016, Andrei Borzenkov wrote:

On Mon, Aug 1, 2016 at 2:23 PM, Michael Chapman 
wrote:

On Mon, 1 Aug 2016, Andrei Borzenkov wrote:
[...]


So here goes what I've done:

1. Create a service and put it in the network-online.target:

/etc/systemd/system/change-target.service:
[Unit]
Description=Change Target
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/tmp/script.sh
TimeoutSec=60s

[Install]
WantedBy=network-online.target


This unit have conflicting requirements - on one hand it is
After=network-online.target, OTOH WantedBy=network-online.target
implies Before=network-online.target.



I've seen this asserted on this list a few times, but as far as I can
tell
it isn't actually correct. After/Before are meant to be completely
orthogonal to Wants/Requires/etc., according to the documentation.


Unless DefaultDependencies= is set to no in either of releated units
or an explicit ordering dependency is already defined, target units
will implicitly complement all configured dependencies of type Wants=
or Requires= with dependencies of type After=.

man systemd.target


I just checked the code, and it looks like systemd explicitly *skips*
these default dependencies if they would create a loop. In
target_add_default_dependencies:


Yes, of course. It is also described in manual. But the question is
what user actually intended? It is more topic of good design.
___
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] Question about changing systemd target during boot

[Andrei Borzenkov]

On Mon, Aug 1, 2016 at 2:43 PM, Michael Chapman  wrote:
> On Mon, 1 Aug 2016, Andrei Borzenkov wrote:
>>
>> On Mon, Aug 1, 2016 at 2:23 PM, Michael Chapman 
>> wrote:
>>>
>>> On Mon, 1 Aug 2016, Andrei Borzenkov wrote:
>>> [...]
>
>
> So here goes what I've done:
>
> 1. Create a service and put it in the network-online.target:
>
> /etc/systemd/system/change-target.service:
> [Unit]
> Description=Change Target
> Wants=network-online.target
> After=network-online.target
>
> [Service]
> Type=oneshot
> ExecStart=/tmp/script.sh
> TimeoutSec=60s
>
> [Install]
> WantedBy=network-online.target
>

 This unit have conflicting requirements - on one hand it is
 After=network-online.target, OTOH WantedBy=network-online.target
 implies Before=network-online.target.
>>>
>>>
>>>
>>> I've seen this asserted on this list a few times, but as far as I can
>>> tell
>>> it isn't actually correct. After/Before are meant to be completely
>>> orthogonal to Wants/Requires/etc., according to the documentation.
>>>
>>
>> Unless DefaultDependencies= is set to no in either of releated units
>> or an explicit ordering dependency is already defined, target units
>> will implicitly complement all configured dependencies of type Wants=
>> or Requires= with dependencies of type After=.
>>
>> man systemd.target
>
>
> I just checked the code, and it looks like systemd explicitly *skips*
> these default dependencies if they would create a loop. In
> target_add_default_dependencies:
>

Yes, of course. It is also described in manual. But the question is
what user actually intended? It is more topic of good design.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Question about changing systemd target during boot

[Michael Chapman]

On Mon, 1 Aug 2016, Andrei Borzenkov wrote:

On Mon, Aug 1, 2016 at 2:23 PM, Michael Chapman  wrote:

On Mon, 1 Aug 2016, Andrei Borzenkov wrote:
[...]


So here goes what I've done:

1. Create a service and put it in the network-online.target:

/etc/systemd/system/change-target.service:
[Unit]
Description=Change Target
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/tmp/script.sh
TimeoutSec=60s

[Install]
WantedBy=network-online.target



This unit have conflicting requirements - on one hand it is
After=network-online.target, OTOH WantedBy=network-online.target
implies Before=network-online.target.



I've seen this asserted on this list a few times, but as far as I can tell
it isn't actually correct. After/Before are meant to be completely
orthogonal to Wants/Requires/etc., according to the documentation.



Unless DefaultDependencies= is set to no in either of releated units
or an explicit ordering dependency is already defined, target units
will implicitly complement all configured dependencies of type Wants=
or Requires= with dependencies of type After=.

man systemd.target


I just checked the code, and it looks like systemd explicitly *skips*
these default dependencies if they would create a loop. In 
target_add_default_dependencies:


/* Imply ordering for requirement dependencies on target
 * units. Note that when the user created a contradicting
 * ordering manually we won't add anything in here to make
 * sure we don't create a loop. */

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

Re: [systemd-devel] Question about changing systemd target during boot

[Michael Chapman]

On Mon, 1 Aug 2016, Andrei Borzenkov wrote:
[...]

So here goes what I've done:

1. Create a service and put it in the network-online.target:

/etc/systemd/system/change-target.service:
[Unit]
Description=Change Target
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/tmp/script.sh
TimeoutSec=60s

[Install]
WantedBy=network-online.target



This unit have conflicting requirements - on one hand it is
After=network-online.target, OTOH WantedBy=network-online.target
implies Before=network-online.target.


I've seen this asserted on this list a few times, but as far as I can tell 
it isn't actually correct. After/Before are meant to be completely 
orthogonal to Wants/Requires/etc., according to the documentation.


If A.service has:

  Wants=B.service
  Before=B.service

then any time you ask A.service to be started, systemd will add a job to 
start B.service... but it still ensures that A.service is started *before* 
B.service.


Is my understanding on this incorrect? I have been making use of this 
behaviour for quite some time, and as far as I can tell it has never 
failed.


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

Re: [systemd-devel] Question about changing systemd target during boot

[Andrei Borzenkov]

On Mon, Aug 1, 2016 at 2:23 PM, Michael Chapman  wrote:
> On Mon, 1 Aug 2016, Andrei Borzenkov wrote:
> [...]
>>>
>>> So here goes what I've done:
>>>
>>> 1. Create a service and put it in the network-online.target:
>>>
>>> /etc/systemd/system/change-target.service:
>>> [Unit]
>>> Description=Change Target
>>> Wants=network-online.target
>>> After=network-online.target
>>>
>>> [Service]
>>> Type=oneshot
>>> ExecStart=/tmp/script.sh
>>> TimeoutSec=60s
>>>
>>> [Install]
>>> WantedBy=network-online.target
>>>
>>
>> This unit have conflicting requirements - on one hand it is
>> After=network-online.target, OTOH WantedBy=network-online.target
>> implies Before=network-online.target.
>
>
> I've seen this asserted on this list a few times, but as far as I can tell
> it isn't actually correct. After/Before are meant to be completely
> orthogonal to Wants/Requires/etc., according to the documentation.
>

Unless DefaultDependencies= is set to no in either of releated units
or an explicit ordering dependency is already defined, target units
will implicitly complement all configured dependencies of type Wants=
or Requires= with dependencies of type After=.

man systemd.target

> If A.service has:
>
>   Wants=B.service
>   Before=B.service
>
> then any time you ask A.service to be started, systemd will add a job to
> start B.service... but it still ensures that A.service is started *before*
> B.service.
>
> Is my understanding on this incorrect? I have been making use of this
> behaviour for quite some time, and as far as I can tell it has never failed.
>
> - Michael
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Question about changing systemd target during boot

[Andrei Borzenkov]

On Mon, Aug 1, 2016 at 12:27 PM, Svetoslav Iliev  wrote:
> Hi all,
>
> I've been recently searching through internet for a possible solution for
> this but so far without success and I'm still not sure if it is even
> possible. Basically what I'm trying to do:
>
> During system boot, after the network-online target I want to execute a
> script which changes the current target ( or put simply just to boot in
> another target, not in the default multi-user.target).
>
> So here goes what I've done:
>
> 1. Create a service and put it in the network-online.target:
>
> /etc/systemd/system/change-target.service:
> [Unit]
> Description=Change Target
> Wants=network-online.target
> After=network-online.target
>
> [Service]
> Type=oneshot
> ExecStart=/tmp/script.sh
> TimeoutSec=60s
>
> [Install]
> WantedBy=network-online.target
>

This unit have conflicting requirements - on one hand it is
After=network-online.target, OTOH WantedBy=network-online.target
implies Before=network-online.target. Systemd breaks cycle here, but
what is correct?

Also network-online.target is intended to be passive, not pulling
anything, rather being pulled by other units.

> 2. Create two new targets:
> /etc/systemd/system/a.target:
> [Unit]
> Description=A Target
> Requires=multi-user.target
> After=multi-user.target
> AllowIsolate=yes
> Conflicts=b.target
>
> /etc/systemd/system/b.target:
> [Unit]
> Description=B Target
> Requires=multi-user.target
> After=multi-user.target
> AllowIsolate=yes
> Conflicts=a.target
>
> 3. The contents of script.sh
> blah blah: do some work and based on that do either
> systemctl isolate a.target || systemctl isolate b.target
>
> Note I've also edited the multi-user.target to depend on the the
> change-target.service by putting the latter in the former's wants and after
> sections. I've tried many things and every time it failed. The problem is
> that the systemd should "wait" for the execution of script.sh before
> continuing with the boot process.
>

This is virtually impossible currently. Nor is this requirement clear.
If systemd is as far as networking large part of startup sequence is
already processed. So how exactly you define units that can be started
before your switch and units that must wait?

> The question is - is what I'm trying to achieve even possible or systemd
> should boot in a certain target before changing to another one ? If possible
> please advise what I'm doing wrong since I'm pretty lost..
>
> ---
> BR,
>
> Swetli
>
>
> ___
> 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

[systemd-devel] FINAL REMINDER! systemd.conf 2016 CFP ends today!

[Lennart Poettering]

Hey!

This is the last reminder that the sytemd.conf 2016 CfP ends today,
Aug. 1st. Please submit your proposals by the end of the Day, Central
European Time! Thank you!

https://cfp.systemd.io/en/systemdconf_2016/cfp/session/new

Lennart

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

[systemd-devel] Question about changing systemd target during boot

[Svetoslav Iliev]

Hi all,

I've been recently searching through internet for a possible solution 
for this but so far without success and I'm still not sure if it is even 
possible. Basically what I'm trying to do:


During system boot, after the network-online target I want to execute a 
script which changes the current target ( or put simply just to boot in 
another target, not in the default multi-user.target).


So here goes what I've done:

1. Create a service and put it in the network-online.target:

/etc/systemd/system/change-target.service:
/[Unit]//
//Description=Change Target //
//Wants=network-online.target//
//After=network-online.target//
//
//[Service]//
//Type=oneshot//
//ExecStart=/tmp/script.sh//
//TimeoutSec=60s//
//
//[Install]//
//WantedBy=network-online.target/

2. Create two new targets:
/etc/systemd/system/a.target:
/[Unit]//
//Description=A Target//
//Requires=multi-user.target//
//After=multi-user.target//
//AllowIsolate=yes//
//Conflicts=b.target/

/etc/systemd/system/b.target:
/[Unit]//
//Description=B Target//
//Requires=multi-user.target//
//After=multi-user.target//
//AllowIsolate=yes//
//Conflicts=a.target/

3. The contents of script.sh
blah blah: do some work and based on that do either
systemctl isolate a.target || systemctl isolate b.target

Note I've also edited the multi-user.target to depend on the the 
change-target.service by putting the latter in the former's wants and 
after sections. I've tried many things and every time it failed. The 
problem is that the systemd should "wait" for the execution of script.sh 
before continuing with the boot process.


The question is - is what I'm trying to achieve even possible or systemd 
should boot in a certain target before changing to another one ? If 
possible please advise what I'm doing wrong since I'm pretty lost..


---
BR,

Swetli

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