Re: [systemd-devel] Why did you set MountFlags=slave in systemd-udevd.service.in

[Hongzhi, Song]

On 2018年03月01日 17:50, Lennart Poettering wrote:

On Do, 01.03.18 14:44, Hongzhi, Song (hongzhi.s...@windriver.com) wrote:


Thank you very much. It dose work.

Would you tell me that how the '--no-block' works,

"systemd-mount" talks to systemd (i.e. PID 1) to issue mount/automount
operations. By default it will do so synchronously, thus blocking
until the mount is established. If you specify "--no-block" then you
turn off this synchronous behaviour, and instead request asynchronous
behaviour, where the rule will just request the operation to be
executed, but won't wait for it to finish. When you invoke
"systemd-mount" from a udev rule then using "--no-block" is a
necessity to avoid a deadlock. That's because PID 1 won't operate on a
device to mount before udev reported it to be fully availabled and
probed.

Do you mean that udev doesn't report device to be fully availabled
and probed until systemd-mount returns?

Thank you for your selfless help.
Hongzhi.Song

Now, if synchronously wait for that from inside the udev rule
you hence delay precisely that probing forever.


I doesn't deeply understand the interpretation in

https://www.freedesktop.org/software/systemd/man/systemd-mount.html#SYSTEMD_MOUNT_OPTIONS=


And why systemd-mount can solve the problem brought by MountFlag=slave.

systemd-mount request the mount operation to be executed by PID 1, and
hence outside of the mount context of udev.

Lennart



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

Re: [systemd-devel] RFC: enable suspend to idle

[Thomas Blume]

On Thu, 1 Mar 2018, Lennart Poettering wrote:


The kernel must not set policy on what is a source of wake ups. Setting
this up so that we do not get a regression in functionality compared
to old style S3 (whose policy is in firmware) falls to user space,
more specifically udev.


And where would udev have that information from? I mean, if it turns
this on for all devices, then why can't the kernel do that on its own?



We don't want all devices for which the kernel is supporting wake on idle, to
act as wakeup device.
Ideally this will be a config option with reasonable defaults.
The udev rule should consider this.

Thomas Blume

--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
Maxfeldstr. 5 / D-90409 Nürnberg / Phone: +49-911-740 53 - 0 / VOIP: 3919
GPG 2048R/2CD4D3E8 9A50 048F 1C73 59AA 4D2E  424E B3C6 3FD9 2CD4 D3E8___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: enable suspend to idle

[Lennart Poettering]

On Do, 01.03.18 15:25, Oliver Neukum (oneu...@suse.com) wrote:

> Am Donnerstag, den 01.03.2018, 15:17 +0100 schrieb Lennart Poettering:
> > On Do, 01.03.18 14:40, Thomas Blume (thomas.bl...@suse.com) wrote:
> 
> > > As a proof of concept, I have created below udev rule and helper script, 
> > > which
> > > works on my testmachine.
> > > Obviously, like that it isn't portable to other distros, but I'd like to 
> > > get
> > > comments whether this is the way to go.
> > > If I get positive feedback, I'll try a portable approach using a binary 
> > > helper.
> > > 
> > > udev rule:
> > > 
> > > -->
> > > ACTION=="add",  ATTR{power/wakeup}=="disabled", 
> > > IMPORT{program}="/usr/lib/udev/get-wakeup-devices.sh %p"
> > > ENV{RESUME_FROM_IDLE}=="1", ATTR{power/wakeup}="enabled"
> > 
> > Not following here. This doesn't appear like something where userspace
> > should be involved. We generally avoid udev rules whose only job is to
> > "shortcut" kernel events back into the kernel. Why doesn't the kernel
> > set this up properly anyway on its own?
> 
> The kernel must not set policy on what is a source of wake ups. Setting
> this up so that we do not get a regression in functionality compared
> to old style S3 (whose policy is in firmware) falls to user space,
> more specifically udev.

And where would udev have that information from? I mean, if it turns
this on for all devices, then why can't the kernel do that on its own?

Lennart

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

Re: [systemd-devel] RFC: enable suspend to idle

[Lennart Poettering]

On Do, 01.03.18 14:40, Thomas Blume (thomas.bl...@suse.com) wrote:

> Hi,
> 
> It seems that major vendors are dropping support of sleep mode S3 in favor of
> the new suspend to idle method.
> We need to enable this new feature in order to be able to suspend to RAM on
> such machines.
> The kernel side of this feature has already been implemented:
> 
> https://patchwork.kernel.org/patch/9873163
> 
> but we need to activate it in userspace.
> Each device, supporting suspend to idle from kernel side, has a file called
> wakeup in sysfs.
> Echoing "enabled" into this file will enable the feature.
> 
> As a proof of concept, I have created below udev rule and helper script, which
> works on my testmachine.
> Obviously, like that it isn't portable to other distros, but I'd like to get
> comments whether this is the way to go.
> If I get positive feedback, I'll try a portable approach using a binary 
> helper.
> 
> udev rule:
> 
> -->
> ACTION=="add",  ATTR{power/wakeup}=="disabled", 
> IMPORT{program}="/usr/lib/udev/get-wakeup-devices.sh %p"
> ENV{RESUME_FROM_IDLE}=="1", ATTR{power/wakeup}="enabled"

