[systemd-devel] systemd-networkd: How to configure network with environment variables?

[Paul Menzel]

Dear systemd folks,


Due to historical reasons, in our environment we have a configuration 
file with the network device name and the to be assigned IP address:


$ more /etc/local/mxhost.conf
MX_NETDEV=net02
MX_IPADDR=141.14.18.X

Then a custom service unit `network.service` [1] configures the network 
with the configuration file as environment file.


[Unit]
Description=Network Connectivity
DefaultDependencies=no

[Service]
EnvironmentFile=/etc/local/mxhost.conf
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/mxnetctl start
ExecStart=/sbin/ip addr add ${MX_IPADDR}/20 broadcast 141.14.31.255 
dev ${MX_NETDEV}

ExecStart=/sbin/ip link set up dev ${MX_NETDEV}
ExecStart=/sbin/ip route add default via 141.14.16.X
ExecStop=/sbin/ip addr del ${MX_IPADDR}/20 dev ${MX_NETDEV}
StandardOutput=syslog

[Install]
WantedBy=network.target

Wanting to use systemd-network but keeping local device configuration in 
`/etc/local` is there an easy way? systemd.network(5) does not say 
anything about, that environment variables could be used.


If that does not work, do you have another suggestion? Possible, but not 
nice, solutions, I came up with:


1.  Use a generator to create .network files from `/etc/local/mxhost.conf`.

2.  Convert `/etc/local/mxhost.conf` manually to 
`/etc/local/mxhost.network` and add a symbolic link from 
`/etc/systemd/network` to that file.



Kind regards,

Paul


[1]: 
https://github.molgen.mpg.de/mariux64/mxtools/blob/master/misc_systemd_units/network.service

[2]: https://www.freedesktop.org/software/systemd/man/systemd.network.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: one more time: SCSI device identification

[Martin K. Petersen]

Martin,

> I suppose 99.9% of users never bother with customizing the udev rules.

Except for the other 99.9%, perhaps? :) We definitely have many users
that tweak udev storage rules for a variety of reasons. Including being
able to use RII for LUN naming purposes.

> But we can actually combine both approaches. If "wwid" yields a good
> value most of the time (which is true IMO), we could make user space
> rely on it by default, and make it possible to set an udev property
> (e.g. ENV{ID_LEGACY}="1") to tell udev rules to determine WWID
> differently. User-space apps like multipath could check the ID_LEGACY
> property to determine whether or not reading the "wwid" attribute would
> be consistent with udev. That would simplify matters a lot for us (Ben,
> do you agree?), without the need of adding endless BLIST entries.

That's fine with me.

> AFAICT, no major distribution uses "wwid" for this purpose (yet).

We definitely have users that currently rely on wwid, although probably
not through standard distro scripts.

> In a recent discussion with Hannes, the idea came up that the priority
> of "SCSI name string" designators should actually depend on their
> subtype. "naa." name strings should map to the respective NAA
> descriptors, and "eui.", likewise (only "iqn." descriptors have no
> binary counterpart; we thought they should rather be put below NAA,
> prio-wise).

I like what NVMe did wrt. to exporting eui, nguid, uuid separately from
the best-effort wwid. That's why I suggested separate sysfs files for
the various page 0x83 descriptors. I like the idea of being able to
explicitly ask for an eui if that's what I need. But that appears to be
somewhat orthogonal to your request.

> I wonder if you'd agree with a change made that way for "wwid". I
> suppose you don't. I'd then propose to add a new attribute following
> this logic. It could simply be an additional attribute with a different
> name. Or this new attribute could be a property of the block device
> rather than the SCSI device, like NVMe does it
> (/sys/block/nvme0n2/wwid).

That's fine. I am not a big fan of the idea that block/foo/wwid and
block/foo/device/wwid could end up being different. But I do think that
from a userland tooling perspective the consistency with NVMe is more
important.

-- 
Martin K. Petersen  Oracle Linux Engineering
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Alias for template/instance service unit

[Hans Gruber]

Hello,
I am having problems with the aliases and "Alias=' directive related to the 
template service unit.
According to https://www.freedesktop.org/software/systemd/man/systemd.unit.html

> "A template instance may only be aliased by another template instance, and 
> the instance part must be identical. A template may be aliased by another 
> template (in which case the alias applies to all instances of the template). 
> As a special case, a template instance (e.g. "alias@inst.service") may be a 
> symlink to different template (e.g. "template@inst.service"). In that case, 
> just this specific instance is aliased, while other instances of the template 
> (e.g. "alias@foo.service", "alias@bar.service") are not aliased. Those rule 
> preserve the requirement that the instance (if any) is always uniquely 
> defined for a given unit and all its aliases."
I have exactly these two cases and requirements and cannot find example.
>  "A template may be aliased by another template (in which case the alias 
>applies to all instances of the template)"

