Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

[Zheng, Lv]

Hi,

> From: linux-acpi-ow...@vger.kernel.org 
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Peter
> Hutterer
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch 
> exported by ACPI
> 
> On Thu, Jun 15, 2017 at 07:33:58AM +, Zheng, Lv wrote:
> > Hi, Peter
> >
> > > From: Peter Hutterer [mailto:peter.hutte...@who-t.net]
> > > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID 
> > > switch exported by ACPI
> > >
> > > On Thu, Jun 15, 2017 at 02:52:57AM +, Zheng, Lv wrote:
> > > > Hi, Benjamin
> > > >
> > > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> > > > > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable 
> > > > > LID switch exported by ACPI
> > > > >
> > > > > Hi,
> > > > >
> > > > > [Sorry for the delay, I have been sidetracked from this]
> > > > >
> > > > > On Jun 07 2017 or thereabouts, Lennart Poettering wrote:
> > > > > > On Thu, 01.06.17 20:46, Benjamin Tissoires 
> > > > > > (benjamin.tissoi...@redhat.com) wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Sending this as a WIP as it still need a few changes, but it 
> > > > > > > mostly works as
> > > > > > > expected (still not fully compliant yet).
> > > > > > >
> > > > > > > So this is based on Lennart's comment in [1]: if the LID state is 
> > > > > > > not reliable,
> > > > > > > the kernel should not export the LID switch device as long as we 
> > > > > > > are not sure
> > > > > > > about its state.
> > > > > >
> > > > > > Ah nice! I (obviously) like this approach.
> > > > >
> > > > > Heh. Now I just need to convince Lv that it's the right approach.
> > > >
> > > > I feel we don't have big conflicts.
> > > > And I already took part of your idea into this patchset:
> > > > https://patchwork.kernel.org/patch/9771121/
> > > > https://patchwork.kernel.org/patch/9771119/
> > > > I tested my surface pros with Ubuntu, they are working as expected.
> > > >
> > > > > > > Note that systemd currently doesn't sync the state when the input 
> > > > > > > node just
> > > > > > > appears. This is a systemd bug, and it should not be handled by 
> > > > > > > the kernel
> > > > > > > community.
> > > > > >
> > > > > > Uh if this is borked, we should indeed fix this in systemd. Is there
> > > > > > already a systemd github bug about this? If not, please create one,
> > > > > > and we'll look into it!
> > > > >
> > > > > I don't think there is. I haven't raised it yet because I am not so 
> > > > > sure
> > > > > this will not break again those worthless unreliable LID, and if we 
> > > > > play
> > > > > whack a mole between the kernel and user space, things are going to be
> > > > > nasty. So I'd rather have this fixed in systemd along with the
> > > > > unreliable LID switch knowledge, so we are sure that the kernel 
> > > > > behaves
> > > > > the way we expect it to be.
> > > >
> > > > This is my feeling:
> > > > We needn't go that far.
> > > > We can interpret "input node appears" into "default input node state".
> > >
> > > Sorry, can you clarify this bit please? I'm not sure what you mean here.
> > > Note that there's an unknown amount of time between "device node appearing
> > > in the system" and when a userspace process actually opens it and looks at
> > > its state. By then, the node may have changed state again.
> >
> > We can see:
> > "logind" has already implemented a timeout, and will not respond lid state
> > unless it can be stable within this timeout period.
> > I'm not an expert of logind, maybe this is because of "HoldOffTimeoutSec"?
> >
> > I feel "removing the input node for a period where its state is not 
> > trustful"
> > is technically identical to this mechanism.
> 
> but you'd be making kernel policy based on one userspace implementation.
> e.g. libinput doesn't have a timeout period, it assumes the state is
> correct when an input node is present.

Do you see practical issues?
If not, should we avoid over-engineering at this moment?

After resume, SW_LID state could remain unreliable "close" for a while.
But that's just a kind of delay happens in all computing programs.
I suppose all power managing programs have already handled that.
I confirmed no breakage for systemd 233.
For systemd 229, it cannot handle it well due to bugs.
But my latest patch series has worked the bug around.
So I don't see any breakage related to post-resume incorrect state period.
Do you see problems that my tests haven't covered?