Not following here. This doesn't appear like something where userspace
should be involved. We generally avoid udev rules whose only job is to
"shortcut" kernel events back into the kernel. Why doesn't the kernel
set this up properly anyway on its own?

Lennart

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

Re: [systemd-devel] RFC: enable suspend to idle

[Oliver Neukum]

Am Donnerstag, den 01.03.2018, 15:17 +0100 schrieb Lennart Poettering:
> On Do, 01.03.18 14:40, Thomas Blume (thomas.bl...@suse.com) wrote:

> > As a proof of concept, I have created below udev rule and helper script, 
> > which
> > works on my testmachine.
> > Obviously, like that it isn't portable to other distros, but I'd like to get
> > comments whether this is the way to go.
> > If I get positive feedback, I'll try a portable approach using a binary 
> > helper.
> > 
> > udev rule:
> > 
> > -->
> > ACTION=="add",  ATTR{power/wakeup}=="disabled", 
> > IMPORT{program}="/usr/lib/udev/get-wakeup-devices.sh %p"
> > ENV{RESUME_FROM_IDLE}=="1", ATTR{power/wakeup}="enabled"
> 
> Not following here. This doesn't appear like something where userspace
> should be involved. We generally avoid udev rules whose only job is to
> "shortcut" kernel events back into the kernel. Why doesn't the kernel
> set this up properly anyway on its own?

The kernel must not set policy on what is a source of wake ups. Setting
this up so that we do not get a regression in functionality compared
to old style S3 (whose policy is in firmware) falls to user space,
more specifically udev.

Regards
Oliver

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

[systemd-devel] RFC: enable suspend to idle

[Thomas Blume]

Hi,

It seems that major vendors are dropping support of sleep mode S3 in favor of
the new suspend to idle method.
We need to enable this new feature in order to be able to suspend to RAM on
such machines.
The kernel side of this feature has already been implemented:

https://patchwork.kernel.org/patch/9873163

but we need to activate it in userspace.
Each device, supporting suspend to idle from kernel side, has a file called
wakeup in sysfs.
Echoing "enabled" into this file will enable the feature.

As a proof of concept, I have created below udev rule and helper script, which
works on my testmachine.
Obviously, like that it isn't portable to other distros, but I'd like to get
comments whether this is the way to go.
If I get positive feedback, I'll try a portable approach using a binary helper.

udev rule:

-->
ACTION=="add",  ATTR{power/wakeup}=="disabled", 
IMPORT{program}="/usr/lib/udev/get-wakeup-devices.sh %p"
ENV{RESUME_FROM_IDLE}=="1", ATTR{power/wakeup}="enabled"
--<

helper script:

-->
#!/bin/sh

SYSDEVS=$(find /sys/devices/pci* -name wakeup)
NETWORKDEVS=$(lspci | sed -n '/Ethernet controller/s/^\([[:graph:]]*\).*/\1/p')
USBINPUTDEVS=$(find /sys/devices/pci*/*/usb* -name input)
OTHERDEVS=$(find /sys/devices -name wakeup | sed -n 
'/serio/p;/pnp/p;/LNXPWRBN/p')

#get ethernet and usb devices
for sysdev in $SYSDEVS; do
PCIID=$(echo $sysdev | sed -n 
's#/sys/devices/pci[[:digit:]]*:[[:digit:]]*/[[:digit:]]*:\([[:digit:]]*:[[:alnum:]]*.[[:alnum:]]\).*#\1#p')
for netdev in $NETWORKDEVS; do
[[ "$PCIID" =~ $netdev ]] && [[ ! "$WAKEUPDEVS" =~ ${sysdev%/power/wakeup} ]] 
&& WAKEUPDEVS+="$sysdev ";
done
for usbinputdev in $USBINPUTDEVS; do
[[ $usbinputdev =~ $PCIID ]] && [[ ! "$WAKEUPDEVS" =~ ${sysdev%/power/wakeup} ]] 
&& WAKEUPDEVS+="$sysdev ";
done
done

#get ps2, plug and play and power button devices
for otherdev in $OTHERDEVS; do
[[ "$WAKEUPDEVS" =~ ${otherdev%/power/wakeup} ]] || WAKEUPDEVS+="$otherdev 
";
done

[[ "$WAKEUPDEVS" =~ "$1/power/wakeup" ]] && echo "RESUME_FROM_IDLE=1"
--<


Regards
Thomas Blume

--
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
Maxfeldstr. 5 / D-90409 Nürnberg / Phone: +49-911-740 53 - 0 / VOIP: 3919
GPG 2048R/2CD4D3E8 9A50 048F 1C73 59AA 4D2E  424E B3C6 3FD9 2CD4 D3E8___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] custom var in sd_notify

[Lennart Poettering]