eg: How to create an alias using `Alias=` for a service template core@.service 
which will have maybe 8 or 16 instances (eg: core@cpu01.service 
core@cpu02.service ..) which will apply to all instances when enabled using eg 
allcores@.service.

> "As a special case, a template instance (e.g. "alias@inst.service") may be a 
> symlink to different template (e.g. "template@inst.service"). In that case, 
> just this specific instance is aliased, while other instances of the template 
> (e.g. "alias@foo.service", "alias@bar.service") are not aliased"

eg: How to create an alias using `Alias=` for a service template 
tailoutput@.service which will have maybe 2 instances (eg: 
tailoutput@tty11.service tailoutput@tty12.service ..) which will apply to only 
instance tailoutput@tty12.service when enabled using eg: 
tty12-tailoutput@tty12.service.

I can't apply any alias using "Alias=" directive for two different template 
.service unit.Whatever I use for "Alias=" directive in the two cases inside the 
templates, instance service works, all symlink are created when instance is 
enabled, instance services are started as expected using their names, but all 
alias are always reporting
"Loaded: error (Reason: unit alasname failed to load properly: File exists)"

Alias=allcores@.service
Alias=allcores@%i.serviceAlias=alias@*.service
Alias=tty12-tailoutput@%i.service
Alias=%i-tailoutput@.service
Alias=alias@tty12.serviceAlias=alias-%n

Thank you in advance.
Regards

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

Re: [systemd-devel] Alias for template/instance service unit

[Hans Gruber]

 Hello,
Thank you for your really appreciated advice. 
I confirm that I misunderstood what "applies to all instances" means.So now 
seems clear. Thanks
But there is something I don't understand.

I have two templates.The second one which is a simple instance of a tail > 
/dev/ttyX under tail@.serviceI renamed it to foo@.service (I don't have 
something which have foo* or bar* as name and previous tail@.service doesn't 
not exist anymore)

I have this [Install] 
Section:WantedBy=getty.targetDefaultInstance=tty12Alias=bar@.service
systemctl enable foo@tty12.service> Created symlink 
/etc/systemd/system/bar@tty12.service => /etc/systemd/system/foo@.service> 
Created symlink /etc/systemd/system/getty.target.wants/foo@tty12.service => 
/etc/systemd/system/foo@service
Systemctl status bar@tty12.service> Loaded: error (Reason: Unit 
bar@tty12.service to load properly: File Exists)
Systemctl start bar@tty12.service = KO> Failed to start bar@tty12.service: Unit 
bar@tty12.service failed to load properly: File Exists.> See system logs and 
systemctl status bar@tty12.service for details
Systemctl start foo@tty12.service = OK
RegardsHans


Le jeudi 22 avril 2021 à 20:49:52 UTC+2, Mantas Mikulėnas 
 a écrit :  
 
 On Thu, Apr 22, 2021 at 9:18 PM Hans Gruber  wrote:

Hello,
I am having problems with the aliases and "Alias=' directive related to the 
template service unit.
According to https://www.freedesktop.org/software/systemd/man/systemd.unit.html

> "A template instance may only be aliased by another template instance, and 
> the instance part must be identical. A template may be aliased by another 
> template (in which case the alias applies to all instances of the template). 
> As a special case, a template instance (e.g. "alias@inst.service") may be a 
> symlink to different template (e.g. "template@inst.service"). In that case, 
> just this specific instance is aliased, while other instances of the template 
> (e.g. "alias@foo.service", "alias@bar.service") are not aliased. Those rule 
> preserve the requirement that the instance (if any) is always uniquely 
> defined for a given unit and all its aliases."
I have exactly these two cases and requirements and cannot find example.
>  "A template may be aliased by another template (in which case the alias 
>applies to all instances of the template)"

eg: How to create an alias using `Alias=` for a service template core@.service 
which will have maybe 8 or 16 instances (eg: core@cpu01.service 
core@cpu02.service ..) which will apply to all instances when enabled using eg 
allcores@.service.