So I wonder if you mean:
After boot, button driver should create input node right before sending first 
input report.
Is this exactly what you want me to improve?
If so, please also let me know if you have seen real issues related to this?

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

Re: [systemd-devel] magically disappearing filesystems

[Mantas Mikulėnas]

This reminds me of a bug (misfeature) that *I think* was fixed in recent
releases...

Mount points are bound to the corresponding .device so that they'd get
cleaned up when the device disappears, but the way it was implemented meant
they'd also get immediately unmounted if the device wasn't there in the
first place.

E.g. in emergency mode when udev wasn't running so systemd thought all
devices were inactive. (State-based when it ought to have been event-based.)

I haven't tested specifically, but according to commit log, that shouldn't
be a problem in 23x versions.

On Wed, Jun 14, 2017, 16:59 Andre Maasikas  wrote:

> Hi,
>
> Having done this numerous times over the years I proceeded to move our
> data to new storage array, first time on a new os version though.
> Goes always like this,
> * attach array, create LUNS, create multipath conf etc...
> * umount old filesystem, mount new filesystems, mount old filesys to temp
> location, copy data over, * update fstab, unmount temporary/old filesystem.
> DONE
> A day later ... Now to cleanly remove the old array/devices I did
> # multipath -f olddev
> # echo 1 > /sys/block/sdx/device/delete
> # echo 1 > /sys/block/sdy/device/delete
> etc..
>
> After double checking I see that none of the new filesystems are mounted !
> OOPS moment. I estimate I have about 10 minutes now to figure this out
> before the transaction logs fill up and lots of revenue goes down. Probably
> doesn't look good for me as I discovered the issue after i executed the
> removal on most production systems and all clustered nodes
>
> OK, let's mount manually,
>
> mount /dev/mapper/newdev /mountpoint
> > no errors, seems ok
> still df, mount and /proc/mounts show nothing...
> WTF moment
>
> mount -v tells me smth like :
>  /dev/newdev does not contain SELinux labels.
>You just mounted an file system that supports labels which does not
>contain labels, onto an SELinux box. It is likely that confined
>applications will generate AVC messages and not be allowed access to
>this file system.  For more details see restorecon(8) and mount(8).
>
> Searching google for 3 minutes if I may be confined to a space where I am
> not allowed to see the filesystem anymore proved futile.
>
> dmesg is filled with messages about how the filesystem is busy for umount
> and for the mount attempt:
> kernel: XFS (dm-22): Mounting V4 Filesystem
> kernel: XFS (dm-22): Ending clean mount
> systemd: Unit xx.mount is bound to inactive unit dev-mapper-xx.device.
> Stopping, too.
> systemd: Unmounting /mountpoint...
> kernel: XFS (dm-22): Unmounting Filesystem
> systemd: Unmounted /mountpoint.
> systemd: Unit xxx.mount entered failed state.
>
> (dev-mapper-xx being the old/removed device-mapper device)
>
> Finally using the second set of keywords reveals that I'm supposed to
> #systemctl daemon-reload
> whenever i edit fstab.
>
> Seems like the fstab file is not always authoritative anymore and the
> authoritative configuration
> is kept god-knows elsewhere and these might not be in sync and depend on
> god-knows what and if you don't know that it's now allowed to automatically
> unmount a perfectly good working filesystem from under you without any
> warning.  A quick review of fstab header, man fstab, man mount etc. does
> not reveal any information about this newish behavior. Also no commands
> that got me to this point gave any errors or indication that this will be
> happening.
>
> It might be something else I did incorrectly or distribution specific
> (RHEL 7.2) or a bug already fixed. Most certainly I have not learned enough
> of the the new ways of systemd (and selinux)
>
> Andre
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-- 

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

Re: [systemd-devel] magically disappearing filesystems

[Andrei Borzenkov]

14.06.2017 16:58, Andre Maasikas пишет:
> 
> OK, let's mount manually,
> 
> mount /dev/mapper/newdev /mountpoint
>> no errors, seems ok
> still df, mount and /proc/mounts show nothing...
> WTF moment
> 

Well, opposite case (it is mounted when it should not) is equally true

