Re: [systemd-devel] [EXT] Re: "[Match]" section in systemd.link file doesn't match interface

2020-03-03 Thread Mantas Mikulėnas
On Wed, Mar 4, 2020 at 9:45 AM Ulrich Windl <
ulrich.wi...@rz.uni-regensburg.de> wrote:

> >>> Felix  schrieb am 03.03.2020 um 15:20 in
> Nachricht
>
> <28933_1583245223_5E5E67A7_28933_1176_1_13488396-f23a-8701-3f64-260f060119d5@ham
> e.net>:
> > Thank you for your help! I've found my problem and it was way simpler
> > than I thought.
> >
> > The systemd.link manpage mentions:
> > "The first (in lexical order) of the link files that matches a given
> > device is applied. Note that a default file 99-default.link is shipped
> > by the system. Any user-supplied .link should hence have a lexically
> > earlier name to be considered at all."
> >
> > My .link file wasn't considered because its file name came lexically
> > after '99-default.link'.
>
> A word of warning: With Unicode collating sequences the ordering of such
> files can sometimes be "unexpected" (e.g. comparing '-' with '.').
>

AFAIK systemd itself always uses ASCIIbetical order (as it should). So it
might not match with `ls` and `sort`, true, but at least it should work
consistently regardless of locale.

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


[systemd-devel] Antw: [EXT] Re: "[Match]" section in systemd.link file doesn't match interface

2020-03-03 Thread Ulrich Windl
>>> Felix  schrieb am 03.03.2020 um 15:20 in 
>>> Nachricht
<28933_1583245223_5E5E67A7_28933_1176_1_13488396-f23a-8701-3f64-260f060119d5@ham
e.net>:
> Thank you for your help! I've found my problem and it was way simpler
> than I thought.
> 
> The systemd.link manpage mentions:
> "The first (in lexical order) of the link files that matches a given
> device is applied. Note that a default file 99-default.link is shipped
> by the system. Any user-supplied .link should hence have a lexically
> earlier name to be considered at all."
> 
> My .link file wasn't considered because its file name came lexically
> after '99-default.link'.

A word of warning: With Unicode collating sequences the ordering of such files 
can sometimes be "unexpected" (e.g. comparing '-' with '.').

[...]


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


Re: [systemd-devel] "[Match]" section in systemd.link file doesn't match interface

2020-03-03 Thread Felix
Thank you for your help! I've found my problem and it was way simpler
than I thought.

The systemd.link manpage mentions:
"The first (in lexical order) of the link files that matches a given
device is applied. Note that a default file 99-default.link is shipped
by the system. Any user-supplied .link should hence have a lexically
earlier name to be considered at all."

My .link file wasn't considered because its file name came lexically
after '99-default.link'.