I think you're misunderstanding what "applies to all instances" means. It does 
not give you a super-unit that controls all instances in unison -- rather, it 
gives you a template alias that will provide an alias for *each instance 
individually*.
But one instance is still aliased to one instance. For example, if you alias 
foo@.service => bar@.service, then you automatically get foo@cpu1.service => 
bar@cpu1.service, and so on. That's what template aliases do.
If you want to control multiple instances at once, you might be looking for two 
other features:1. Custom target units, which allow you to *start* all instances 
at once;
2. Wildcard support in `systemctl` commands, which allows you to see the status 
of all loaded instances at once (systemctl status "foo@*.service").
-- 
Mantas Mikulėnas  ___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is there a way to know inside of systemd if it's in a reboot state?

[Lennart Poettering]

On Mo, 19.04.21 20:19, Tia, Javier (javier@hpe.com) wrote:

> Hi,
>
> Is there a way to know inside of systemd if it's in a reboot state?

systemctl is-system-running

Lennart

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

Re: [systemd-devel] Is there a way to know inside of systemd if it's in a reboot state?

[Tia, Javier]

I had to make a little change to systemctl to use a file as a flag when 
the system is rebooting. Likely, this a use case that most people would 
not be interested in. And it might exist a better way to do it. Anyway, 
this is the patch:

diff --git a/src/basic/fs-util.h b/src/basic/fs-util.h
index 1f0bdd95b3..9643763d13 100644
--- a/src/basic/fs-util.h
+++ b/src/basic/fs-util.h
@@ -16,6 +16,8 @@

  #define MODE_INVALID ((mode_t) -1)