https://github.com/systemd/systemd/issues/6066

Same reason, same cause. It is assumed that configuration cannot change
since boot (or to view it differently that configuration change requires
reboot).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Persistent address on "Lost carrier"

[Amish]

On Thursday 15 June 2017 03:07 PM, Mantas Mikulėnas wrote:
On Thu, Jun 15, 2017 at 11:21 AM, Lennart Poettering 
> wrote:


On Tue, 13.06.17 21:44, Amish (anon.am...@gmail.com
) wrote:

> Hello,
>
> I have the following in /etc/systemd/network/25-eth0.network
>
> [Match]
> MACAddress=00:11:22:33:44:55
>
> [Network]
> Address=192.168.1.32/24 
> Gateway=192.168.1.1
>
> Now I have few "dynamic" routes where destination IP keeps changing.
>
> Example:
> /usr/bin/ip route add to 1.2.3.4 via 192.168.1.2 (Different gateway)
>
> Many more routes are added by one script which keeps adding /
deleting
> routes based on certain algorithms.
>
> Since destination IP keeps changing, I can not put it in [Route]
section.
>
> Now my problem is, if for any reason the interface loses carrier
(cable
> fault / switch / router reboot), the IP associated with it is
removed and
> hence all the routes added by script gets lost.
>
> My question is how to stop this?
>
> How do I tell systemd to not to delete IP address on "Lost carrier"?
>
> I tried with:
>
> BindCarrier=lo
> OR
> BindCarrier=eth0
> OR
> BindCarrier=lo eth0
>
> But none worked.
>
> Any idea / suggestions? Something similar to -
CriticalConnection for DHCP?
>
> Or may be we can have Persistent=true in "[Network]" OR
"[Address]" section?

This is really not how networkd is supposed to be used. Either it
manages an interface in its entirety or not at all. It's not designed
to manage an interface only "half-way", i.e. manage addresses but not
the routes.


Hmm, that wasn't the actual question though, was it? The point was 
just to make networkd ignore carrier status (i.e. often there's no 
need to remove addresses just because the interface is down for a 
moment), not to stop managing halfway.




Yes thats what I am looking for.

I wonder, if IP is "static IP" why should it remove it from interface? 
or atleast let administrator have an option to specify if IP should be 
deleted or not on "Lost carrier"


Also on a side note:

Even if I use [Route] section in .network file. There is still an issue.

Say I have two WAN connections. WAN1 and WAN2.

All traffic goes through WAN1. (default route)

But say I add [Route] section, telling that traffic to some networks is 
supposed to go via WAN2.


But no sooner the "Carrier" gets lost on WAN2, the routes added by 
[Route] section also gets deleted.


And traffic that was supposed to go via WAN2, start going through WAN1.

Ofcourse routes get readded when WAN2 "Gains carrier" but by that time 
some connection get dropped / interrupted / rejected by RST as packets 
went through WAN1 (which was not allowed).


Please consider of adding an option to Ignore "Lost carrier" atleast for 
static IPs.


Thanks and regards,

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

Re: [systemd-devel] [rsyslog] Rsyslog & newlines

[Renjith Vijayan]

+ Systemd-dev

Hi,

Does journal ignore the forwarding of logs ending with newline(\n) to
rsyslog? In my system there are some logs send directly via
sd_journal_send() API and ending with newline.
These logs are present in journal, but not in /var/log/messages.

Rainer confirmed that rsyslog does accept logs with newline as seen in mail
below. So is this the case where journal not forwarding the logs due to
newline?

Thanks,
RV

On Thu, Jun 15, 2017 at 1:27 PM, Rainer Gerhards 
wrote:

