systemd timing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

systemd timing

Karl Auer
How can I make a systemd service run after all network interfaces are
up?

systemd-sysctl is a one-shot service that runs very early in the
startup sequence; I need it to run again. Ideally every time a network
interface comes up, but a workable solution would be after the network
is up the first time.

Note that I need it to run *again* - i.e., as well as the first time.

I suppose I could set up a new service to do this, but it would be
cleaner if there were a way to tell the existing service to run again.

Regards, K.

[1] /lib/systemd/system/systemd-sysctl.service

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([hidden email])
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: A52E F6B9 708B 51C4 85E6 1634 0571 ADF9 3C1C 6A3A
Old fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B



--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Xen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: systemd timing

Xen
Karl Auer schreef op 15-07-2017 13:04:

> How can I make a systemd service run after all network interfaces are
> up?
>
> systemd-sysctl is a one-shot service that runs very early in the
> startup sequence; I need it to run again. Ideally every time a network
> interface comes up, but a workable solution would be after the network
> is up the first time.
>
> Note that I need it to run *again* - i.e., as well as the first time.
>
> I suppose I could set up a new service to do this, but it would be
> cleaner if there were a way to tell the existing service to run again.

You asked before, but personally I would just create a new service to
rerun this service.

If you want something else, it would have to be a timer, I guess, but...

I do not know.

Experiment :p. A one-shot service that stays, or a one-shot service that
exists? In any case many times you need to restart it since the service
will still be considered "started" I think.

So the first question is: does it have RemainAfterExit?

I really don't know how it all works, although I have experimented with
it enough.

I think I would just pull in a service using a network target. The
service runs "systemctl restart systemd.sysctl".

I mean, you can't do much with systemd's system.

You could use network.target or network-online.target. It was for the
ipv6 right.

Looking for a clean solution in a dirty system is not very useful ;-).

Regards.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: systemd timing

Karl Auer
On Sat, 2017-07-15 at 13:31 +0200, Xen wrote:
> Karl Auer schreef op 15-07-2017 13:04:
> > How can I make a systemd service run after all network interfaces
> > are up?

The actual problem was that certain IPv6-related sysctl variables were
not being set because the interfaces were up at the time the sysctl
service ran. OR the network plumbing was setting them back; that's a
possibility I was unable to check.

Specifically, autoconf was not working, and the autoconf and accept_ra
variables were not being set (or were being reset).

Running the sysctl service again manually after boot fixed the problem
temporarily, hence my desire to run it later, but automatically.

In trying to make that simple thing happen, I was exposed to the full
lunacy that is systemd.

I finally got it to work by making it dependent on a late-completion
target ("WantedBy=multi-user.target"). I was completely unable to
locate the correct moment to re-run it, so the fine-grained control
that is supposed to be enabled by systemd was made a mockery of.

The solution to my actual problem was to use static IPv6 addresses
(which is what I needed anyway, I just got distracted by SLAAC
addressing apparently not working).

There are still several anomalies WRT IPv6 addressing; I think the
presence of at least three systems, each of which seems to want to
control elements of SLAAC, is a big part of the problem. DHCP, systemd
and the "old" /etc/network/interfaces method.

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([hidden email])
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: A52E F6B9 708B 51C4 85E6 1634 0571 ADF9 3C1C 6A3A
Old fingerprint: E00D 64ED 9C6A 8605 21E0 0ED0 EE64 2BEE CBCB C38B



--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Xen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: systemd timing

Xen
Karl Auer schreef op 16-07-2017 17:01:

> In trying to make that simple thing happen, I was exposed to the full
> lunacy that is systemd.
>
> I finally got it to work by making it dependent on a late-completion
> target ("WantedBy=multi-user.target"). I was completely unable to
> locate the correct moment to re-run it, so the fine-grained control
> that is supposed to be enabled by systemd was made a mockery of.

Well I guess you can do pre and post stuff (Before and After) wrt other
services but that means you get a solution that is rather specific to
other services existing, I guess...

In the end it works and then you wonder why ;-). Right.

Amazing that you got this far in any case. Hats off.

> The solution to my actual problem was to use static IPv6 addresses
> (which is what I needed anyway, I just got distracted by SLAAC
> addressing apparently not working).

I think SLAAC is not very useful myself, but yeah... as if it still
matters what I'd say or what anyone would say ;-).

The only thing you can do is try to stay true to yourself in that sense.

> There are still several anomalies WRT IPv6 addressing; I think the
> presence of at least three systems, each of which seems to want to
> control elements of SLAAC, is a big part of the problem. DHCP, systemd
> and the "old" /etc/network/interfaces method.

Alright.

I was never bothered by IPv4 in the slightest, and then when there was
some debate somewhere my 'opponent' said he liked IPv6 because it meant
he could easier manage the 100 computers behind the firewall.

And I'm like, but if you are going to be doing things on that scale,
surely a software could be developed to act as a proxy for that in an
easier way?

IPv4 throws up hindrances, but they only really start to bug people when
the scale goes up, and at that point you wonder why they can't invest
time in finding another solution ;-).

Anyway, so much for my unsolicited opinion.

Regards.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: systemd timing

Tom H-4
In reply to this post by Karl Auer
On Sat, Jul 15, 2017 at 7:04 AM, Karl Auer <[hidden email]> wrote:


> How can I make a systemd service run after all network interfaces are
> up?

Before=network-online.target
Wants=network-online.target


> systemd-sysctl is a one-shot service that runs very early in the
> startup sequence; I need it to run again. Ideally every time a network
> interface comes up, but a workable solution would be after the network
> is up the first time.

Which network setup are you using? ifupdown? NM? systemd-networkd?


> Note that I need it to run *again* - i.e., as well as the first time.
>
> I suppose I could set up a new service to do this, but it would be
> cleaner if there were a way to tell the existing service to run again.

It'd be better to set up a new service because sysctl might need to
run "at the right time" for other values.

--
ubuntu-users mailing list
[hidden email]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
Loading...