+#define REBOOTING_FILE "/run/systemd/is-rebooting"
+
  /* The following macros add 1 when converting things, since 0 is a 
valid mode, while the pointer
   * NULL is special */
  #define PTR_TO_MODE(p) ((mode_t) ((uintptr_t) (p)-1))
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 5ac40be4a7..652b1af12f 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -3587,6 +3587,10 @@ static int start_special(int argc, char *argv[], 
void *userdata) {
  bool termination_action; /* an action that terminates the manager,
* can be performed also by signal. */

+r = touch(REBOOTING_FILE);
+if (r < 0)
+log_debug_errno(r, "Failed to touch %s, ignoring: %m", 
  REBOOTING_FILE);
+
  assert(argv);

  a = verb_to_action(argv[0]);
@@ -9089,6 +9093,10 @@ static int logind_schedule_shutdown(void) {
  static int halt_main(void) {
  int r;

+r = touch(REBOOTING_FILE);
+if (r < 0)
+log_debug_errno(r, "Failed to touch %s, ignoring: %m", 
REBOOTING_FILE);
+
  r = logind_check_inhibitors(arg_action);
  if (r < 0)
  return r;

▷ Javier's 🖊

On 4/19/21 2:19 PM, Tia, Javier wrote:
> Hi,
> 
> Is there a way to know inside of systemd if it's in a reboot state?
> 
> Something like the Linux kernel does [1], keeping the system state in a
> variable.
> 
> [1]
> https://elixir.bootlin.com/linux/v4.19.98/source/include/linux/kernel.h#L581
> 
> ▷ Javier's 🖊
> ___
> 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] "Correct" way to obtain DHCP lease info?

[Bruce A. Johnson]

On 22/04/2021 16:14, Bruce A. Johnson wrote:
I'm still trying to get an explanation of why having a valid DHCP 
address is not in itself good enough. 
Correction: I'm still trying to get an explanation from my requirements 
person :facepalm:


Bruce A. Johnson | Firmware Engineer
Blue Ridge Networks, Inc.
14120 Parke Long Court Suite 103 | Chantilly, VA 20151
Main: 1.800.722.1168 | Direct: 703-633-7332
http://www.blueridgenetworks.com
OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/





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

Re: [systemd-devel] "Correct" way to obtain DHCP lease info?

[Bruce A. Johnson]

I'm still trying to get an explanation of why having a valid DHCP 
address is not in itself good enough. The only reason I've been able to 
see is that after the lease is issued, and before the time comes to 
refresh the lease, there could be a communication failure somewhere 
between the switch the DHCP client is on and the home office where the 
DHCP server is. One would assume that application failures would be a 
reasonable clue Regardless, it seems to me that it's not 
unreasonable for an application outside of systemd-networkd to be able 
to obtain the DHCP lease information. Am I off base here?


Bruce A. Johnson | Firmware Engineer
Blue Ridge Networks, Inc.
14120 Parke Long Court Suite 103 | Chantilly, VA 20151
Main: 1.800.722.1168 | Direct: 703-633-7332
http://www.blueridgenetworks.com
OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/

On 22/04/2021 12:00, Mantas Mikulėnas wrote:
On Thu, Apr 22, 2021 at 6:17 PM Bruce A. Johnson 
> wrote:


Silvio, thanks for the suggestion. I'm not concerned with keeping
the lease forever; the system actually experiences a topology
change as it's switched from one network to another, and I can
catch that from the DBus events that occur. The problem we're
trying to solve is to contact some address that we're sure exists
on the network, without knowing anything about that network. The
default gateway was an obvious choice, but someone wants to cover
the case of there being a private LAN with no gateway. The only
other choice I could see is the DHCP server that issues the lease.

Hmm, don't you also have the case of there being a private LAN with no 
gateway and no DHCP? Or possibly the case of a DHCP relay. And since 
you don't know anything about the network, you also don't know whether 
the address will respond to your communication attempts (other than 
ARP) -- it might be pingable but it might be not.


I'm curious about what brought this problem into existence in the 
first place. Why *is* it necessary to contact a random address within 
the network? (If it's to check that the physical interface is working, 
then just the fact that you somehow acquired a lease would be enough. no?)


--
Mantas Mikulėnas


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

Re: [systemd-devel] Alias for template/instance service unit

[Mantas Mikulėnas]

On Thu, Apr 22, 2021 at 9:18 PM Hans Gruber  wrote:

> Hello,
>
> I am having problems with the aliases and "Alias=' directive related to
> the template service unit.
>
> According to
> https://www.freedesktop.org/software/systemd/man/systemd.unit.html
>
> > "A template instance may only be aliased by another template instance,
> and the instance part must be identical. A template may be aliased by
> another template (in which case the alias applies to all instances of the
> template). As a special case, a template instance (e.g. "alias@inst.service")
> may be a symlink to different template (e.g. "template@inst.service"). In
> that case, just this specific instance is aliased, while other instances of
> the template (e.g. "alias@foo.service", "alias@bar.service") are not
> aliased. Those rule preserve the requirement that the instance (if any) is
> always uniquely defined for a given unit and all its aliases."
>
> I have exactly these two cases and requirements and cannot find example.
>
> >  "A template may be aliased by another template (in which case the alias
> applies to all instances of the template)"
>
> eg: How to create an alias using `Alias=` for a service template core@.service
> which will have maybe 8 or 16 instances (eg: core@cpu01.service
> core@cpu02.service ..) which will apply to all instances when enabled
> using eg allcores@.service.
>

I think you're misunderstanding what "applies to all instances" means. It
does not give you a super-unit that controls all instances in unison --
rather, it gives you a template alias that will provide an alias for *each
instance individually*.

But one instance is still aliased to one instance. For example, if you
alias foo@.service => bar@.service, then you automatically get
foo@cpu1.service => bar@cpu1.service, and so on. That's what template
aliases do.

If you want to control multiple instances at once, you might be looking for
two other features:
1. Custom target units, which allow you to *start* all instances at once;
2. Wildcard support in `systemctl` commands, which allows you to see the
status of all loaded instances at once (systemctl status "foo@*.service").

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

Re: [systemd-devel] RFC: one more time: SCSI device identification

[Benjamin Marzinski]

On Thu, Apr 22, 2021 at 09:07:15AM +, Martin Wilck wrote:
> On Wed, 2021-04-21 at 22:46 -0400, Martin K. Petersen wrote:
> > 
> > Martin,
> > 
> > > Hm, it sounds intriguing, but it has issues in its own right. For
> > > years to come, user space will have to probe whether these attribute
> > > exist, and fall back to the current ones ("wwid", "vpd_pg83")
> > > otherwise. So user space can't be simplified any time soon. Speaking
> > > for an important user space consumer of WWIDs (multipathd), I doubt
> > > that this would improve matters for us. We'd be happy if the kernel
> > > could just pick the "best" designator for us. But I understand that
> > > the kernel can't guarantee a good choice (user space can't either).
> > 
> > But user space can be adapted at runtime to pick one designator over
> > the
> > other (ha!).
> 
> And that's exactly the problem. Effectively, all user space relies on
> udev today, because that's where this "adaptation" is taking place. It
> happens
> 
>  1) either in systemd's scsi_id built-in 
>
> (https://github.com/systemd/systemd/blob/7feb1dd6544d1bf373dbe13dd33cf563ed16f891/src/udev/scsi_id/scsi_serial.c#L37)
>  2) or in the udev rules coming with sg3_utils 
>
> (https://github.com/hreinecke/sg3_utils/blob/master/scripts/55-scsi-sg3_id.rules)
> 
> 1) is just as opaque and un-"adaptable" as the kernel, and the logic is
> suboptimal. 2) is of course "adaptable", but that's a problem in
> practice, if udev fails to provide a WWID. multipath-tools go through
> various twists for this case to figure out "fallback" WWIDs, guessing
> whether that "fallback" matches what udev would have returned if it had
> worked.
> 
> That's the gist of it - the general frustration about udev among some
> of its heaviest users (talk to the LVM2 maintainers).
> 
> I suppose 99.9% of users never bother with customizing the udev rules.
> IOW, these users might as well just use a kernel-provided value. But
> the remaining 0.1% causes headaches for user-space applications, which
> can't make solid assumptions about the rules. Thus, in a way, the
> flexibility of the rules does more harm than it helps.
> 
> > We could do that in the kernel too, of course, but I'm afraid what
> > the
> > resulting BLIST changes would end up looking like over time.
> 
> That's something we want to avoid, sure.
> 
> But we can actually combine both approaches. If "wwid" yields a good
> value most of the time (which is true IMO), we could make user space
> rely on it by default, and make it possible to set an udev property
> (e.g. ENV{ID_LEGACY}="1") to tell udev rules to determine WWID
> differently. User-space apps like multipath could check the ID_LEGACY
> property to determine whether or not reading the "wwid" attribute would
> be consistent with udev. That would simplify matters a lot for us (Ben,
> do you agree?), without the need of adding endless BLIST entries.
> 