> I assume that journal does not forward them. A debug log might help to
> validate this assumption. Rsyslog does not reject logs with newlines albeit
> they usually cause huge problems in many subsystems and thus it is strongly
> recommended to not use them.
>
> Rainer
>
> Sent from phone, thus brief.
>
> Am 15.06.2017 05:00 schrieb "Renjith Vijayan via rsyslog" <
> rsys...@lists.adiscon.com>:
>
> Hi,
>
> I am working on a system where both systemd-journal & rsyslog(7.6.1) are
> there. Systemd-journal is configured to forward logs to rsyslog routinely.
> I have some logs which ends with newlines & that are directly sent to
> journal using sd_journal_send() API's.
>
> I see that although these logs are present in journal, it's not present in
> /var/log/messages which is populated by rsyslog. Is rsyslog rejecting these
> logs due to the ending newline?
>
> Further, based on some search results on this topic, I tried adding the
> following lines to rsyslog.conf, but this didn't help either.
>
> # global directives
> $EscapeControlCharactersOnReceive off
> $EscapeControlCharactersCStyle off
> $ActionFileDefaultTemplate RSYSLOG_SysklogdFileFormat
> $SpaceLFOnReceive on
> $DropTrailingLFOnReception off
>
> Could you please let me know how can  I make rsyslog to accept these logs
> ending with newline?
>
> Thanks,
> RV
> ___
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com/professional-services/
> What's up with rsyslog? Follow https://twitter.com/rgerhards
> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad
> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you
> DON'T LIKE THAT.
>
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Persistent address on "Lost carrier"

[Mantas Mikulėnas]

On Thu, Jun 15, 2017 at 11:21 AM, Lennart Poettering  wrote:

> On Tue, 13.06.17 21:44, Amish (anon.am...@gmail.com) wrote:
>
> > Hello,
> >
> > I have the following in /etc/systemd/network/25-eth0.network
> >
> > [Match]
> > MACAddress=00:11:22:33:44:55
> >
> > [Network]
> > Address=192.168.1.32/24
> > Gateway=192.168.1.1
> >
> > Now I have few "dynamic" routes where destination IP keeps changing.
> >
> > Example:
> > /usr/bin/ip route add to 1.2.3.4 via 192.168.1.2 (Different gateway)
> >
> > Many more routes are added by one script which keeps adding / deleting
> > routes based on certain algorithms.
> >
> > Since destination IP keeps changing, I can not put it in [Route] section.
> >
> > Now my problem is, if for any reason the interface loses carrier (cable
> > fault / switch / router reboot), the IP associated with it is removed and
> > hence all the routes added by script gets lost.
> >
> > My question is how to stop this?
> >
> > How do I tell systemd to not to delete IP address on "Lost carrier"?
> >
> > I tried with:
> >
> > BindCarrier=lo
> > OR
> > BindCarrier=eth0
> > OR
> > BindCarrier=lo eth0
> >
> > But none worked.
> >
> > Any idea / suggestions? Something similar to - CriticalConnection for
> DHCP?
> >
> > Or may be we can have Persistent=true in "[Network]" OR "[Address]"
> section?
>
> This is really not how networkd is supposed to be used. Either it
> manages an interface in its entirety or not at all. It's not designed
> to manage an interface only "half-way", i.e. manage addresses but not
> the routes.
>

Hmm, that wasn't the actual question though, was it? The point was just to
make networkd ignore carrier status (i.e. often there's no need to remove
addresses just because the interface is down for a moment), not to stop
managing halfway.

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

Re: [systemd-devel] Persistent address on "Lost carrier"

[Lennart Poettering]

On Tue, 13.06.17 21:44, Amish (anon.am...@gmail.com) wrote:

> Hello,
> 
> I have the following in /etc/systemd/network/25-eth0.network
> 
> [Match]
> MACAddress=00:11:22:33:44:55
> 
> [Network]
> Address=192.168.1.32/24
> Gateway=192.168.1.1
> 
> Now I have few "dynamic" routes where destination IP keeps changing.
> 
> Example:
> /usr/bin/ip route add to 1.2.3.4 via 192.168.1.2 (Different gateway)
> 
> Many more routes are added by one script which keeps adding / deleting
> routes based on certain algorithms.
> 
> Since destination IP keeps changing, I can not put it in [Route] section.
> 
> Now my problem is, if for any reason the interface loses carrier (cable
> fault / switch / router reboot), the IP associated with it is removed and
> hence all the routes added by script gets lost.
> 
> My question is how to stop this?
> 
> How do I tell systemd to not to delete IP address on "Lost carrier"?
> 
> I tried with:
> 
> BindCarrier=lo
> OR
> BindCarrier=eth0
> OR
> BindCarrier=lo eth0
> 
> But none worked.
> 
> Any idea / suggestions? Something similar to - CriticalConnection for DHCP?
> 
> Or may be we can have Persistent=true in "[Network]" OR "[Address]" section?

