Re: [systemd-devel] systemd-network and loopback
On Fri, Sep 9, 2022 at 11:36 PM Andrea Pappacoda wrote: > Il giorno ven 9 set 2022 alle 12:17:42 -05:00:00, Greg Oliver > ha scritto: > > Well, easiest to explain is user apps that use tcp or udp sockets to > > communicate. If they are on the same host, then huge gains can be > > achieved by using the loopback adapter (especially TCP comms). > > Thanks, but again, is this related to systemd-network in any way? My > question is whether letting systemd-network manage the loopback > interface is useful or not, not what the loopback interface is used for > in general. > > As far as I understand, systemd itself brings up the loopback interface > on its own during the early boot stage, and systemd-network(d) is > launched much later. But is writing something like this in > /etc/systemd/network/foo.conf ever useful? > > $ cat /etc/systemd/network/foo.conf > [Match] > Name=* > Type=loopback > It's useful when you want the `lo` interface to have a custom [Address] or two. Routers often have an address assigned that's supposed to be independent from any "physical" interface – on Linux it could be assigned to a Type=dummy interface or to an empty bridge, but just as frequently it's assigned to `lo`. (It's even called a "loopback address".) -- Mantas Mikulėnas
Re: [systemd-devel] systemd-network and loopback
Il giorno ven 9 set 2022 alle 12:17:42 -05:00:00, Greg Oliver ha scritto: Well, easiest to explain is user apps that use tcp or udp sockets to communicate. If they are on the same host, then huge gains can be achieved by using the loopback adapter (especially TCP comms). Thanks, but again, is this related to systemd-network in any way? My question is whether letting systemd-network manage the loopback interface is useful or not, not what the loopback interface is used for in general. As far as I understand, systemd itself brings up the loopback interface on its own during the early boot stage, and systemd-network(d) is launched much later. But is writing something like this in /etc/systemd/network/foo.conf ever useful? $ cat /etc/systemd/network/foo.conf [Match] Name=* Type=loopback -- OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49
Re: [systemd-devel] systemd-network and loopback
On Fri, Sep 09, 2022 at 12:17:42PM -0500, Greg Oliver wrote: > Il giorno ven 9 set 2022 alle 17:37:14 +02:00:00, Lennart Poettering > <[2]lenn...@poettering.net> ha scritto: > > People sometimes route stuff onto the loopback device in addition to > > the the usual [3]127.0.0.0/8 traffic so that it ends up on local > sockets. > > Thanks for the reply, but I don't fully understand the implications of > this, nor how sd-network is related - I'm quite ignorant when it comes > to networking :/ > >Well, easiest to explain is user apps that use tcp or udp sockets to >communicate. If they are on the same host, then huge gains can be >achieved by using the loopback adapter (especially TCP comms). >You should google search for loopback MTUs.. Sure, but network connections between processes on the local host will always use the loopback interface, whether they go out of their way to do so or not. It's part of the IP spec and it doesn't matter who's managing the loopback interface, nor does it depend on any special routing tricks or prefixes being present on the loopback interface specifically. $ ip -4 addr show dev ens5 ; ip -4 addr show dev lo ; ip -4 ro 2: ens5: mtu 9001 qdisc mq state UP group default qlen 1000 altname enp0s5 inet 10.0.0.162/24 brd 10.0.0.255 scope global dynamic ens5 valid_lft 3315sec preferred_lft 3315sec 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever default via 10.0.0.1 dev ens5 10.0.0.0/24 dev ens5 proto kernel scope link src 10.0.0.162 192.168.80.0/25 dev br-48e2d6739dbf proto kernel scope link src 192.168.80.1 $ ip -4 ro get 10.0.0.162 local 10.0.0.162 dev lo src 10.0.0.162 uid 1000 cache
Re: [systemd-devel] systemd-network and loopback
On Fri, Sep 9, 2022 at 10:40 AM Andrea Pappacoda wr > Il giorno ven 9 set 2022 alle 17:37:14 +02:00:00, Lennart Poettering > ha scritto: > > People sometimes route stuff onto the loopback device in addition to > > the the usual 127.0.0.0/8 traffic so that it ends up on local sockets. > > Thanks for the reply, but I don't fully understand the implications of > this, nor how sd-network is related - I'm quite ignorant when it comes > to networking :/ > Well, easiest to explain is user apps that use tcp or udp sockets to communicate. If they are on the same host, then huge gains can be achieved by using the loopback adapter (especially TCP comms). You should google search for loopback MTUs..
Re: [systemd-devel] Antw: Re: Re: [EXT] Re: Q: Querying units for "what provides" a target
On 09.09.2022 16:19, Andrei Borzenkov wrote: > "Requires" means - submit additional start jobs for the listed units > and wait until these start jobs are completed before processing the > start job for the unit itself. Sorry, that was wrong. That is what everyone assumes it does. Requires means - "submit additional start jibs and fail start job for this unit if these additional start jobs failed". The problem is that Requires by itself does not wait for additional jobs, so unit start can complete (successfully) before other jobs are selected for execution. Which is why Requires without After is almost never useful.
Re: [systemd-devel] systemd-network and loopback
Il giorno ven 9 set 2022 alle 17:37:14 +02:00:00, Lennart Poettering ha scritto: People sometimes route stuff onto the loopback device in addition to the the usual 127.0.0.0/8 traffic so that it ends up on local sockets. Thanks for the reply, but I don't fully understand the implications of this, nor how sd-network is related - I'm quite ignorant when it comes to networking :/ -- OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49
Re: [systemd-devel] systemd-network and loopback
On Fr, 09.09.22 14:45, Andrea Pappacoda (and...@pappacoda.it) wrote: > Hi all, > > yesterday I was playing a bit with systemd-network, and I noticed that it is > possible for it to manage the loopback interface. Is it useful in any way? > Should the loopback interface be managed in systems where sd-network is the > only program managing interfaces (like my desktop pc)? > > I tried looking at systemd.network(5), but that didn't seem to answer my > question. People sometimes route stuff onto the loopback device in addition to the the usual 127.0.0.0/8 traffic so that it ends up on local sockets. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Antw: Re: Re: [EXT] Re: Q: Querying units for "what provides" a target
On Fri, Sep 9, 2022 at 4:12 PM Ulrich Windl wrote: > Thanks for the explanation! For me part of the problem is: Where is "pull in" > defined? ;-) In an English dictionary? > The phrase is used for Wants, but also for Requires. So is "pull in " a > synonym for "wants or requires"? Yes. "Pull in some service" == "cause activation of some service". > (IMHO the first part is an "action", while the last part is a "desire", hard > to treat them as synonyms ;-)) > And in this case you should forget about the English meaning of these words (wants and requires) and treat them as opaque labels. As was mentioned more than once on this list. "Wants" means - submit additional start jobs for the listed units "Requires" means - submit additional start jobs for the listed units and wait until these start jobs are completed before processing the start job for the unit itself.
[systemd-devel] Antw: Re: Re: Antw: Re: Re: [EXT] Re: Q: Querying units for "what provides" a target
>>> Michael Biebl schrieb am 09.09.2022 um 14:15 in Nachricht
:
> Am Fr., 9. Sept. 2022 um 14:12 Uhr schrieb Michael Biebl :
>>
>> Am Fr., 9. Sept. 2022 um 14:01 Uhr schrieb Ulrich Windl
>> :
>> >
>> > >>> Andrei Borzenkov schrieb am 09.09.2022 um 13:41
>> > >>> in
>> > Nachricht
>> > :
>> > > On Fri, Sep 9, 2022 at 2:13 PM Ulrich Windl
>> > > wrote:
>> > > ...
>> > >> >
>> > >> > If you are interested in services that pull in e.g. time-sync.target
>> > >> > via Wants (or Requires) and order themselves before the target, you
>> > >> > can use something like
>> > >> > $ systemctl show time-sync.target -p WantedBy -p RequiredBy -p After
>> > >> > RequiredBy=
>> > >> > WantedBy=chrony.service
>> > >> > After=chrony.service time-set.target
>> > >>
>> > >> It seems what I wanted to know is output by
>> > >> # systemctl show -p After time-set.target
>> > >> After=systemd-timesyncd.service
>> > >> # systemctl show -p After time-sync.target
>> > >> After=time-set.target ntp-wait.service
>> > >>
>> > >> However the "After=" is somewhat unexpected.
>> > >
>> > > This is exactly what targets are about. The only usage for targets is
>> > > to wait until something else becomes active and to do it they must
>> > > come After something.
>> > >
>> > >> And "-p WantedBy" is definitely
>> > >> wrong (it will output units that "require the target", not the units
>> > > "providing
>> > >> the target").
>> > >>
>> > >
>> > > There is no such thing as "units providing the target". Systemd
>> > > documentation makes distinction between targets that Want other units
>> > > ("active") and targets that are WantedBy other units ("passive"). It
>> > > is expected that services "providing" passive targets have
>> > > WantedBy=this-passive.target, otherwise passive targets will not be
>> > > activated at all. So WantedBy is exactly correct in this case.
>> >
>> > Hi!
>> >
>> > But when I include it (as suggested) I get:
>> > # systemctl show -p WantedBy -p RequiredBy -p After time-sync.target
>> > RequiredBy=
>> > WantedBy=iotwatch@ROOT.service iotwatch@VPM.service
> iotwatch-generator.service ntp-wait.service systemd-timesyncd.service
>> > After=time-set.target ntp-wait.service
>> > ---
>> >
>> > Those iotwatch* units use "Before="; so is the WantedBy= incorrect for
> those?
>> >
>> > Those units use:
>> > Wants=nss-user-lookup.target time-sync.target paths.target
>> > After=nss-user-lookup.target time-sync.target paths.target
>>
>>
>> See man systemd.special, passive and active targets (as Andrei already
>> hinted at).
>> Quoting the relevant parts
>> " Special Passive System Units
>>A number of special system targets are defined that can be used
>> to properly order boot-up of optional services. These targets are
>> generally not part of the initial boot transaction, unless they are
>> explicitly pulled in by one of the implementing
>>services. Note specifically that these passive target units are
>> generally not pulled in by the consumer of a service, but by the
>> provider of the service.
>> "
>> iotwatch* does appear to be a consumer of the time-sync.target, so it
>> should merely have an ordering but not pull in the target.
>
> Quoting the rest of the man page section:
> "
> This means: a consuming service should order itself after these
> targets (as appropriate), but not
> pull it in. A providing service should order itself before these
> targets (as appropriate) and pull it in (via a Wants= type
> dependency).
> "
Thanks for the explanation! For me part of the problem is: Where is "pull in"
defined? ;-)
The phrase is used for Wants, but also for Requires. So is "pull in " a synonym
for "wants or requires"?
(IMHO the first part is an "action", while the last part is a "desire", hard to
treat them as synonyms ;-))
Regards,
Ulrich
Re: [systemd-devel] Antw: Re: Re: [EXT] Re: Q: Querying units for "what provides" a target
Am Fr., 9. Sept. 2022 um 14:12 Uhr schrieb Michael Biebl :
>
> Am Fr., 9. Sept. 2022 um 14:01 Uhr schrieb Ulrich Windl
> :
> >
> > >>> Andrei Borzenkov schrieb am 09.09.2022 um 13:41 in
> > Nachricht
> > :
> > > On Fri, Sep 9, 2022 at 2:13 PM Ulrich Windl
> > > wrote:
> > > ...
> > >> >
> > >> > If you are interested in services that pull in e.g. time-sync.target
> > >> > via Wants (or Requires) and order themselves before the target, you
> > >> > can use something like
> > >> > $ systemctl show time-sync.target -p WantedBy -p RequiredBy -p After
> > >> > RequiredBy=
> > >> > WantedBy=chrony.service
> > >> > After=chrony.service time-set.target
> > >>
> > >> It seems what I wanted to know is output by
> > >> # systemctl show -p After time-set.target
> > >> After=systemd-timesyncd.service
> > >> # systemctl show -p After time-sync.target
> > >> After=time-set.target ntp-wait.service
> > >>
> > >> However the "After=" is somewhat unexpected.
> > >
> > > This is exactly what targets are about. The only usage for targets is
> > > to wait until something else becomes active and to do it they must
> > > come After something.
> > >
> > >> And "-p WantedBy" is definitely
> > >> wrong (it will output units that "require the target", not the units
> > > "providing
> > >> the target").
> > >>
> > >
> > > There is no such thing as "units providing the target". Systemd
> > > documentation makes distinction between targets that Want other units
> > > ("active") and targets that are WantedBy other units ("passive"). It
> > > is expected that services "providing" passive targets have
> > > WantedBy=this-passive.target, otherwise passive targets will not be
> > > activated at all. So WantedBy is exactly correct in this case.
> >
> > Hi!
> >
> > But when I include it (as suggested) I get:
> > # systemctl show -p WantedBy -p RequiredBy -p After time-sync.target
> > RequiredBy=
> > WantedBy=iotwatch@ROOT.service iotwatch@VPM.service
> > iotwatch-generator.service ntp-wait.service systemd-timesyncd.service
> > After=time-set.target ntp-wait.service
> > ---
> >
> > Those iotwatch* units use "Before="; so is the WantedBy= incorrect for
> > those?
> >
> > Those units use:
> > Wants=nss-user-lookup.target time-sync.target paths.target
> > After=nss-user-lookup.target time-sync.target paths.target
>
>
> See man systemd.special, passive and active targets (as Andrei already
> hinted at).
> Quoting the relevant parts
> " Special Passive System Units
>A number of special system targets are defined that can be used
> to properly order boot-up of optional services. These targets are
> generally not part of the initial boot transaction, unless they are
> explicitly pulled in by one of the implementing
>services. Note specifically that these passive target units are
> generally not pulled in by the consumer of a service, but by the
> provider of the service.
> "
> iotwatch* does appear to be a consumer of the time-sync.target, so it
> should merely have an ordering but not pull in the target.
Quoting the rest of the man page section:
"
This means: a consuming service should order itself after these
targets (as appropriate), but not
pull it in. A providing service should order itself before these
targets (as appropriate) and pull it in (via a Wants= type
dependency).
"
Re: [systemd-devel] Antw: Re: Re: [EXT] Re: Q: Querying units for "what provides" a target
Am Fr., 9. Sept. 2022 um 14:01 Uhr schrieb Ulrich Windl
:
>
> >>> Andrei Borzenkov schrieb am 09.09.2022 um 13:41 in
> Nachricht
> :
> > On Fri, Sep 9, 2022 at 2:13 PM Ulrich Windl
> > wrote:
> > ...
> >> >
> >> > If you are interested in services that pull in e.g. time-sync.target
> >> > via Wants (or Requires) and order themselves before the target, you
> >> > can use something like
> >> > $ systemctl show time-sync.target -p WantedBy -p RequiredBy -p After
> >> > RequiredBy=
> >> > WantedBy=chrony.service
> >> > After=chrony.service time-set.target
> >>
> >> It seems what I wanted to know is output by
> >> # systemctl show -p After time-set.target
> >> After=systemd-timesyncd.service
> >> # systemctl show -p After time-sync.target
> >> After=time-set.target ntp-wait.service
> >>
> >> However the "After=" is somewhat unexpected.
> >
> > This is exactly what targets are about. The only usage for targets is
> > to wait until something else becomes active and to do it they must
> > come After something.
> >
> >> And "-p WantedBy" is definitely
> >> wrong (it will output units that "require the target", not the units
> > "providing
> >> the target").
> >>
> >
> > There is no such thing as "units providing the target". Systemd
> > documentation makes distinction between targets that Want other units
> > ("active") and targets that are WantedBy other units ("passive"). It
> > is expected that services "providing" passive targets have
> > WantedBy=this-passive.target, otherwise passive targets will not be
> > activated at all. So WantedBy is exactly correct in this case.
>
> Hi!
>
> But when I include it (as suggested) I get:
> # systemctl show -p WantedBy -p RequiredBy -p After time-sync.target
> RequiredBy=
> WantedBy=iotwatch@ROOT.service iotwatch@VPM.service
> iotwatch-generator.service ntp-wait.service systemd-timesyncd.service
> After=time-set.target ntp-wait.service
> ---
>
> Those iotwatch* units use "Before="; so is the WantedBy= incorrect for those?
>
> Those units use:
> Wants=nss-user-lookup.target time-sync.target paths.target
> After=nss-user-lookup.target time-sync.target paths.target
See man systemd.special, passive and active targets (as Andrei already
hinted at).
Quoting the relevant parts
" Special Passive System Units
A number of special system targets are defined that can be used
to properly order boot-up of optional services. These targets are
generally not part of the initial boot transaction, unless they are
explicitly pulled in by one of the implementing
services. Note specifically that these passive target units are
generally not pulled in by the consumer of a service, but by the
provider of the service.
"
iotwatch* does appear to be a consumer of the time-sync.target, so it
should merely have an ordering but not pull in the target.
[systemd-devel] Antw: Re: Antw: Re: Re: [EXT] Re: Q: Querying units for "what provides" a target
>>> Andrei Borzenkov schrieb am 09.09.2022 um 13:41 in
Nachricht
:
> On Fri, Sep 9, 2022 at 2:13 PM Ulrich Windl
> wrote:
> ...
>> >
>> > If you are interested in services that pull in e.g. time-sync.target
>> > via Wants (or Requires) and order themselves before the target, you
>> > can use something like
>> > $ systemctl show time-sync.target -p WantedBy -p RequiredBy -p After
>> > RequiredBy=
>> > WantedBy=chrony.service
>> > After=chrony.service time-set.target
>>
>> It seems what I wanted to know is output by
>> # systemctl show -p After time-set.target
>> After=systemd-timesyncd.service
>> # systemctl show -p After time-sync.target
>> After=time-set.target ntp-wait.service
>>
>> However the "After=" is somewhat unexpected.
>
> This is exactly what targets are about. The only usage for targets is
> to wait until something else becomes active and to do it they must
> come After something.
>
>> And "-p WantedBy" is definitely
>> wrong (it will output units that "require the target", not the units
> "providing
>> the target").
>>
>
> There is no such thing as "units providing the target". Systemd
> documentation makes distinction between targets that Want other units
> ("active") and targets that are WantedBy other units ("passive"). It
> is expected that services "providing" passive targets have
> WantedBy=this-passive.target, otherwise passive targets will not be
> activated at all. So WantedBy is exactly correct in this case.
Hi!
But when I include it (as suggested) I get:
# systemctl show -p WantedBy -p RequiredBy -p After time-sync.target
RequiredBy=
WantedBy=iotwatch@ROOT.service iotwatch@VPM.service iotwatch-generator.service
ntp-wait.service systemd-timesyncd.service
After=time-set.target ntp-wait.service
---
Those iotwatch* units use "Before="; so is the WantedBy= incorrect for those?
Those units use:
Wants=nss-user-lookup.target time-sync.target paths.target
After=nss-user-lookup.target time-sync.target paths.target
Regards,
Ulrich
Re: [systemd-devel] Antw: Re: Re: [EXT] Re: Q: Querying units for "what provides" a target
On Fri, Sep 9, 2022 at 2:13 PM Ulrich Windl
wrote:
...
> >
> > If you are interested in services that pull in e.g. time-sync.target
> > via Wants (or Requires) and order themselves before the target, you
> > can use something like
> > $ systemctl show time-sync.target -p WantedBy -p RequiredBy -p After
> > RequiredBy=
> > WantedBy=chrony.service
> > After=chrony.service time-set.target
>
> It seems what I wanted to know is output by
> # systemctl show -p After time-set.target
> After=systemd-timesyncd.service
> # systemctl show -p After time-sync.target
> After=time-set.target ntp-wait.service
>
> However the "After=" is somewhat unexpected.
This is exactly what targets are about. The only usage for targets is
to wait until something else becomes active and to do it they must
come After something.
> And "-p WantedBy" is definitely
> wrong (it will output units that "require the target", not the units
> "providing
> the target").
>
There is no such thing as "units providing the target". Systemd
documentation makes distinction between targets that Want other units
("active") and targets that are WantedBy other units ("passive"). It
is expected that services "providing" passive targets have
WantedBy=this-passive.target, otherwise passive targets will not be
activated at all. So WantedBy is exactly correct in this case.
[systemd-devel] Antw: Re: Re: [EXT] Re: Q: Querying units for "what provides" a target
>>> Michael Biebl schrieb am 09.09.2022 um 12:54 in Nachricht : > Am Fr., 9. Sept. 2022 um 12:31 Uhr schrieb Michael Biebl : >> >> Am Fr., 9. Sept. 2022 um 12:08 Uhr schrieb Ulrich Windl >> : >> > >> > >>> Michael Biebl schrieb am 09.09.2022 um 10:55 in >> > Nachricht >> > : >> > > Example: syslog.service >> > > >> > > $ systemctl status syslog.service >> > > ● rsyslog.service - System Logging Service >> > > Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; >> > > preset: enabled) >> > > Active: active (running) since Thu 2022-09-08 08:55:45 CEST; 1 day 1h >> > > ago >> > > TriggeredBy: ● syslog.socket >> > >Docs: man:rsyslogd(8) >> > > man:rsyslog.conf(5) >> > > https://www.rsyslog.com/doc/ >> > >Main PID: 624 (rsyslogd) >> > > Tasks: 4 (limit: 19002) >> > > Memory: 3.8M >> > > CPU: 1.341s >> > > CGroup: /system.slice/rsyslog.service >> > > └─624 /usr/sbin/rsyslogd -n -iNONE >> > > >> > > You'll see that syslog.service is provided by provided by >> > > rsyslog.service (and the actual name of the file on the disk) >> > > Isn't this what you wanted? If not, I must have misunderstood what you >> > > are looking for. >> > >> > Hi! >> > >> > I'm afraid that does not help: >> > # systemctl status time-set.target >> > ● time-set.target - System Time Set >> > Loaded: loaded (/usr/lib/systemd/system/time-set.target; static) >> > Active: active since Mon 2022-09-05 14:30:42 CEST; 3 days ago >> >Docs: man:systemd.special(7) >> > >> > Now what is actually providing "time-set" (if any)? >> > Does that mean "nothing provides time-set"? >> > >> > Likewise: >> > # systemctl status time-sync.target >> > ● time-sync.target - System Time Synchronized >> > Loaded: loaded (/usr/lib/systemd/system/time-sync.target; static) >> > Active: active since Mon 2022-09-05 14:32:00 CEST; 3 days ago >> >Docs: man:systemd.special(7) >> > >> > Sep 05 14:32:00 host16 systemd[1]: Reached target System Time Synchronized. >> > >> > Clear now? >> >> Not really. >> Are you interested in what services hook into time-sync.target (and >> are ordered before it)? > > If you are interested in services that pull in e.g. time-sync.target > via Wants (or Requires) and order themselves before the target, you > can use something like > $ systemctl show time-sync.target -p WantedBy -p RequiredBy -p After > RequiredBy= > WantedBy=chrony.service > After=chrony.service time-set.target It seems what I wanted to know is output by # systemctl show -p After time-set.target After=systemd-timesyncd.service # systemctl show -p After time-sync.target After=time-set.target ntp-wait.service However the "After=" is somewhat unexpected. And "-p WantedBy" is definitely wrong (it will output units that "require the target", not the units "providing the target"). Regards, Ulrich
[systemd-devel] Antw: Re: Re: [EXT] Re: Q: Querying units for "what provides" a target
>>> Michael Biebl schrieb am 09.09.2022 um 12:31 in Nachricht : > Am Fr., 9. Sept. 2022 um 12:08 Uhr schrieb Ulrich Windl > : >> >> >>> Michael Biebl schrieb am 09.09.2022 um 10:55 in >> Nachricht >> : >> > Example: syslog.service >> > >> > $ systemctl status syslog.service >> > ● rsyslog.service - System Logging Service >> > Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; >> > preset: enabled) >> > Active: active (running) since Thu 2022-09-08 08:55:45 CEST; 1 day 1h >> > ago >> > TriggeredBy: ● syslog.socket >> >Docs: man:rsyslogd(8) >> > man:rsyslog.conf(5) >> > https://www.rsyslog.com/doc/ >> >Main PID: 624 (rsyslogd) >> > Tasks: 4 (limit: 19002) >> > Memory: 3.8M >> > CPU: 1.341s >> > CGroup: /system.slice/rsyslog.service >> > └─624 /usr/sbin/rsyslogd -n -iNONE >> > >> > You'll see that syslog.service is provided by provided by >> > rsyslog.service (and the actual name of the file on the disk) >> > Isn't this what you wanted? If not, I must have misunderstood what you >> > are looking for. >> >> Hi! >> >> I'm afraid that does not help: >> # systemctl status time-set.target >> ● time-set.target - System Time Set >> Loaded: loaded (/usr/lib/systemd/system/time-set.target; static) >> Active: active since Mon 2022-09-05 14:30:42 CEST; 3 days ago >>Docs: man:systemd.special(7) >> >> Now what is actually providing "time-set" (if any)? >> Does that mean "nothing provides time-set"? >> >> Likewise: >> # systemctl status time-sync.target >> ● time-sync.target - System Time Synchronized >> Loaded: loaded (/usr/lib/systemd/system/time-sync.target; static) >> Active: active since Mon 2022-09-05 14:32:00 CEST; 3 days ago >>Docs: man:systemd.special(7) >> >> Sep 05 14:32:00 host16 systemd[1]: Reached target System Time Synchronized. >> >> Clear now? > > Not really. > Are you interested in what services hook into time-sync.target (and > are ordered before it)? Yes. I call it "providing time set/sync". Regards, Ulrich
Re: [systemd-devel] [EXT] Re: Q: Querying units for "what provides" a target
Am Fr., 9. Sept. 2022 um 12:31 Uhr schrieb Michael Biebl : > > Am Fr., 9. Sept. 2022 um 12:08 Uhr schrieb Ulrich Windl > : > > > > >>> Michael Biebl schrieb am 09.09.2022 um 10:55 in > > Nachricht > > : > > > Example: syslog.service > > > > > > $ systemctl status syslog.service > > > ● rsyslog.service - System Logging Service > > > Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; > > > preset: enabled) > > > Active: active (running) since Thu 2022-09-08 08:55:45 CEST; 1 day 1h > > > ago > > > TriggeredBy: ● syslog.socket > > >Docs: man:rsyslogd(8) > > > man:rsyslog.conf(5) > > > https://www.rsyslog.com/doc/ > > >Main PID: 624 (rsyslogd) > > > Tasks: 4 (limit: 19002) > > > Memory: 3.8M > > > CPU: 1.341s > > > CGroup: /system.slice/rsyslog.service > > > └─624 /usr/sbin/rsyslogd -n -iNONE > > > > > > You'll see that syslog.service is provided by provided by > > > rsyslog.service (and the actual name of the file on the disk) > > > Isn't this what you wanted? If not, I must have misunderstood what you > > > are looking for. > > > > Hi! > > > > I'm afraid that does not help: > > # systemctl status time-set.target > > ● time-set.target - System Time Set > > Loaded: loaded (/usr/lib/systemd/system/time-set.target; static) > > Active: active since Mon 2022-09-05 14:30:42 CEST; 3 days ago > >Docs: man:systemd.special(7) > > > > Now what is actually providing "time-set" (if any)? > > Does that mean "nothing provides time-set"? > > > > Likewise: > > # systemctl status time-sync.target > > ● time-sync.target - System Time Synchronized > > Loaded: loaded (/usr/lib/systemd/system/time-sync.target; static) > > Active: active since Mon 2022-09-05 14:32:00 CEST; 3 days ago > >Docs: man:systemd.special(7) > > > > Sep 05 14:32:00 host16 systemd[1]: Reached target System Time Synchronized. > > > > Clear now? > > Not really. > Are you interested in what services hook into time-sync.target (and > are ordered before it)? If you are interested in services that pull in e.g. time-sync.target via Wants (or Requires) and order themselves before the target, you can use something like $ systemctl show time-sync.target -p WantedBy -p RequiredBy -p After RequiredBy= WantedBy=chrony.service After=chrony.service time-set.target
Re: [systemd-devel] [EXT] Re: Q: Querying units for "what provides" a target
Am Fr., 9. Sept. 2022 um 12:08 Uhr schrieb Ulrich Windl : > > >>> Michael Biebl schrieb am 09.09.2022 um 10:55 in > Nachricht > : > > Example: syslog.service > > > > $ systemctl status syslog.service > > ● rsyslog.service - System Logging Service > > Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; > > preset: enabled) > > Active: active (running) since Thu 2022-09-08 08:55:45 CEST; 1 day 1h > > ago > > TriggeredBy: ● syslog.socket > >Docs: man:rsyslogd(8) > > man:rsyslog.conf(5) > > https://www.rsyslog.com/doc/ > >Main PID: 624 (rsyslogd) > > Tasks: 4 (limit: 19002) > > Memory: 3.8M > > CPU: 1.341s > > CGroup: /system.slice/rsyslog.service > > └─624 /usr/sbin/rsyslogd -n -iNONE > > > > You'll see that syslog.service is provided by provided by > > rsyslog.service (and the actual name of the file on the disk) > > Isn't this what you wanted? If not, I must have misunderstood what you > > are looking for. > > Hi! > > I'm afraid that does not help: > # systemctl status time-set.target > ● time-set.target - System Time Set > Loaded: loaded (/usr/lib/systemd/system/time-set.target; static) > Active: active since Mon 2022-09-05 14:30:42 CEST; 3 days ago >Docs: man:systemd.special(7) > > Now what is actually providing "time-set" (if any)? > Does that mean "nothing provides time-set"? > > Likewise: > # systemctl status time-sync.target > ● time-sync.target - System Time Synchronized > Loaded: loaded (/usr/lib/systemd/system/time-sync.target; static) > Active: active since Mon 2022-09-05 14:32:00 CEST; 3 days ago >Docs: man:systemd.special(7) > > Sep 05 14:32:00 host16 systemd[1]: Reached target System Time Synchronized. > > Clear now? Not really. Are you interested in what services hook into time-sync.target (and are ordered before it)?
[systemd-devel] Antw: Re: [EXT] Re: Q: Querying units for "what provides" a target
>>> Michael Biebl schrieb am 09.09.2022 um 10:55 in Nachricht : > Example: syslog.service > > $ systemctl status syslog.service > ● rsyslog.service - System Logging Service > Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; > preset: enabled) > Active: active (running) since Thu 2022-09-08 08:55:45 CEST; 1 day 1h > ago > TriggeredBy: ● syslog.socket >Docs: man:rsyslogd(8) > man:rsyslog.conf(5) > https://www.rsyslog.com/doc/ >Main PID: 624 (rsyslogd) > Tasks: 4 (limit: 19002) > Memory: 3.8M > CPU: 1.341s > CGroup: /system.slice/rsyslog.service > └─624 /usr/sbin/rsyslogd -n -iNONE > > You'll see that syslog.service is provided by provided by > rsyslog.service (and the actual name of the file on the disk) > Isn't this what you wanted? If not, I must have misunderstood what you > are looking for. Hi! I'm afraid that does not help: # systemctl status time-set.target ● time-set.target - System Time Set Loaded: loaded (/usr/lib/systemd/system/time-set.target; static) Active: active since Mon 2022-09-05 14:30:42 CEST; 3 days ago Docs: man:systemd.special(7) Now what is actually providing "time-set" (if any)? Does that mean "nothing provides time-set"? Likewise: # systemctl status time-sync.target ● time-sync.target - System Time Synchronized Loaded: loaded (/usr/lib/systemd/system/time-sync.target; static) Active: active since Mon 2022-09-05 14:32:00 CEST; 3 days ago Docs: man:systemd.special(7) Sep 05 14:32:00 host16 systemd[1]: Reached target System Time Synchronized. Clear now? Regards, Ulrich > > Am Fr., 9. Sept. 2022 um 10:52 Uhr schrieb Ulrich Windl > : >> >> >>> Michael Biebl schrieb am 09.09.2022 um 10:30 in Nachricht >> : >> > I'd probably just use `systemctl status` >> >> Can you give some details? I don't see what I'm expecting to see. >> >> Regards, >> Ulrich >> >> >> > >> > Am Fr., 9. Sept. 2022 um 10:18 Uhr schrieb Ulrich Windl >> > : >> >> >> >> Hi! >> >> >> >> I'm wondering: having some specific target, e.g. time-set.target, how can I >> > find out what actually "provides" that target? >> >> I see that I can query what "requires" the given target, but how to I get >> > the other direction? >> >> I mean by using a tool like systemctl, not by finding and grepping some >> > directories for symbolic links. >> >> >> >> Sorry if that turns out to be a stupid question where I should have known >> > the answer... >> >> >> >> Regards, >> >> Ulrich >> >> >> >> >> >> >> >> >> >>
Re: [systemd-devel] networkd : ipv6 prefix delegation
Yes, this. There's no benefit to disabling link-local addressing, and doing so can definitely break other IPv6 features. I've never seen an explicitly-configured link-local address before, but I'd be really surprised if it worked as a replacement for the automatically-generated link-local address. Manually configured link local adresses are quite common on routers. And there is no reason, why it should not work, but having simpler addresses on gateways can make some sense. After all, where is the difference between a random, a RFC7217 stable private or manual address? To emphasise it again: It is not about disabling link local addressing, that is not, what the stanza does, it is about optionally disabling _auto_configuration.
Re: [systemd-devel] [EXT] Re: Q: Querying units for "what provides" a target
Example: syslog.service $ systemctl status syslog.service ● rsyslog.service - System Logging Service Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; preset: enabled) Active: active (running) since Thu 2022-09-08 08:55:45 CEST; 1 day 1h ago TriggeredBy: ● syslog.socket Docs: man:rsyslogd(8) man:rsyslog.conf(5) https://www.rsyslog.com/doc/ Main PID: 624 (rsyslogd) Tasks: 4 (limit: 19002) Memory: 3.8M CPU: 1.341s CGroup: /system.slice/rsyslog.service └─624 /usr/sbin/rsyslogd -n -iNONE You'll see that syslog.service is provided by provided by rsyslog.service (and the actual name of the file on the disk) Isn't this what you wanted? If not, I must have misunderstood what you are looking for. Am Fr., 9. Sept. 2022 um 10:52 Uhr schrieb Ulrich Windl : > > >>> Michael Biebl schrieb am 09.09.2022 um 10:30 in > >>> Nachricht > : > > I'd probably just use `systemctl status` > > Can you give some details? I don't see what I'm expecting to see. > > Regards, > Ulrich > > > > > > Am Fr., 9. Sept. 2022 um 10:18 Uhr schrieb Ulrich Windl > > : > >> > >> Hi! > >> > >> I'm wondering: having some specific target, e.g. time-set.target, how can I > > find out what actually "provides" that target? > >> I see that I can query what "requires" the given target, but how to I get > > the other direction? > >> I mean by using a tool like systemctl, not by finding and grepping some > > directories for symbolic links. > >> > >> Sorry if that turns out to be a stupid question where I should have known > > the answer... > >> > >> Regards, > >> Ulrich > >> > >> > >> > > > >
[systemd-devel] Antw: [EXT] Re: Q: Querying units for "what provides" a target
>>> Michael Biebl schrieb am 09.09.2022 um 10:30 in Nachricht : > I'd probably just use `systemctl status` Can you give some details? I don't see what I'm expecting to see. Regards, Ulrich > > Am Fr., 9. Sept. 2022 um 10:18 Uhr schrieb Ulrich Windl > : >> >> Hi! >> >> I'm wondering: having some specific target, e.g. time-set.target, how can I > find out what actually "provides" that target? >> I see that I can query what "requires" the given target, but how to I get > the other direction? >> I mean by using a tool like systemctl, not by finding and grepping some > directories for symbolic links. >> >> Sorry if that turns out to be a stupid question where I should have known > the answer... >> >> Regards, >> Ulrich >> >> >>
Re: [systemd-devel] Q: Querying units for "what provides" a target
I'd probably just use `systemctl status` Am Fr., 9. Sept. 2022 um 10:18 Uhr schrieb Ulrich Windl : > > Hi! > > I'm wondering: having some specific target, e.g. time-set.target, how can I > find out what actually "provides" that target? > I see that I can query what "requires" the given target, but how to I get the > other direction? > I mean by using a tool like systemctl, not by finding and grepping some > directories for symbolic links. > > Sorry if that turns out to be a stupid question where I should have known the > answer... > > Regards, > Ulrich > > >
[systemd-devel] Q: Querying units for "what provides" a target
Hi! I'm wondering: having some specific target, e.g. time-set.target, how can I find out what actually "provides" that target? I see that I can query what "requires" the given target, but how to I get the other direction? I mean by using a tool like systemctl, not by finding and grepping some directories for symbolic links. Sorry if that turns out to be a stupid question where I should have known the answer... Regards, Ulrich