Yeah, as long as ID_LEGACY was changed in a careful manner, so WWIDs
didn't simply change without warning because of an upgrade, a path out
of this complexity is a definitely helpful.

-Ben

> 
> > I am also very concerned about changing what the kernel currently
> > exports in a given variable like "wwid". A seemingly innocuous change
> > to
> > the reported value could lead to a system no longer booting after
> > updating the kernel.
> 
> AFAICT, no major distribution uses "wwid" for this purpose (yet). I
> just recently realized that the kernel's ALUA code refers to it. (*)
> 
> In a recent discussion with Hannes, the idea came up that the priority
> of "SCSI name string" designators should actually depend on their
> subtype. "naa." name strings should map to the respective NAA
> descriptors, and "eui.", likewise (only "iqn." descriptors have no
> binary counterpart; we thought they should rather be put below NAA,
> prio-wise).
> 
> I wonder if you'd agree with a change made that way for "wwid". I
> suppose you don't. I'd then propose to add a new attribute following
> this logic. It could simply be an additional attribute with a different
> name. Or this new attribute could be a property of the block device
> rather than the SCSI device, like NVMe does it
> (/sys/block/nvme0n2/wwid).
> 
> I don't like the idea of having separate sysfs attributes for
> designators of different types, that's impractical for user space.
> 
> > But taking a step back: Other than "it's not what userland currently
> > does", what specifically is the problem with designator_prio()? We've
> > picked the priority list once and for all. If we promise never to
> > change
> > it, what is the issue?
> 
> If the prioritization in kernel and user space was the same, we could
> migrate away from udev more easily without risking boot failure.
> 
> Thanks,
> Martin
> 
> (*) which is an argument for using "wwid" in user space too - just to
> be consitent with the kernel's internal logic.
> 
> -- 
> Dr. Martin Wilck , Tel. +49 (0)911 74053 2107
> SUSE Software Solutions Germa

Re: [systemd-devel] systemctl reboot get terminated by signal 15

[Pengpeng Sun]

Hi Lennart,

After installed a signal handler for SIGTERM and reproduced the issue, got 
si_pid is 1 which is systemd.

Also paste the stderr here:
stderr: 'Bus n/a: changing state UNSET → OPENING
Bus n/a: changing state OPENING → AUTHENTICATING
Executing dbus call org.freedesktop.systemd1.Manager StartUnit(reboot.target, 
replace-irreversibly)
Bus n/a: changing state AUTHENTICATING → RUNNING
Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 
path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=StartUnit cookie=1 reply_cookie=0 signature=ss error-name=n/a 
error-message=n/a
Got message type=method_return sender=org.freedesktop.systemd1 destination=n/a 
path=n/a interface=n/a member=n/a cookie=5 reply_cookie=1 signature=o 
error-name=n/a error-message=n/a
Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 
path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=GetUnit cookie=2 reply_cookie=0 signature=s error-name=n/a 
error-message=n/a
Got message type=method_return sender=org.freedesktop.systemd1 destination=n/a 
path=n/a interface=n/a member=n/a cookie=131 reply_cookie=2 signature=o 
error-name=n/a error-message=n/a
Sent message type=method_call sender=n/a destination=org.freedesktop.systemd1 
path=/org/freedesktop/systemd1/unit/reboot_2etarget 
interface=org.freedesktop.DBus.Properties member=Get cookie=3 reply_cookie=0 
signature=ss error-name=n/a error-message=n/a