On Do, 01.03.18 11:09, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:

> On Wed, Feb 28, 2018 at 7:04 PM, Lennart Poettering
>  wrote:
> > On Mo, 26.02.18 08:09, Mantas Mikulėnas (graw...@gmail.com) wrote:
> >
> >> > Daemons can choose to send additional variables. However, it is 
> >> > recommended
> >> > to prefix variable names not listed above with X_.
> >> > So naturally i tried
> >> >
> >> > sd_notify(0, "X_ANSWER=42")
> >> >
> >> > and apparently systemd has no problem with that, but my questions are 2
> >> > now:
> >> >
> >> > 1) What does systemd do with this information?
> >> >
> >>
> >> Nothing. The documentation just says in other words that "the init system
> >> must not reject packets with unknown variables", but doesn't say that
> >> systemd or any other init will store all of them anywhere.
> >
> > Currently we indeed ignore those unknown variables entirely. It has
> > been requested that we expose these variables on the bus somehow. I
> > think that would be an OK addition, but we need to think about the
> > lifecycle of those vars then so that the vars we collect don't grow
> > without bounds.
> 
> I believe this is what we do with STATUS: messages today. I was just
> curious if there is a rate limit around this sd_notify interface.

No, it's an AF_UNIX socket. That means we have to process the queued
datagrams in order.

Of course clients might decide to skip enqueuing messages if the
socket buffer is full (i.e. by setting O_NONBLOCK on the socket and
checking for EAGAIN), however that's purely on the client-side, PID 1
can't really do much else than process every single message, there's
no ratelimit.

Lennart

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

Re: [systemd-devel] Best practice for prepopulating the CacheDirectory of dynamic users

[Lennart Poettering]

On Do, 01.03.18 01:32, Antoine Pietri (antoine.piet...@gmail.com) wrote:

> On Wed, Feb 28, 2018 at 6:59 PM, Lennart Poettering
>  wrote:
> > Not sure I follow. Why do you let the service hang around? If all you
> > want to do is have it create the directory for you you could just run:
> >
> > # systemd-run -P -p DynamicUser=yes -p CacheDirectory=mywrapper --wait true
> >
> > That would be synchronous, would set up the dir and immediately
> > return.
> 
> My bad, for some reason my understanding was that there was some
> teardown happening after the service was run, but the problem was just
> somewhere else.

There's a destruction logic in place for RuntimeDirectory= but not for
CacheDirectory=. And even for RuntimeDirectory= you can turn it off
with RuntimeDirectoryPreserve=.

Lennart

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

Re: [systemd-devel] custom var in sd_notify

[Umut Tezduyar Lindskog]

On Wed, Feb 28, 2018 at 7:04 PM, Lennart Poettering
 wrote:
> On Mo, 26.02.18 08:09, Mantas Mikulėnas (graw...@gmail.com) wrote:
>
>> > Daemons can choose to send additional variables. However, it is recommended
>> > to prefix variable names not listed above with X_.
>> > So naturally i tried
>> >
>> > sd_notify(0, "X_ANSWER=42")
>> >
>> > and apparently systemd has no problem with that, but my questions are 2
>> > now:
>> >
>> > 1) What does systemd do with this information?
>> >
>>
>> Nothing. The documentation just says in other words that "the init system
>> must not reject packets with unknown variables", but doesn't say that
>> systemd or any other init will store all of them anywhere.
>
> Currently we indeed ignore those unknown variables entirely. It has
> been requested that we expose these variables on the bus somehow. I
> think that would be an OK addition, but we need to think about the
> lifecycle of those vars then so that the vars we collect don't grow
> without bounds.

I believe this is what we do with STATUS: messages today. I was just
curious if there is a rate limit around this sd_notify interface.

UMUT

>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> 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] Why did you set MountFlags=slave in systemd-udevd.service.in

[Lennart Poettering]

On Do, 01.03.18 14:44, Hongzhi, Song (hongzhi.s...@windriver.com) wrote:

> Thank you very much. It dose work.
> 
> Would you tell me that how the '--no-block' works,

"systemd-mount" talks to systemd (i.e. PID 1) to issue mount/automount
operations. By default it will do so synchronously, thus blocking
until the mount is established. If you specify "--no-block" then you
turn off this synchronous behaviour, and instead request asynchronous
behaviour, where the rule will just request the operation to be
executed, but won't wait for it to finish. When you invoke
"systemd-mount" from a udev rule then using "--no-block" is a
necessity to avoid a deadlock. That's because PID 1 won't operate on a
device to mount before udev reported it to be fully availabled and
probed. Now, if synchronously wait for that from inside the udev rule
you hence delay precisely that probing forever.

> I doesn't deeply understand the interpretation in
> 
> https://www.freedesktop.org/software/systemd/man/systemd-mount.html#SYSTEMD_MOUNT_OPTIONS=
> 
> 
> And why systemd-mount can solve the problem brought by MountFlag=slave.

systemd-mount request the mount operation to be executed by PID 1, and
hence outside of the mount context of udev.

Lennart

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