This is really not how networkd is supposed to be used. Either it
manages an interface in its entirety or not at all. It's not designed
to manage an interface only "half-way", i.e. manage addresses but not
the routes.

I am sorry, but networkd really isn't the right tool for what you are
trying to do.

Sorry,

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] magically disappearing filesystems

[Andre Maasikas]

On Thu, Jun 15, 2017 at 10:39 AM, Jérémy Rosen 
wrote:

>
> I'm pretty it should only be necessary to call daemon-reload before using
> systemctl. It warns if any source files (unit files, dropins and anything
> mentioned by SourcePath= in a unit) have been updated since the last
> reload. The fstab generator should be using SourcePath=.
>
>
> Would it be theoretically possible to do a .path that looked at /etc/fstab
> and triggered a daemon-reload, or would that be a bad idea for reasons I
> don't imagine ?
>
> Hi,

That wont help too much as I see it.
Currently if i manually unmount a filesystem some configuration remains and
later when i remove the md device it tries to
do automatic actions based on that invalid configuration.

To break this link either
1. removing the md device should not umount the filesystem or at least
check that it is still the right one
or more correct
2. umounting should break the link, update configuration so removing the
device doesn't do funny things

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

Re: [systemd-devel] magically disappearing filesystems

[Michael Chapman]

On Thu, 15 Jun 2017, Jérémy Rosen wrote:



 I'm pretty it should only be necessary to call daemon-reload before using
 systemctl. It warns if any source files (unit files, dropins and anything
 mentioned by SourcePath= in a unit) have been updated since the last
 reload. The fstab generator should be using SourcePath=.



Would it be theoretically possible to do a .path that looked at /etc/fstab 
and triggered a daemon-reload, or would that be a bad idea for reasons I 
don't imagine ?


I guess you could do that.

I'm happy enough to not have config loaded automatically, though -- it 
just seems neater to have a whole bunch of changes queued up and to have 
them all applied at once. I've never found manual reloads to be a big 
problem.


On the other hand, I can't think of any big problems with having new 
config applied automatically. It's not as if systemd will automatically 
start any new units or stop any that disappear under it, at least at the 
time of the reload itself. The one concern though is that it can affect 
future jobs, as new dependencies between units may have been automatically 
added. But maybe that's what the sysadmin expected.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

[Peter Hutterer]