What make systemd triggered SIGTERM when calling 'systemd reboot'? 

--
Best regards,
Pengpeng 

On 2021/4/21, 12:48 AM, "Pengpeng Sun"  wrote:

Thanks Lennart!
I reproduced the issue after set "systemd-analyze log-level debug". It 
turns out 'systemctl reboot' triggered before all the steps logged in 
'journalctl -a'. But I did get the stderr of 'systemctl reboot', paste it as 
below, please check if it helps to locate the root cause.
And besides 'journalctl -a', where can I get the systemd debug logs?

stderr: Bus n/a: changing state UNSET → OPENING
Bus n/a: changing state OPENING → AUTHENTICATING
Executing dbus call org.freedesktop.systemd1.Manager 
StartUnit(reboot.target, replace-irreversibly)
Bus n/a: changing state AUTHENTICATING → RUNNING
Sent message type=method_call sender=n/a 
destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=StartUnit cookie=1 
reply_cookie=0 signature=ss error-name=n/a error-message=n/a
Got message type=method_return sender=org.freedesktop.systemd1 
destination=n/a path=n/a interface=n/a member=n/a cookie=5 reply_cookie=1 
signature=o error-name=n/a error-message=n/a
Sent message type=method_call sender=n/a 
destination=org.freedesktop.systemd1 path=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=GetUnit cookie=2 
reply_cookie=0 signature=s error-name=n/a error-message=n/a

--
Best regards,
Pengpeng 

On 2021/4/19, 10:37 PM, "Lennart Poettering"  wrote:

On Mo, 19.04.21 14:29, Pengpeng Sun (pengpe...@vmware.com) wrote:

> Hi there,
>
> Our program executes 'systemctl reboot' in a child process to reboot
> Linux right after its booted, Sometimes there is no error, but
> sometimes the child process terminated due to received uncaught
> signal 15, then no reboot happened. WIFSIGNALED evaluated a non-zero
> value, WTERMSIG evaluated 15. Don't understand why the uncaught
> signal 15 happened here, could you please shed light on this,
> Thanks.

15 is SIGTERM, i.e. the signal sent when a process is politely asked
to shut down. Something is terminating your process.

It could be systemd, could be something else.

To track down what it is, maybe turn on debug logging in systemd, maybe
you find the explanation there. i.e. "systemd-analyze log-level debug"
and then reproduce the issue.

ALternatively, install a signal handler for SIGTERM via sigaction, and
look into the .si_pid field of the siginfo_t you can receive in the
handler. It tells you which processes sent the SIGTERM.

Lennart

--
Lennart Poettering, Berlin


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

Re: [systemd-devel] "Correct" way to obtain DHCP lease info?

[Mantas Mikulėnas]

On Thu, Apr 22, 2021 at 6:17 PM Bruce A. Johnson <
bjohn...@blueridgenetworks.com> wrote:

> Silvio, thanks for the suggestion. I'm not concerned with keeping the
> lease forever; the system actually experiences a topology change as it's
> switched from one network to another, and I can catch that from the DBus
> events that occur. The problem we're trying to solve is to contact some
> address that we're sure exists on the network, without knowing anything
> about that network. The default gateway was an obvious choice, but someone
> wants to cover the case of there being a private LAN with no gateway. The
> only other choice I could see is the DHCP server that issues the lease.
>
Hmm, don't you also have the case of there being a private LAN with no
gateway and no DHCP? Or possibly the case of a DHCP relay. And since you
don't know anything about the network, you also don't know whether the
address will respond to your communication attempts (other than ARP) -- it
might be pingable but it might be not.

I'm curious about what brought this problem into existence in the first
place. Why *is* it necessary to contact a random address within the
network? (If it's to check that the physical interface is working, then
just the fact that you somehow acquired a lease would be enough. no?)

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

Re: [systemd-devel] "Correct" way to obtain DHCP lease info?

[Bruce A. Johnson]

Silvio, thanks for the suggestion. I'm not concerned with keeping the 
lease forever; the system actually experiences a topology change as it's 
switched from one network to another, and I can catch that from the DBus 
events that occur. The problem we're trying to solve is to contact some 
address that we're sure exists on the network, without knowing anything 
about that network. The default gateway was an obvious choice, but 
someone wants to cover the case of there being a private LAN with no 
gateway. The only other choice I could see is the DHCP server that 
issues the lease.


As my thinking has evolved, I really want to get at more DHCP lease 
information when it comes in, like a private DHCP option code that 
conveys something about the environment. I came across a comment 
somewhere that said the only way is to set the systemd-networkd client 
to use debug log level and read from the journal, but isn't there a more 
direct way, like with the Dbus signals that tell subscribers about 
network interface status?


Bruce A. Johnson | Firmware Engineer
Blue Ridge Networks, Inc.
14120 Parke Long Court Suite 103 | Chantilly, VA 20151
Main: 1.800.722.1168 | Direct: 703-633-7332
http://www.blueridgenetworks.com
OpenPGP key ID: 296D1CD6F2B84CAB https://keys.openpgp.org/

On 21/04/2021 15:34, Silvio Knizek wrote:

Am Mittwoch, dem 21.04.2021 um 14:24 -0400 schrieb Bruce A. Johnson:

Is there a correct way to obtain information about the DHCP lease
received by systemd-networkd's DHCP client functionality? It was easy
enough to find SERVER_ADDRESS in /var/run/systemd/netif/leases/4, but
there is a big fat warning stamped at the top of the file:


# This is private data. Do not parse.

I'd like to be able to make a widget that can tell me which DHCP server
issued my lease, how much more time I have, etc., mainly because I want
to be able to ping something that is known to be on the network. I'm
dealing with a lazy sysadmin who doesn't want to put a gateway on this
private network, I haven't found a solution using the CLI tools.

Thanks in advance.

Hi Bruce,

IMHO "having a lease" is not a good metric to determine if you can
access something.
I would suggest something along this line:

--- /etc/systemd/system/internal-network-accessable.target
[Unit]
Description=Internal System Accessable
---
--- /etc/systemd/system/check-if-internal-system-is-accessable.service
[Unit]
Description=Check if internal system can be reached

[Service]
ExecStart=/usr/local/bin/check-if-internal-system-is-accessable.sh
Restart=always

[Install]
WantedBy=multi-user.target
---
--- /usr/local/bin/check-if-internal-system-is-accessable.sh
#!/usr/bin/bash
while :; do
 if wget -q --spider $INTERNAL_RESOURCE; then
 systemctl start internal-network-accessable.target
 else
 systemctl stop internal-network-accessable.target
 fi
 sleep 600
done
---

Than you can check just the status of the .target. You may need to
tweak the lifeness probe, YMMV.

Also in sd-networkd you can configure a .network to never loose its
lease, see man:systemd.network → KeepConfiguration=

HTH
Silvio

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


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

Re: [systemd-devel] RFC: one more time: SCSI device identification

[Martin Wilck]

On Wed, 2021-04-21 at 22:46 -0400, Martin K. Petersen wrote:
> 
> Martin,
> 
> > Hm, it sounds intriguing, but it has issues in its own right. For
> > years to come, user space will have to probe whether these attribute
> > exist, and fall back to the current ones ("wwid", "vpd_pg83")
> > otherwise. So user space can't be simplified any time soon. Speaking
> > for an important user space consumer of WWIDs (multipathd), I doubt
> > that this would improve matters for us. We'd be happy if the kernel
> > could just pick the "best" designator for us. But I understand that
> > the kernel can't guarantee a good choice (user space can't either).
> 
> But user space can be adapted at runtime to pick one designator over
> the
> other (ha!).

And that's exactly the problem. Effectively, all user space relies on
udev today, because that's where this "adaptation" is taking place. It
happens

 1) either in systemd's scsi_id built-in 
   
(https://github.com/systemd/systemd/blob/7feb1dd6544d1bf373dbe13dd33cf563ed16f891/src/udev/scsi_id/scsi_serial.c#L37)
 2) or in the udev rules coming with sg3_utils 
   
(https://github.com/hreinecke/sg3_utils/blob/master/scripts/55-scsi-sg3_id.rules)

1) is just as opaque and un-"adaptable" as the kernel, and the logic is
suboptimal. 2) is of course "adaptable", but that's a problem in
practice, if udev fails to provide a WWID. multipath-tools go through
various twists for this case to figure out "fallback" WWIDs, guessing
whether that "fallback" matches what udev would have returned if it had
worked.

That's the gist of it - the general frustration about udev among some
of its heaviest users (talk to the LVM2 maintainers).