I'm now happily using the mac address for matching. I use `udevadm
test-builtin net_setup_link /sys/class/net/ens19` for applying a changed
.link file to my link.


On Tue, Mar 3, 2020, 10:59 Mantas Mikulėnas  wrote:
>
>
> On Mon, Mar 2, 2020, 16:59 Felix  > wrote:
>
> Hello everybody,
>
> I'm failing to set an alias for a link using systemd-networkd. Am I
> doing something wrong? Is this a bug?
>
>
> I'm on this systemd version:
> systemd 244 (244.3-1~bpo10+1)
> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
> +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS
> +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid
>
> This runs on a Debian Buster inside a virtual machine hosted on a
> proxmox 6.1 server, if that matters.
>
> I'm trying to set an alias for a link using systemd-networkd,
> following
> this documentation:
> https://www.freedesktop.org/software/systemd/man/systemd.link.html#Alias=
> .
> I put my file in /etc/systemd/network/, as
> -rw-r--r-- 1 root root  56 Mär  2 14:06 ens19.link
> with this content:
>
> ```
> [Match]
> Path=/sys/class/net/ens19
>
>
> The Path= setting is documented to match against the ID_PATH udev
> property, not against the list of sysfs paths. (For example udevadm
> shows "pci-:01:00.0" on my machine.)
>  
>
>
> [Link]
> Alias=myalias
> ```
>
> I also tried to replace `Path=/sys/class/net/ens19` with
> `MACAddress=be:19:32:ed:c0:61` and `OriginalName=ens19`.
>
>
> OriginalName matches the kernel-assigned name (udev property
> 'INTERFACE'), which is always either eth# or wlan# or usb# or similar.
>
> Names such as ens# or eno# are not original – the interfaces are
> renamed by udev, and this actually happens *after* applying .link
> files (as the .link files specify which naming policy to use in the
> first place.)
>
>  
>
>
> After `systemctl restart systemd-networkd` or even rebooting the alias
> is still not set:
>
>  
>
> How can I set the link alias using systemd-networkd?
>
>
> .link files are not applied by networkd – they're applied by udev.
>

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


Re: [systemd-devel] UDEV popen/system returns error if called from the program (RUN option)

2020-03-03 Thread Ilya Matveychikov


> On Mar 3, 2020, at 3:43 PM, Josef Moellers  wrote:
> 
> On 03.03.20 12:26, Ilya Matveychikov wrote:
>> Dear Lennart,
>> 
>> Thank you for the reply.
>> 
>>> On Mar 3, 2020, at 12:54 PM, Lennart Poettering  
>>> wrote:
>>> 
>>> On Mo, 02.03.20 00:35, Ilya Matveychikov (matvejchi...@gmail.com) wrote:
>>> 
 Hey guys,
 
 I’m not sure is it the right place to ask about the UDEV or not.
 
 Anyways, I have a problem with running custom program from the UDEV rule 
 (RUN+= option).
 The problem is somehow related to fork/exec, I can’t tell for sure.
 
 My code (this custom “RUN+=“-binary) using popen() to call external program
 and get the result using stream. Once I run this custom program alone it 
 works
 perfectly well. But once it is executed under the systemd/udev via the rule
 this popen() returns error with the code ENOMEM which is very strange for 
 me
 as the system has like 32Gb of RAM.
 
 The same happen with system() ...
 
 Do you guys have any glue of what the heck is going on?
 Are there any constraints on what can be done in “programs”?
>>> 
>>> We enforce a limit on the number of processes/threads forked off
>>> services, and udevd has a limt set like that too, via the TasksMax=
>>> setting in its unit file. Maybe you are leaking processes/threads
>>> somehow and hit that limit?
>> 
>> I don’t do any multithreading in my program, except some popen()’s ..
>> 
>> My system (archlinux) has "TasksMax=infinity” line in file:
>> /usr/lib/systemd/system/sysinit.target.wants/systemd-udev.service
>> 
>> Any other tips?
> Just a shot in the dark: do you pclose() all popen()s?

I hope I do pclose() all of them. Anyway, the same behavior I’m getting
with trying to do system(“ls -al / >/xxx”) before any popen(), just in
the beginning of the program. It fails! 

> 
> Josef
> -- 
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5
> 90409 Nürnberg
> Germany
> 
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
> ___
> 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] UDEV popen/system returns error if called from the program (RUN option)

2020-03-03 Thread Josef Moellers
On 03.03.20 12:26, Ilya Matveychikov wrote:
> Dear Lennart,
> 
> Thank you for the reply.
> 
>> On Mar 3, 2020, at 12:54 PM, Lennart Poettering  
>> wrote:
>>
>> On Mo, 02.03.20 00:35, Ilya Matveychikov (matvejchi...@gmail.com) wrote:
>>
>>> Hey guys,
>>>
>>> I’m not sure is it the right place to ask about the UDEV or not.
>>>
>>> Anyways, I have a problem with running custom program from the UDEV rule 
>>> (RUN+= option).
>>> The problem is somehow related to fork/exec, I can’t tell for sure.
>>>
>>> My code (this custom “RUN+=“-binary) using popen() to call external program
>>> and get the result using stream. Once I run this custom program alone it 
>>> works
>>> perfectly well. But once it is executed under the systemd/udev via the rule
>>> this popen() returns error with the code ENOMEM which is very strange for me
>>> as the system has like 32Gb of RAM.
>>>
>>> The same happen with system() ...
>>>
>>> Do you guys have any glue of what the heck is going on?
>>> Are there any constraints on what can be done in “programs”?
>>
>> We enforce a limit on the number of processes/threads forked off
>> services, and udevd has a limt set like that too, via the TasksMax=
>> setting in its unit file. Maybe you are leaking processes/threads
>> somehow and hit that limit?
> 
> I don’t do any multithreading in my program, except some popen()’s ..
> 
> My system (archlinux) has "TasksMax=infinity” line in file:
> /usr/lib/systemd/system/sysinit.target.wants/systemd-udev.service
> 
> Any other tips?
Just a shot in the dark: do you pclose() all popen()s?

Josef
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] UDEV popen/system returns error if called from the program (RUN option)

2020-03-03 Thread Ilya Matveychikov
Dear Lennart,

Thank you for the reply.

> On Mar 3, 2020, at 12:54 PM, Lennart Poettering  
> wrote:
> 
> On Mo, 02.03.20 00:35, Ilya Matveychikov (matvejchi...@gmail.com) wrote:
> 
>> Hey guys,
>> 
>> I’m not sure is it the right place to ask about the UDEV or not.
>> 
>> Anyways, I have a problem with running custom program from the UDEV rule 
>> (RUN+= option).
>> The problem is somehow related to fork/exec, I can’t tell for sure.
>> 
>> My code (this custom “RUN+=“-binary) using popen() to call external program
>> and get the result using stream. Once I run this custom program alone it 
>> works
>> perfectly well. But once it is executed under the systemd/udev via the rule
>> this popen() returns error with the code ENOMEM which is very strange for me
>> as the system has like 32Gb of RAM.
>> 
>> The same happen with system() ...
>> 
>> Do you guys have any glue of what the heck is going on?
>> Are there any constraints on what can be done in “programs”?
> 
> We enforce a limit on the number of processes/threads forked off
> services, and udevd has a limt set like that too, via the TasksMax=
> setting in its unit file. Maybe you are leaking processes/threads
> somehow and hit that limit?

I don’t do any multithreading in my program, except some popen()’s ..

My system (archlinux) has "TasksMax=infinity” line in file:
/usr/lib/systemd/system/sysinit.target.wants/systemd-udev.service

Any other tips?


> 
> Lennart
> 
> --
> Lennart Poettering, Berlin

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


Re: [systemd-devel] "[Match]" section in systemd.link file doesn't match interface

2020-03-03 Thread Mantas Mikulėnas
On Mon, Mar 2, 2020, 16:59 Felix  wrote:

> Hello everybody,
>
> I'm failing to set an alias for a link using systemd-networkd. Am I
> doing something wrong? Is this a bug?
>
>
> I'm on this systemd version:
> systemd 244 (244.3-1~bpo10+1)
> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
> +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS
> +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid
>
> This runs on a Debian Buster inside a virtual machine hosted on a
> proxmox 6.1 server, if that matters.
>
> I'm trying to set an alias for a link using systemd-networkd, following
> this documentation:
> https://www.freedesktop.org/software/systemd/man/systemd.link.html#Alias=
> .
> I put my file in /etc/systemd/network/, as
> -rw-r--r-- 1 root root  56 Mär  2 14:06 ens19.link
> with this content:
>
> ```
> [Match]
> Path=/sys/class/net/ens19
>