On Thu, Jun 15, 2017 at 07:33:58AM +, Zheng, Lv wrote:
> Hi, Peter
> 
> > From: Peter Hutterer [mailto:peter.hutte...@who-t.net]
> > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID 
> > switch exported by ACPI
> > 
> > On Thu, Jun 15, 2017 at 02:52:57AM +, Zheng, Lv wrote:
> > > Hi, Benjamin
> > >
> > > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> > > > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID 
> > > > switch exported by ACPI
> > > >
> > > > Hi,
> > > >
> > > > [Sorry for the delay, I have been sidetracked from this]
> > > >
> > > > On Jun 07 2017 or thereabouts, Lennart Poettering wrote:
> > > > > On Thu, 01.06.17 20:46, Benjamin Tissoires 
> > > > > (benjamin.tissoi...@redhat.com) wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Sending this as a WIP as it still need a few changes, but it mostly 
> > > > > > works as
> > > > > > expected (still not fully compliant yet).
> > > > > >
> > > > > > So this is based on Lennart's comment in [1]: if the LID state is 
> > > > > > not reliable,
> > > > > > the kernel should not export the LID switch device as long as we 
> > > > > > are not sure
> > > > > > about its state.
> > > > >
> > > > > Ah nice! I (obviously) like this approach.
> > > >
> > > > Heh. Now I just need to convince Lv that it's the right approach.
> > >
> > > I feel we don't have big conflicts.
> > > And I already took part of your idea into this patchset:
> > > https://patchwork.kernel.org/patch/9771121/
> > > https://patchwork.kernel.org/patch/9771119/
> > > I tested my surface pros with Ubuntu, they are working as expected.
> > >
> > > > > > Note that systemd currently doesn't sync the state when the input 
> > > > > > node just
> > > > > > appears. This is a systemd bug, and it should not be handled by the 
> > > > > > kernel
> > > > > > community.
> > > > >
> > > > > Uh if this is borked, we should indeed fix this in systemd. Is there
> > > > > already a systemd github bug about this? If not, please create one,
> > > > > and we'll look into it!
> > > >
> > > > I don't think there is. I haven't raised it yet because I am not so sure
> > > > this will not break again those worthless unreliable LID, and if we play
> > > > whack a mole between the kernel and user space, things are going to be
> > > > nasty. So I'd rather have this fixed in systemd along with the
> > > > unreliable LID switch knowledge, so we are sure that the kernel behaves
> > > > the way we expect it to be.
> > >
> > > This is my feeling:
> > > We needn't go that far.
> > > We can interpret "input node appears" into "default input node state".
> > 
> > Sorry, can you clarify this bit please? I'm not sure what you mean here.
> > Note that there's an unknown amount of time between "device node appearing
> > in the system" and when a userspace process actually opens it and looks at
> > its state. By then, the node may have changed state again.
> 
> We can see:
> "logind" has already implemented a timeout, and will not respond lid state
> unless it can be stable within this timeout period.
> I'm not an expert of logind, maybe this is because of "HoldOffTimeoutSec"?
> 
> I feel "removing the input node for a period where its state is not trustful"
> is technically identical to this mechanism.

but you'd be making kernel policy based on one userspace implementation.
e.g. libinput doesn't have a timeout period, it assumes the state is
correct when an input node is present. 

Cheers,
   Peter

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

Re: [systemd-devel] magically disappearing filesystems

[Jérémy Rosen]

I'm pretty it should only be necessary to call daemon-reload before using
systemctl. It warns if any source files (unit files, dropins and 
anything mentioned by SourcePath= in a unit) have been updated since 
the last reload. The fstab generator should be using SourcePath=.




Would it be theoretically possible to do a .path that looked at 
/etc/fstab and triggered a daemon-reload, or would that be a bad idea 
for reasons I don't imagine ?


Jeremy


- Michael


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


--
Logo 

20 rue des Jardins
92600 Asnières-sur-Seine
www.smile.fr    
*Jérémy ROSEN*
Architecte technique
Email : jeremy.ro...@smile.fr 
Tel : +33141402967

Facebook  Google%2B 
 LinkedIn 
 Twitter 




bandeaux_mail 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

[Zheng, Lv]

Hi, Peter

> From: Peter Hutterer [mailto:peter.hutte...@who-t.net]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch 
> exported by ACPI
> 
> On Thu, Jun 15, 2017 at 02:52:57AM +, Zheng, Lv wrote:
> > Hi, Benjamin
> >
> > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> > > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID 
> > > switch exported by ACPI
> > >
> > > Hi,
> > >
> > > [Sorry for the delay, I have been sidetracked from this]
> > >
> > > On Jun 07 2017 or thereabouts, Lennart Poettering wrote:
> > > > On Thu, 01.06.17 20:46, Benjamin Tissoires 
> > > > (benjamin.tissoi...@redhat.com) wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Sending this as a WIP as it still need a few changes, but it mostly 
> > > > > works as
> > > > > expected (still not fully compliant yet).
> > > > >
> > > > > So this is based on Lennart's comment in [1]: if the LID state is not 
> > > > > reliable,
> > > > > the kernel should not export the LID switch device as long as we are 
> > > > > not sure
> > > > > about its state.
> > > >
> > > > Ah nice! I (obviously) like this approach.
> > >
> > > Heh. Now I just need to convince Lv that it's the right approach.
> >
> > I feel we don't have big conflicts.
> > And I already took part of your idea into this patchset:
> > https://patchwork.kernel.org/patch/9771121/
> > https://patchwork.kernel.org/patch/9771119/
> > I tested my surface pros with Ubuntu, they are working as expected.
> >
> > > > > Note that systemd currently doesn't sync the state when the input 
> > > > > node just
> > > > > appears. This is a systemd bug, and it should not be handled by the 
> > > > > kernel
> > > > > community.
> > > >
> > > > Uh if this is borked, we should indeed fix this in systemd. Is there
> > > > already a systemd github bug about this? If not, please create one,
> > > > and we'll look into it!
> > >
> > > I don't think there is. I haven't raised it yet because I am not so sure
> > > this will not break again those worthless unreliable LID, and if we play
> > > whack a mole between the kernel and user space, things are going to be
> > > nasty. So I'd rather have this fixed in systemd along with the
> > > unreliable LID switch knowledge, so we are sure that the kernel behaves
> > > the way we expect it to be.
> >
> > This is my feeling:
> > We needn't go that far.
> > We can interpret "input node appears" into "default input node state".
> 
> Sorry, can you clarify this bit please? I'm not sure what you mean here.
> Note that there's an unknown amount of time between "device node appearing
> in the system" and when a userspace process actually opens it and looks at
> its state. By then, the node may have changed state again.