I suppose 99.9% of users never bother with customizing the udev rules.
IOW, these users might as well just use a kernel-provided value. But
the remaining 0.1% causes headaches for user-space applications, which
can't make solid assumptions about the rules. Thus, in a way, the
flexibility of the rules does more harm than it helps.

> We could do that in the kernel too, of course, but I'm afraid what
> the
> resulting BLIST changes would end up looking like over time.

That's something we want to avoid, sure.

But we can actually combine both approaches. If "wwid" yields a good
value most of the time (which is true IMO), we could make user space
rely on it by default, and make it possible to set an udev property
(e.g. ENV{ID_LEGACY}="1") to tell udev rules to determine WWID
differently. User-space apps like multipath could check the ID_LEGACY
property to determine whether or not reading the "wwid" attribute would
be consistent with udev. That would simplify matters a lot for us (Ben,
do you agree?), without the need of adding endless BLIST entries.


> I am also very concerned about changing what the kernel currently
> exports in a given variable like "wwid". A seemingly innocuous change
> to
> the reported value could lead to a system no longer booting after
> updating the kernel.

AFAICT, no major distribution uses "wwid" for this purpose (yet). I
just recently realized that the kernel's ALUA code refers to it. (*)

In a recent discussion with Hannes, the idea came up that the priority
of "SCSI name string" designators should actually depend on their
subtype. "naa." name strings should map to the respective NAA
descriptors, and "eui.", likewise (only "iqn." descriptors have no
binary counterpart; we thought they should rather be put below NAA,
prio-wise).

I wonder if you'd agree with a change made that way for "wwid". I
suppose you don't. I'd then propose to add a new attribute following
this logic. It could simply be an additional attribute with a different
name. Or this new attribute could be a property of the block device
rather than the SCSI device, like NVMe does it
(/sys/block/nvme0n2/wwid).

I don't like the idea of having separate sysfs attributes for
designators of different types, that's impractical for user space.

> But taking a step back: Other than "it's not what userland currently
> does", what specifically is the problem with designator_prio()? We've
> picked the priority list once and for all. If we promise never to
> change
> it, what is the issue?

If the prioritization in kernel and user space was the same, we could
migrate away from udev more easily without risking boot failure.

Thanks,
Martin

(*) which is an argument for using "wwid" in user space too - just to
be consitent with the kernel's internal logic.

-- 
Dr. Martin Wilck , Tel. +49 (0)911 74053 2107
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg GF: Felix Imendörffer


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

Re: [systemd-devel] resolved: wrong address w/ cache off, wo/ querying DNS server

[Lennart Poettering]

On Do, 22.04.21 01:42, Dénes Türei (turei.de...@gmail.com) wrote:

> Dear Systemd Developers,
>
> I got stuck with investigating an issue and I would be very grateful
> for some advice.
> Briefly, systemd-resolved keeps returning a wrong answer to a query,
> despite the cache is disabled. The debug log doesn't show the origin
> of the answer. Systemd-resolved doesn't query the configured DNS
> server when answering this query. If I query the DNS server directly,
> it returns the correct answer. I described the issue in this thread:
> https://bbs.archlinux.org/viewtopic.php?pid=196#p196 -- please
> ignore the starting comment, the last 3 are the most relevant. See
> some system info below the mail.

Maybe your local hostname or an /etc/hosts entry exist that match the
domain name you are looking up?

Lennart

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

Re: [systemd-devel] syscvall-filters killing CGI after update to Fedora 33

[Lennart Poettering]

On Mo, 19.04.21 18:24, Reindl Harald (h.rei...@thelounge.net) wrote:

> after a long time using this SystemCallFilter perl-cgi with Fedora 33 get
> killed - anyone an idea what changed that's obviously covered by the second
> line
>
> SystemCallFilter=@system-service @network-io @privileged
> SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module @mount
> @obsolete @raw-io @reboot @resources @swap

@resources is included in @system-service for a reason: it's syscalls
are typically used by programs. Regular system service use it, and
that's totally OK and expected.

i.e. the basically explicitly created a configuration that can't
work. My recommendation: just drop the second line altogether. Your
first line implements an allowlist already, hence besides the
@resources thing the second line is entirely redundant, and the
@resources stuff you really don't want.

> either the blacklist of the new systemd version convers more than before or
> something changed in the perl stack

Yeah, programs change the APIs they use. System call filters needs to
be put together with an undrstanding what the programs do, and hence
are besten already put togther upstream or by the distro. If you do it
downstream you might run into issues like this.

The idea of @system-service is that it mostly tries to isolate you
from this, but in your case you overrode what it does, so it fell apart.

Lennart

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