The Path= setting is documented to match against the ID_PATH udev property,
not against the list of sysfs paths. (For example udevadm shows
"pci-:01:00.0" on my machine.)


>
> [Link]
> Alias=myalias
> ```
>
> I also tried to replace `Path=/sys/class/net/ens19` with
> `MACAddress=be:19:32:ed:c0:61` and `OriginalName=ens19`.
>

OriginalName matches the kernel-assigned name (udev property 'INTERFACE'),
which is always either eth# or wlan# or usb# or similar.

Names such as ens# or eno# are not original – the interfaces are renamed by
udev, and this actually happens *after* applying .link files (as the .link
files specify which naming policy to use in the first place.)



>
> After `systemctl restart systemd-networkd` or even rebooting the alias
> is still not set:
>


> How can I set the link alias using systemd-networkd?
>

.link files are not applied by networkd – they're applied by udev.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] UDEV popen/system returns error if called from the program (RUN option)

2020-03-03 Thread Lennart Poettering
On Mo, 02.03.20 00:35, Ilya Matveychikov (matvejchi...@gmail.com) wrote:

> Hey guys,
>
> I’m not sure is it the right place to ask about the UDEV or not.
>
> Anyways, I have a problem with running custom program from the UDEV rule 
> (RUN+= option).
> The problem is somehow related to fork/exec, I can’t tell for sure.
>
> My code (this custom “RUN+=“-binary) using popen() to call external program
> and get the result using stream. Once I run this custom program alone it works
> perfectly well. But once it is executed under the systemd/udev via the rule
> this popen() returns error with the code ENOMEM which is very strange for me
> as the system has like 32Gb of RAM.
>
> The same happen with system() ...
>
> Do you guys have any glue of what the heck is going on?
> Are there any constraints on what can be done in “programs”?

We enforce a limit on the number of processes/threads forked off
services, and udevd has a limt set like that too, via the TasksMax=
setting in its unit file. Maybe you are leaking processes/threads
somehow and hit that limit?

Lennart

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


[systemd-devel] sd_notify protocol definition

2020-03-03 Thread Łukasz Niemier
Is there documentation for sd_notify protocol? I am working on pure-Erlang 
implementation of sd_notify (and few other systemd facilities) and I am looking 
for better description than reading C code which can be a little confusing 
without deeper knowledge of systemd helper functions around iocvec. Especially 
ucred and fds parts, as rest I have mostly implemented.

--

Łukasz Niemier
luk...@niemier.pl

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


Re: [systemd-devel] systemd prerelease 245-rc2

2020-03-03 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Mar 03, 2020 at 07:43:22AM +, systemd tag bot wrote:
> A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the 
> tarball here:
> 
> https://github.com/systemd/systemd/archive/v245-rc2.tar.gz

It's mostly bufixes, but still 146 commits since -rc1.
The plan is too release the final version at the end of the week.
Regressions and bugs are still being reported, so expect more patches
to go in.

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


Re: [systemd-devel] sd-daemon documentation clarification

2020-03-03 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Mar 02, 2020 at 01:38:54PM +0100, Łukasz Niemier wrote:
> > AFAIK both stdout and stderr even get attached to the same journal pipe by 
> > default, so they should also be interpreted in the same way.
> > 
> > The description of SyslogLevelPrefix= in systemd.exec(5) also says: "This 
> > only applies to log messages written to stdout or stderr.”
> 
> THX, I must have missed that. This mean that the `sd-daemon` documentation 
> page should be updated to contain that information as well.

Please file a PR!

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