We can see:
"logind" has already implemented a timeout, and will not respond lid state
unless it can be stable within this timeout period.
I'm not an expert of logind, maybe this is because of "HoldOffTimeoutSec"?

I feel "removing the input node for a period where its state is not trustful"
is technically identical to this mechanism.

Cheers,
Lv

> 
> Cheers,
>Peter
> 
> > That's what you want for acpi button driver - we now defaults to "method" 
> > mode.
> >
> > What's your opinion?
> >
> > Thanks
> > Lv
> >
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

[Peter Hutterer]

On Thu, Jun 15, 2017 at 02:52:57AM +, Zheng, Lv wrote:
> Hi, Benjamin
> 
> > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> > Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID 
> > switch exported by ACPI
> > 
> > Hi,
> > 
> > [Sorry for the delay, I have been sidetracked from this]
> > 
> > On Jun 07 2017 or thereabouts, Lennart Poettering wrote:
> > > On Thu, 01.06.17 20:46, Benjamin Tissoires 
> > > (benjamin.tissoi...@redhat.com) wrote:
> > >
> > > > Hi,
> > > >
> > > > Sending this as a WIP as it still need a few changes, but it mostly 
> > > > works as
> > > > expected (still not fully compliant yet).
> > > >
> > > > So this is based on Lennart's comment in [1]: if the LID state is not 
> > > > reliable,
> > > > the kernel should not export the LID switch device as long as we are 
> > > > not sure
> > > > about its state.
> > >
> > > Ah nice! I (obviously) like this approach.
> > 
> > Heh. Now I just need to convince Lv that it's the right approach.
> 
> I feel we don't have big conflicts.
> And I already took part of your idea into this patchset:
> https://patchwork.kernel.org/patch/9771121/
> https://patchwork.kernel.org/patch/9771119/
> I tested my surface pros with Ubuntu, they are working as expected.
> 
> > > > Note that systemd currently doesn't sync the state when the input node 
> > > > just
> > > > appears. This is a systemd bug, and it should not be handled by the 
> > > > kernel
> > > > community.
> > >
> > > Uh if this is borked, we should indeed fix this in systemd. Is there
> > > already a systemd github bug about this? If not, please create one,
> > > and we'll look into it!
> > 
> > I don't think there is. I haven't raised it yet because I am not so sure
> > this will not break again those worthless unreliable LID, and if we play
> > whack a mole between the kernel and user space, things are going to be
> > nasty. So I'd rather have this fixed in systemd along with the
> > unreliable LID switch knowledge, so we are sure that the kernel behaves
> > the way we expect it to be.
> 
> This is my feeling:
> We needn't go that far.
> We can interpret "input node appears" into "default input node state".

Sorry, can you clarify this bit please? I'm not sure what you mean here.
Note that there's an unknown amount of time between "device node appearing
in the system" and when a userspace process actually opens it and looks at
its state. By then, the node may have changed state again.

Cheers,
   Peter

> That's what you want for acpi button driver - we now defaults to "method" 
> mode.
> 
> What's your opinion?
> 
> Thanks
> Lv
> 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel