Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

2017-06-07 Thread NeilBrown 
On Wed, Jun 07 2017, Steve Dickson wrote:

> On 06/07/2017 08:02 AM, Lennart Poettering wrote:
>> On Wed, 07.06.17 06:08, Steve Dickson (ste...@redhat.com) wrote:
>> 
>>>
>>>
>>> On 06/06/2017 05:49 PM, NeilBrown wrote:
 On Tue, Jun 06 2017, Steve Dickson wrote:

> Hello,
>
> On 05/29/2017 06:19 PM, NeilBrown wrote:
>>
>> Systemd does not, and will not, support "bg" correctly.
>> It has other, better, ways to handle "background" mounting.
> The only problem with this is bg mounts still work at least
> up to 4.11 kernel... 

 I don't think this is correct.
 In the default configuration, "mount -t nfs -o bg "
 runs for longer than 90 seconds, so systemd kill it.
>>> I must be missing something... it seems to be working for me
>>>
>>> # mount -vvv -o bg rhel7srv:/home/tmp /mnt/tmp
>>> mount.nfs: trying text-based options 
>>> 'bg,vers=4.1,addr=172.31.1.60,clientaddr=172.31.1.58'
>>> mount.nfs: mount(2): Connection refused
>>> mount.nfs: trying text-based options 'bg,addr=172.31.1.60'
>>> mount.nfs: prog 13, trying vers=3, prot=6
>>> mount.nfs: trying 172.31.1.60 prog 13 vers 3 prot TCP port 2049
>>> mount.nfs: portmap query failed: RPC: Remote system error - Connection 
>>> refused
>>> mount.nfs: backgrounding "rhel7srv:/home/tmp"
>>> mount.nfs: mount options: "rw,bg"
>> 
>> We are talking about mounts done through /etc/fstab, i.e. the ones
>> systemd actually manages.
> I guess I was not clear... After adding a bg mount to fstab and
> reboot, mounting a server that is not up, there is a mount in
> background that looks like 
>
> # ps ax | grep mount
>  1104 ?Ss 0:00 /sbin/mount.nfs nfssrv:/home/tmp /mnt/tmp -o rw,bg
>
> Looking at the remote-fs.target status:
>
> # systemctl status remote-fs.target 
> * remote-fs.target - Remote File Systems
>Loaded: loaded (/usr/lib/systemd/system/remote-fs.target; enabled; vendor 
> preset: enabled)
>Active: active since Tue 2017-06-06 12:36:51 EDT; 12min ago
>  Docs: man:systemd.special(7)
>
> Jun 06 12:36:51 f26.boston.devel.redhat.com systemd[1]: Reached target Remote 
> File Systems.
>
> It appears to be successful 

Strange ... not for me.

I have a recent compiled-from-source upstream systemd and a very recent
upstream kernel.

I add a line to /etc/fstab

 192.168.1.111:/nowhere /mnt nfs bg 0 0

and reboot (192.168.1.111 is on a different subnet to the VM I am
testing in, but no host responds to the address).

There is a 1m30s wait while trying to mount /mnt, then boot completes
(I was wrong when I said that it didn't).

● mnt.mount - /mnt
   Loaded: loaded (/etc/fstab; generated; vendor preset: enabled)
   Active: failed (Result: timeout) since Thu 2017-06-08 11:13:52 AEST; 1min 
24s ago
Where: /mnt
 What: 192.168.1.111:/nowhere
 Docs: man:fstab(5)
   man:systemd-fstab-generator(8)
  Process: 333 ExecMount=/bin/mount 192.168.1.111:/nowhere /mnt -t nfs -o bg 
(code=killed, signal=TERM)

Jun 08 11:12:22 debian systemd[1]: Mounting /mnt...
Jun 08 11:13:52 debian systemd[1]: mnt.mount: Mounting timed out. Stopping.
Jun 08 11:13:52 debian systemd[1]: mnt.mount: Mount process exited, code=killed 
status=15
Jun 08 11:13:52 debian systemd[1]: Failed to mount /mnt.
Jun 08 11:13:52 debian systemd[1]: mnt.mount: Unit entered failed state.


The /bin/mount process has been killed (SIGTERM) after the 90 second
timeout

● remote-fs.target - Remote File Systems
   Loaded: loaded (/lib/systemd/system/remote-fs.target; enabled; vendor 
preset: enabled)
  Drop-In: /run/systemd/generator/remote-fs.target.d
   └─50-insserv.conf.conf
   Active: inactive (dead)
 Docs: man:systemd.special(7)

Jun 08 11:13:52 debian systemd[1]: Dependency failed for Remote File Systems.
Jun 08 11:13:52 debian systemd[1]: remote-fs.target: Job remote-fs.target/start 
failed with result 'dependency'.


remote-fs.target has not been reached.

Because remote-fs.target is WantedBy multi-user.target, but need
RequiredBy it, boot completes.
But if anything did Require remote-fs.target, it would fail if "bg"
mounts were not mounted within 90 seconds.


Looking back over your log messages:

>>> mount.nfs: portmap query failed: RPC: Remote system error - Connection 
>>> refused
>>> mount.nfs: backgrounding "rhel7srv:/home/tmp"

it appears that the fg mount attempt failed quickly (ECONNREFUSED), so it
background the process immediately.  Systemd sees that as success
(despite the fact that the filesystem isn't actually mounted) and
doesn't clean up the background processes (which is arguably a bug).

If you try to mount from a server which doesn't even return ECONNREFUSED or
EHOSTUNREACH, such that the first mount attempt takes longer than 90
seconds, then you should get the same results as me.

Your results go some way to explaining why Lennart hasn't received many
complaints, but I'm convinced that the current situation is not ideal
(because SUSE has received some complaints).

I've been

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

2017-06-07 Thread Steve Dickson 


On 06/07/2017 08:02 AM, Lennart Poettering wrote:
> On Wed, 07.06.17 06:08, Steve Dickson (ste...@redhat.com) wrote:
> 
>>
>>
>> On 06/06/2017 05:49 PM, NeilBrown wrote:
>>> On Tue, Jun 06 2017, Steve Dickson wrote:
>>>
 Hello,

 On 05/29/2017 06:19 PM, NeilBrown wrote:
>
> Systemd does not, and will not, support "bg" correctly.
> It has other, better, ways to handle "background" mounting.
 The only problem with this is bg mounts still work at least
 up to 4.11 kernel... 
>>>
>>> I don't think this is correct.
>>> In the default configuration, "mount -t nfs -o bg "
>>> runs for longer than 90 seconds, so systemd kill it.
>> I must be missing something... it seems to be working for me
>>
>> # mount -vvv -o bg rhel7srv:/home/tmp /mnt/tmp
>> mount.nfs: trying text-based options 
>> 'bg,vers=4.1,addr=172.31.1.60,clientaddr=172.31.1.58'
>> mount.nfs: mount(2): Connection refused
>> mount.nfs: trying text-based options 'bg,addr=172.31.1.60'
>> mount.nfs: prog 13, trying vers=3, prot=6
>> mount.nfs: trying 172.31.1.60 prog 13 vers 3 prot TCP port 2049
>> mount.nfs: portmap query failed: RPC: Remote system error - Connection 
>> refused
>> mount.nfs: backgrounding "rhel7srv:/home/tmp"
>> mount.nfs: mount options: "rw,bg"
> 
> We are talking about mounts done through /etc/fstab, i.e. the ones
> systemd actually manages.
I guess I was not clear... After adding a bg mount to fstab and
reboot, mounting a server that is not up, there is a mount in
background that looks like 

# ps ax | grep mount
 1104 ?Ss 0:00 /sbin/mount.nfs nfssrv:/home/tmp /mnt/tmp -o rw,bg

Looking at the remote-fs.target status:

# systemctl status remote-fs.target 
* remote-fs.target - Remote File Systems
   Loaded: loaded (/usr/lib/systemd/system/remote-fs.target; enabled; vendor 
preset: enabled)
   Active: active since Tue 2017-06-06 12:36:51 EDT; 12min ago
 Docs: man:systemd.special(7)

Jun 06 12:36:51 f26.boston.devel.redhat.com systemd[1]: Reached target Remote 
File Systems.

It appears to be successful 

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

Re: [systemd-devel] more verbose debug info than systemd.log_level=debug?

2017-06-07 Thread Chris Murphy 
On Fri, May 19, 2017 at 1:46 PM, Chris Murphy  wrote:
> FYI the file system folks are discussing this. It is not just a
> problem with XFS it can affect ext4 too. And it's far from clear the
> fs folks have a solution that won't cause worse problems.


OK so this is what I got out of those conversations

sync() -> write data to disk, write metadata to log
FIFREEZE() -> sync() and write log contents to fs.
unmount() -> sync() write log contents to fs.
reboot() -> sync() and reboot.

Only on non-journaled file systems does sync() mean write data to
disk, write metadata to fs, because there's no log.

sync() only makes the file system crash safe. It's doesn't mean the
bootloader can find files: configuration, kernel, initramfs, if they
are only sync()'d because the bootloader has no idea how to read the
log. And the fs itself isn't up to date because the log is dirty.

The most central blame here goes to the bootloader: specifically that
which makes changes to the bootloader configuration in a manner that
(pretty much) guarantees the bootloader proper (the binary that
executes after POST) will not be able to find either the old or new
configuration. At the least if it found the old configuration, it
would boot the old kernel and initramfs, which would then cause the
journal to be replayed, the file system updated, and on next boot, the
new configuration, kernel, and initramfs would get used. Because the
bootloader has a special requirement, since it cannot read dirty logs,
the thing making bootloader related changes needs to make sure that
its updates are not merely crash safe, but are actually fully
committed to the file system. That requires fsfreeze.

That implicates grub-mkconfig (for GRUB), grubby (not related to GRUB,
used on Red Hat, CentOS, Fedora systems), and myriad kernel package
scripts that modify bootloader configurations, kernels, and initramfs
out in the wild. The first two: grub-mkconfig and grubby, probably
represent a fairly good chunk of deployments. But there's still a
bunch of non-Red Hat systems that do not use GRUB, and do not use
grubby, they depend on the kernel package post-install scripts to make
bootloader changes, and that is what would need to do fsfreeze.

Or systemd can help pick up some of the slack and figure out a way to
either make sure one of three things definitely happens before a
reboot: umount, remount-ro, or fsfreeze. Of course, not every distro
uses systemd, and so only solving the central problem is a solution on
those distros, but in either case that's not systemd's responsibility.


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

Re: [systemd-devel] Systemd license vs. libcryptsetup license

2017-06-07 Thread Zbigniew Jędrzejewski-Szmek 
On Wed, Jun 07, 2017 at 05:26:21PM +0200, Krzysztof Jackiewicz wrote:
> Thanks, for explanation.
>  
> > - a collection of rpms, like a linux distro, including systemd.rpm,
> >   libcryptsetup.rpm, and thousands of other loosely coupled rpms
> >   → that's a mere aggregation, each of the thousands of components carries
> >   it's own license, each has to be satisfied separately
> 
> It is mere aggregation as long as binary from systemd.rpm does not link to a 
> library from libcryptsetup.rpm. If it does then it's a combination or a 
> derivative work in terms of GPL and as such the systemd.rpm should include a 
> GPL license (and of course comply with other GPL terms and conditions). Is 
> that correct?

No, that makes no sense. It'd mean that putting two zip files that one
provides and the other uses a function with the same name next to one
another would make them somehow connected and derivatives of one
another. The whole point of dynamic linking is that you can provide
independent implementations of the API, and you can clearly substitute
libcryptsetup with another implementation, and both bodies of code are
usable without one another.

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

Re: [systemd-devel] Systemd license vs. libcryptsetup license

2017-06-07 Thread Greg KH 
On Wed, Jun 07, 2017 at 05:26:21PM +0200, Krzysztof Jackiewicz wrote:
> Thanks, for explanation.
>  
> > - a collection of rpms, like a linux distro, including systemd.rpm,
> >   libcryptsetup.rpm, and thousands of other loosely coupled rpms
> >   → that's a mere aggregation, each of the thousands of components carries
> >   it's own license, each has to be satisfied separately
> 
> It is mere aggregation as long as binary from systemd.rpm does not
> link to a library from libcryptsetup.rpm. If it does then it's a
> combination or a derivative work in terms of GPL and as such the
> systemd.rpm should include a GPL license (and of course comply with
> other GPL terms and conditions). Is that correct?

You need to consult a lawyer to get a definitive answer for this, please
don't ask developers for legal advice :)

good luck!

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

Re: [systemd-devel] Systemd license vs. libcryptsetup license

2017-06-07 Thread Krzysztof Jackiewicz 
Thanks, for explanation.
 
> - a collection of rpms, like a linux distro, including systemd.rpm,
>   libcryptsetup.rpm, and thousands of other loosely coupled rpms
>   → that's a mere aggregation, each of the thousands of components carries
>   it's own license, each has to be satisfied separately

It is mere aggregation as long as binary from systemd.rpm does not link to a 
library from libcryptsetup.rpm. If it does then it's a combination or a 
derivative work in terms of GPL and as such the systemd.rpm should include a 
GPL license (and of course comply with other GPL terms and conditions). Is that 
correct?

Krzy


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

Re: [systemd-devel] Systemd license vs. libcryptsetup license

2017-06-07 Thread Zbigniew Jędrzejewski-Szmek 
On Wed, Jun 07, 2017 at 11:47:58AM +0200, Krzysztof Jackiewicz wrote:
> > Not sure what "release product under GPL" is supposed to mean.
> 
> The combined work would have to be licensed under GPL according to:
> https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
> https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
> I think that it means that the code has to be relicensed to GPL (which LGPL
> 2.1 allows). I'm not sure about it either. That's why I'm asking.

You are right that the combined work is licensed under the GPL.
But no, that has no effect on the source code itself, and there's no
reason for the source code to have to be relicensed.

> > libcryptsetup dep is optional anyway, and only used by the
> systemd-cryptsetup
> > helper, not PID 1 itself.
> 
> I'm asking about license issues with this specific option enabled. Also, I
> don't think it matters which binary it is as long as it's included in a
> final product. 

Right.

> > Unless you link your own more restrictive code into systemd-cryptsetup the
> GPL
> > dep that is libcryptsetup should not affect you in any way. At least not
> more
> > than the Linux kernel's own GPL license does. I mean, systemd doesn't
> support
> > any other kernels anyway...
> 
> AFAIK using the kernel (syscalls) is not considered a derivative work.
> Dynamic linking is (in terms of GPL).

Right, but dynamic linking happens on the target machine. And the LGPL
and GPL license only place conditions on distributions, so before any
distribution happens, you can do whatever with the code. Let's instead look
at some points along the spectrum of possible distribution mechanisms:

- statically linked libcryptsetup + systemd, and the resulting binaries
  distributed in a tarball → clearly derived from both, can only be distributed
  under GPL
- libcryptsetup + systemd linked into an image in memory, i.e. the result
  of dynamic linking, saved for distribution as a VM snapshot or emacs-style
  memory image → the same as above
- just systemd.rpm → only systemd license applies, i.e. it's OK to distribute
  under terms of LGPL. (Though that's basically unusable, until
  you provide multiple libraries and executables from elsewhere, the rest of
  the filesystem, etc.)
- a collection of rpms, like a linux distro, including systemd.rpm,
  libcryptsetup.rpm, and thousands of other loosely coupled rpms
  → that's a mere aggregation, each of the thousands of components carries
  it's own license, each has to be satisfied separately
- you compile systemd and libcryptsetup into a bunch of dlls to run
  on windows and distribute the result in a nifty .exe installer
  → that's somewhere between the first case and fourth, but the installer
  as a whole can only be distributed under the GPL, since it contains
  GPL-only code.

So it depends on what you're trying to do with the systemd code, but
except for the contrived cases, you're free to use LGPL as stated.

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

[systemd-devel] Fwd: Unclean shutdown causes vncserver to not use correct settings

2017-06-07 Thread Samuel Rakitničan 
Hello,

So I am using vncserver on a CentOS system from base repo. I have the
systemd service enabled to start vncserver automatically on each boot.

I found out that vncserver is complaining about /tmp/.X11-unix/X1 socket
file present almost each time shutdown is unclean due to freeze or power
loss.

The service I am using that comes from base repo package looks like
following. File is meant to be copied over to /etc/systemd/system with
 substituted accordingly.

[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=forking
# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/usr/sbin/runuser -l  -c "/usr/bin/vncserver %i"
PIDFile=/home//.vnc/%H%i.pid
ExecStop=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'

[Install]
WantedBy=multi-user.target


It seems this is doing the right thing, it is calling "vncserver -kill" on
configured display each time before vncserver, but somehow that doesn't
work and in the log I see:

Jun 06 13:58:43 host runuser[1188]: pam_unix(runuser-l:session): session
opened for user  by (uid=0)
Jun 06 13:58:43 host runuser[1188]: Warning: host:1 is taken because of
/tmp/.X11-unix/X1
Jun 06 13:58:43 host runuser[1188]: Remove this file if there is no X
server host:1
Jun 06 13:58:43 host runuser[1188]: A VNC server is already running as :1
Jun 06 13:58:43 host runuser[1188]: Warning: host:1 is taken because of
/tmp/.X11-unix/X1
Jun 06 13:58:43 host runuser[1188]: Remove this file if there is no X
server host:1
Jun 06 13:58:46 host runuser[1188]: New 'host:2 (srakit)' desktop is host:2
Jun 06 13:58:46 host runuser[1188]: Starting applications specified in
/home//.vnc/xstartup
Jun 06 13:58:46 host runuser[1188]: Log file is
/home//.vnc/host:2.log
Jun 06 13:58:46 host runuser[1188]: pam_unix(runuser-l:session): session
closed for user 


Any idea what is happening here, maybe a race condition?

If I restart the systemd service manually later it works, no problem. I
don't know it /tmp/.X11-unix/X1 file exists immediately after an
unsuccessful start, I always forget to check.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sd_bus_add_filter usage

2017-06-07 Thread Lennart Poettering 
On Wed, 07.06.17 14:01, Pawel Szewczyk (p.szewc...@samsung.com) wrote:

> Hello,
> 
> What is the purpose of sd_bus_add_filter() function? There is no
> documentation for it and all I can tell from looking over the code is that
> the callback registered by it is called on every dbus message. What else
> does it do?

Nothing. It may be used to install a callback that is called early for
each incoming message and may be used to filter them (i.e. drop them
or permit them) or otherwise process them. They do not install any match,
and hence only get what other matches have already selected.

Lennart

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

[systemd-devel] sd_bus_add_filter usage

2017-06-07 Thread Pawel Szewczyk 

Hello,

What is the purpose of sd_bus_add_filter() function? There is no 
documentation for it and all I can tell from looking over the code is 
that the callback registered by it is called on every dbus message. What 
else does it do?


Regards,
Paweł Szewczyk
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

2017-06-07 Thread Lennart Poettering 
On Wed, 07.06.17 06:08, Steve Dickson (ste...@redhat.com) wrote:

> 
> 
> On 06/06/2017 05:49 PM, NeilBrown wrote:
> > On Tue, Jun 06 2017, Steve Dickson wrote:
> > 
> >> Hello,
> >>
> >> On 05/29/2017 06:19 PM, NeilBrown wrote:
> >>>
> >>> Systemd does not, and will not, support "bg" correctly.
> >>> It has other, better, ways to handle "background" mounting.
> >> The only problem with this is bg mounts still work at least
> >> up to 4.11 kernel... 
> > 
> > I don't think this is correct.
> > In the default configuration, "mount -t nfs -o bg "
> > runs for longer than 90 seconds, so systemd kill it.
> I must be missing something... it seems to be working for me
> 
> # mount -vvv -o bg rhel7srv:/home/tmp /mnt/tmp
> mount.nfs: trying text-based options 
> 'bg,vers=4.1,addr=172.31.1.60,clientaddr=172.31.1.58'
> mount.nfs: mount(2): Connection refused
> mount.nfs: trying text-based options 'bg,addr=172.31.1.60'
> mount.nfs: prog 13, trying vers=3, prot=6
> mount.nfs: trying 172.31.1.60 prog 13 vers 3 prot TCP port 2049
> mount.nfs: portmap query failed: RPC: Remote system error - Connection refused
> mount.nfs: backgrounding "rhel7srv:/home/tmp"
> mount.nfs: mount options: "rw,bg"

We are talking about mounts done through /etc/fstab, i.e. the ones
systemd actually manages.

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] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

2017-06-07 Thread Steve Dickson 


On 06/06/2017 05:49 PM, NeilBrown wrote:
> On Tue, Jun 06 2017, Steve Dickson wrote:
> 
>> Hello,
>>
>> On 05/29/2017 06:19 PM, NeilBrown wrote:
>>>
>>> Systemd does not, and will not, support "bg" correctly.
>>> It has other, better, ways to handle "background" mounting.
>> The only problem with this is bg mounts still work at least
>> up to 4.11 kernel... 
> 
> I don't think this is correct.
> In the default configuration, "mount -t nfs -o bg "
> runs for longer than 90 seconds, so systemd kill it.
I must be missing something... it seems to be working for me

# mount -vvv -o bg rhel7srv:/home/tmp /mnt/tmp
mount.nfs: trying text-based options 
'bg,vers=4.1,addr=172.31.1.60,clientaddr=172.31.1.58'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'bg,addr=172.31.1.60'
mount.nfs: prog 13, trying vers=3, prot=6
mount.nfs: trying 172.31.1.60 prog 13 vers 3 prot TCP port 2049
mount.nfs: portmap query failed: RPC: Remote system error - Connection refused
mount.nfs: backgrounding "rhel7srv:/home/tmp"
mount.nfs: mount options: "rw,bg"

# ps ax | grep mount.nfs
 2270 ?Ss 0:00 /sbin/mount.nfs rhel7srv:/home/tmp /mnt/tmp -v -o 
rw,bg

> 
> A working "bg" mount would successfully mount the filesystem is the
> server came back after 5 minutes. If you use current systemd in the
> default configuration, it won't.
When I add a bg mount to fstab again... it works just fine. This
is with the latest upstream nfs-utils. 

> 
> bg mounts do work sometimes, but I don't think they are reliable, and
> there seems to be no interest in changing this.
> Maybe the text should say "Systemd does not, and will not, reliably
> support "bg" mounts...".
not reliable maybe... I'm just doing very simple testing... 
> 
> 
>>
>> It appears there is a problem with a 4.12 kernel. The mount no 
>> longer errors out with ECONNREFUSED it just hangs in the 
>> kernel trying forever... It sounds like a bug to me but 
>> maybe that change was intentional.. Anna?? Trond???
> 
> Might be related to my patch
>   [PATCH] SUNRPC: ensure correct error is reported by xs_tcp_setup_socket()
> 
> sent 25th May.
I'll take a look.. thanks!

> 
>>
>> So I'm a bit hesitant to commit this since not accurate, yet.
>>
>> Finally, the whole idea of systemd randomly/silently 
>> strip off mount options is crazy... IMHO... 
> 
> It isn't exactly systemd, it is systemd-fstab-generator.
> The options lists in /etc/fstab are not all equal.  Some
> are relevant to /bin/mount, some to mount.nfs, some to the kernel.
> I think /bin/mount processes the option lists before passing it
> to mount.nfs.  There is no intrinsic reason that systemd-fstab-generator
> shouldn't do the same thing.
OK. 
> 
>>
>> Just because a concept that has been around for years
>> does not fix well in the systemd world it gets
>> rip out??? IDK... but I think we can do better than that.
> 
> I could suggest that automount is uniformly better than bg.  Give how
> long automount has been around, and how easy it is to use with systemd,
> it might be time to start encouraging people to stop using the inferior
> technology.
Yes... bg mounts are a poor man's automount... 
> 
> I could say that, but I'm not 100% sure.  The difference between
> automount and bg is that with bg it is easy to see if the mount has
> succeeded yet - just look for an empty directory.  With automount,
> you'll typically get a delay at that point.  We could possibly wind down
> that delay...
> 
>>
>> Note, the 'bg' is used by clients that do want their
>> booting to hang by servers that are down so if the 
>> option is rip out, boots will start hang. This
>> will make it very difficult to debug since the bg
>> will still exist in fstab.
> 
> Not exactly.
> Current default behaviour is that systemd will wait 90 seconds, then
> kill the mount program and fail the boot.  If we strip out "bg", the
> same thing will happen.
Again.. I'm not seeing this 90 sec delay when I add a bg mount
to /etc/fstab.

> 
> I'm OK with the patch not being applied just yet.  I think we need to
> resolve this issue, but it isn't 100% clear to me what the best
> resolution would be.  So I'm happy to see a conversation happening and
> opinions being shared.
> I'd be particularly pleased if you could double check how "bg" is
> currently handled on some systemd-enabled system that you use.
> Does the mount program get killed like I see?  
No. after adding a bg mount to fstab and rebooting (with the server
down) I see the following mount in backgroup 
   1104 ?Ss 0:00 /sbin/mount.nfs nfssrv:/home/tmp /mnt/tmp -o rw,bg

> Does boot succeed if there is a bg mount from an unresponsive server?
Yes. Then when I bring up the server the mount succeeds

steved.

P.S. I'm taking some PTO today so I will not be back in the office
until later today or tomorrow... 

steved.
 
> 
> Thanks,
> NeilBrown
> 
> 
>>
>> Again, the whole concept of systemd messing with mounts options
>> is just not a good one... IMHO..

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

2017-06-07 Thread Steve Dickson 


On 06/07/2017 04:12 AM, Lennart Poettering wrote:
> On Tue, 06.06.17 14:07, Steve Dickson (ste...@redhat.com) wrote:
> 
>> Hello,
>>
>> On 05/29/2017 06:19 PM, NeilBrown wrote:
>>>
>>> Systemd does not, and will not, support "bg" correctly.
>>> It has other, better, ways to handle "background" mounting.
>> The only problem with this is bg mounts still work at least
>> up to 4.11 kernel... 
>>
>> It appears there is a problem with a 4.12 kernel. The mount no 
>> longer errors out with ECONNREFUSED it just hangs in the 
>> kernel trying forever... It sounds like a bug to me but 
>> maybe that change was intentional.. Anna?? Trond???
>>
>> So I'm a bit hesitant to commit this since not accurate, yet.
>>
>> Finally, the whole idea of systemd randomly/silently 
>> strip off mount options is crazy... IMHO... 
>>
>> Just because a concept that has been around for years
>> does not fix well in the systemd world it gets
>> rip out??? IDK... but I think we can do better than that.
> 
> Well "bg" doesn't really work on systemd systems, and this was never
> different, hence I think it's only fair to document that it is
> incompatible with systemd. 
I'm seeing it work just fine... 

/etc/fstab: nfssrv:/home/tmp /mnt/tmp nfs bg 0 0
nfssrv is down 
reboot client 
login to client 
# ps ax | grep mount
  980 ?Ss 0:00 /sbin/mount.nfs nfssrv:/home/tmp /mnt/tmp -o rw,bg


> In addition, I have the suspicion it is not
> used very widely, since I never actually got complaints about it.
Since it seems to be still working we probably would not hear
any complaints about it... 

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

Re: [systemd-devel] [WIP PATCH 2/4] ACPI: button: remove the LID input node when the state is unknown

2017-06-07 Thread Zheng, Lv 
Hi, Benjamin

> From: linux-acpi-ow...@vger.kernel.org 
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Benjamin
> Tissoires
> Subject: Re: [WIP PATCH 2/4] ACPI: button: remove the LID input node when the 
> state is unknown
> 
> Hi Lv,
> 
> On Jun 05 2017 or thereabouts, Zheng, Lv wrote:
> > Hi, Benjamin
> >
> > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> > > Subject: [WIP PATCH 2/4] ACPI: button: remove the LID input node when the 
> > > state is unknown
> 
> > My dell latitude 6430u test platform sends multiple Notify(lid) before 
> > suspend and after resume.
> 
> Does this platform requires the not lid_reliable check as per this
> series? Because if it doesn't, then we should not care.

No need to mark lid_reliable.

> > This is because the aml table puts many Notify(LID, 0x80) in various 
> > control methods.
> > And not one of them but multiple of them will be invoked by various OS 
> > drivers during suspend/resume
> period.
> > I think this is not an isolated platform that will invoke multiple 
> > redundant "Notify(lid)".
> >
> > Fortunately, the lid state for the multiple notify(lid) should be same as 
> > the first "Notify(lid)".
> > I suppose this is why SW_LID is invented, as it can really filter such 
> > redundant events.
> > And user space finally can only see 1 "close" event.
> >
> > But unconditionally prepending "open" before all "close" events surely can 
> > break the logic by
> > delivering multiple "close" events to the user space.
> 
> That doesn't matter. What matters is the state of the switch, not the
> event. So if user space receives (in case we marked the switch as not
> reliable) several close events, all user space will do is realize that
> the state is still closed and will act accordingly.

OK, I tried to address this here:
https://patchwork.kernel.org/patch/9771121/

> > Another issue is, for case 5, when we use button.lid_init_state=method.
> > Unconditionally prepending "open" before driver initiated "close" event
> > sent due to acpi_lid_initialize_state(), we will see suspend/resume cycles.
> 
> Case 5 is broken anyway and needs to be handled specially. It was not
> targeted in this WIP series.

It was addressed by button.lid_init_state=open and newer systemd.
It's not broken any more.


> > Thus if we consider both cases, we should:
> > 1. put a frequency check to filter possible redundant events.
> 
> This doesn't work and should be avoided. The state of the input switch
> is known to the input layer only, and given there are spinlocks, you can
> not know if the state is actually the one you expected beforehand.
> 
> You can however add frequency checks in the input handler, but that
> would assume the input layer is not doing its job properly and so should
> be avoided.

OK, I dropped frequency check mechanism.

> > 2. distinguish AML "Notify" call and button driver initiated lid 
> > notification.
> 
> Again, we don't care if the "event" comes from ACPI, the driver itself or
> user space (libinput). All that matters is the current state of the
> input node switch, that needs to match the physical world at any time.

That depends on the final test result.
However I managed to get systemd working with case 2,4 using this commit:
https://patchwork.kernel.org/patch/9771121/

> > This is another major differences between your proposal and mine.
> >
> > First of all, I think it should be in a separate patch.
> 
> Well, that's already a patch on its own :/
> 
> >
> > Second, I have concerns related to such a change:
> > I can see that, you are trying to address a problem that:
> > The input layer requires a determined initial SW_LID state while ACPI 
> > button driver cannot offer.
> > So by adding/removing input node, you can introduce a tristate SW_LID input 
> > node.
> 
> You can put it that way. I prefer putting it: "when we export the LID
> switch input node, you are guaranteed to have the proper state".
> 
> > However I doubt if this is necessary and can solve real issues, as:
> > systemd now works fine with button driver for all cases,
> 
> I do not care about systemd or the suspend lopps introduced by systemd.
> All I care is that the kernel provides correct behavior. If systemd can
> work around some issues we see because we are too lazy to fix them in
> the kernel (this is not a personal attack, sometimes being lazy is the
> right solution), fine. But the current state of this driver doesn't
> follow the specification of the input subsystem on some platform, and
> this is what this series fixes.

No, we just can see if case 5 is properly addressed (like current systemd 233 
does),
we don't need to do anything.
So if you still insist to fix systemd 229, I just post an RFC:
https://patchwork.kernel.org/patch/9771121/

> > only desktop managers should be changed to be compliant to case 2/4/5
> 
> As long as the kernel lies, we should not even remotely envision asking
> user space to change.

By reverting back to "method" mode

Re: [systemd-devel] Systemd license vs. libcryptsetup license

2017-06-07 Thread Krzysztof Jackiewicz 
> Not sure what "release product under GPL" is supposed to mean.

The combined work would have to be licensed under GPL according to:
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
I think that it means that the code has to be relicensed to GPL (which LGPL
2.1 allows). I'm not sure about it either. That's why I'm asking.

> libcryptsetup dep is optional anyway, and only used by the
systemd-cryptsetup
> helper, not PID 1 itself.

I'm asking about license issues with this specific option enabled. Also, I
don't think it matters which binary it is as long as it's included in a
final product. 

> Unless you link your own more restrictive code into systemd-cryptsetup the
GPL
> dep that is libcryptsetup should not affect you in any way. At least not
more
> than the Linux kernel's own GPL license does. I mean, systemd doesn't
support
> any other kernels anyway...

AFAIK using the kernel (syscalls) is not considered a derivative work.
Dynamic linking is (in terms of GPL).

Krzy

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

[systemd-devel] [RFC PATCH 0/2] ACPI: button: Fix button.lid_init_state=method mode

2017-06-07 Thread Lv Zheng 
The following approach fixes button.lid_init_state=method mode for
systemd 233:
 https://patchwork.kernel.org/patch/9756457/
 https://patchwork.kernel.org/patch/9756467/
But it is not working well with old systemd 229. This solution tries to
make a more comfortable approach for systemd 229.

There are platform variations implementing ACPI lid device in different
way:
1. Some platforms send "open" events to OS and the events arrive before
   button driver is resumed;
2. Some platforms send "open" events to OS, but the events arrive after
   button driver is resumed, ex., Samsung N210+;
3. Some platforms never send "open" events to OS, but send "open" events to
   update the cached _LID return value, and the update events arrive before
   button driver is resumed;
4. Some platforms never send "open" events to OS, but send "open" events to
   update the cached _LID return value, but the update events arrive after
   button driver is resumed, ex., Surface Pro 3;
5. Some platforms never send "open" events, _LID returns value sticks to
   "close", ex., Surface Pro 1.

[PATCH 1] tries to fix case 2,4, making them working with any systemd.
[PATCH 2] tries to fix case 5, making it working with systemd 233.
  This is also a replacement of the following solution:
   https://patchwork.kernel.org/patch/9760867/
  It seems adding/removing input node and requesting systemd to
  change again is unnecessary for such platforms, so this patch
  simply converts "lid_unreliable" into
  "button.lid_init_state=ignore".

This material is just sent to demonstrate solutions and issues, the
final solution is not determined yet. So marking them as RFC.

Lv Zheng (2):
  ACPI: button: Fix issue that button notify cannot report stateful
SW_LID state
  ACPI: button: Add a quirk mode for Surface Pro 1 like laptop

 drivers/acpi/button.c | 188 --
 1 file changed, 89 insertions(+), 99 deletions(-)

-- 
2.7.4

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

Re: [systemd-devel] [WIP PATCH 4/4] ACPI: button: Fix lid notification locks

2017-06-07 Thread Zheng, Lv 
Hi, Benjamin

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [WIP PATCH 4/4] ACPI: button: Fix lid notification locks
> 
> On Jun 05 2017 or thereabouts, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> > > Subject: [WIP PATCH 4/4] ACPI: button: Fix lid notification locks
> > >
> > > From: Lv Zheng 
> > >
> > > acpi/button.c now contains the logic to avoid frequently replayed events
> > > which originally was ensured by using blocking notifier.
> > > On the contrary, using a blocking notifier is wrong as it could keep on
> > > returning NOTIFY_DONE, causing events lost.
> > >
> > > This patch thus changes lid notification to raw notifier in order not to
> > > have any events lost.
> >
> > This patch is on top of the following:
> > https://patchwork.kernel.org/patch/9756467/
> > where button driver implements a frequency check and
> > thus is capable of filtering redundant events itself:
> > I saw you have deleted it from PATCH 02.
> > So this patch is not applicable now.
> 
> I actually rebased it in this series. I kept your SoB line given that
> the idea came from you and the resulting patch was rather similar (only
> one hunk differs, but the meaning is the same).
> 
> >
> > Is input layer capable of filtering redundant events.
> 
> I don't think it does, and it should not. If an event is emitted, it has
> to be forwarded. However, the logic of the protocol makes that the only
> state that matters is when an EV_SYN is emitted. So if a SW_LID 0 then 1
> is sent between the 2 EV_SYN, and the state was 1 before, from a
> protocol point of view it's a no-op.
> 
> > I saw you unconditionally prepend "open" before "close",
> > which may make input layer incapable of filtering redundant close events.
> 
> Again, we don't care about events. We care about states, and those are
> only emitted when the lid is marked as non reliable.
> 
> >
> > If input layer is capable of filtering redundant events,
> > why don't you:
> > 1. drop this commit;
> > 2. remove all ACPI lid notifier APIs;
> > 3. change lid notifier callers to register notification via input layer?
> 
> Having the i915 driver listening to the input events is actually a good
> solution. Let me think about it a little bit more and I'll come back.

OK, then I'll drop the frequency check mechanism and drop patch 4/5.

Cheers,
Lv

> 
> Cheers,
> Benjamin
> 
> >
> > Thanks and best regards
> > Lv
> >
> > >
> > > Signed-off-by: Lv Zheng 
> > > Signed-off-by: Benjamin Tissoires 
> > > ---
> > >  drivers/acpi/button.c | 68 
> > > ---
> > >  1 file changed, 27 insertions(+), 41 deletions(-)
> > >
> > > diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> > > index 03e5981..1927b08 100644
> > > --- a/drivers/acpi/button.c
> > > +++ b/drivers/acpi/button.c
> > > @@ -114,7 +114,7 @@ struct acpi_button {
> > >
> > >  static DEFINE_MUTEX(button_input_lock);
> > >
> > > -static BLOCKING_NOTIFIER_HEAD(acpi_lid_notifier);
> > > +static RAW_NOTIFIER_HEAD(acpi_lid_notifier);
> > >  static struct acpi_device *lid_device;
> > >  static u8 lid_init_state = ACPI_BUTTON_LID_INIT_METHOD;
> > >
> > > @@ -179,14 +179,12 @@ static int acpi_lid_evaluate_state(struct 
> > > acpi_device *device)
> > >   return lid_state ? 1 : 0;
> > >  }
> > >
> > > -static int acpi_lid_notify_state(struct acpi_device *device, int state)
> > > +static void acpi_lid_notify_state(struct acpi_device *device, int state)
> > >  {
> > >   struct acpi_button *button = acpi_driver_data(device);
> > >
> > > - /* button_input_lock must be held */
> > > -
> > >   if (!button->input)
> > > - return 0;
> > > + return;
> > >
> > >   /*
> > >* If the lid is unreliable, always send an "open" event before any
> > > @@ -201,8 +199,6 @@ static int acpi_lid_notify_state(struct acpi_device 
> > > *device, int state)
> > >
> > >   if (state)
> > >   pm_wakeup_hard_event(>dev);
> > > -
> > > - return 0;
> > >  }
> > >
> > >  /*
> > > @@ -214,28 +210,14 @@ static void acpi_button_lid_events(struct 
> > > input_handle *handle,
> > >  {
> > >   const struct input_value *v;
> > >   int state = -1;
> > > - int ret;
> > >
> > >   for (v = vals; v != vals + count; v++) {
> > >   switch (v->type) {
> > >   case EV_SYN:
> > > - if (v->code == SYN_REPORT && state >= 0) {
> > > - ret = 
> > > blocking_notifier_call_chain(_lid_notifier,
> > > + if (v->code == SYN_REPORT && state >= 0)
> > > + 
> > > (void)raw_notifier_call_chain(_lid_notifier,
> > >   state,
> > >   lid_device);
> > > - if (ret == NOTIFY_DONE)
> > > - ret = 
> > >

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

2017-06-07 Thread Steve Dickson 


On 06/07/2017 04:13 AM, Lennart Poettering wrote:
> On Tue, 06.06.17 21:57, Michael Biebl (mbi...@gmail.com) wrote:
> 
>> 2017-06-06 20:07 GMT+02:00 Steve Dickson :
>>> Finally, the whole idea of systemd randomly/silently
>>> strip off mount options is crazy... IMHO...
>>
>> Personally, I would prefer if systemd simply logged a warning/error
>> message but would *not* strip the bg option.
> 
> What good does that do if "bg" doesn't actually work properly?
At the moment it works just fine... 

steved.

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

[systemd-devel] [RFC PATCH v5 1/2] ACPI: button: Fix issue that button notify cannot report stateful SW_LID state

2017-06-07 Thread Lv Zheng 
There are platform variations implementing ACPI lid device in different
ways:
1. Some platforms send "open" events to OS and the events arrive before
   button driver is resumed;
2. Some platforms send "open" events to OS, but the events arrive after
   button driver is resumed, ex., Samsung N210+;
3. Some platforms never send "open" events to OS, but send "open" events to
   update the cached _LID return value, and the update events arrive before
   button driver is resumed;
4. Some platforms never send "open" events to OS, but send "open" events to
   update the cached _LID return value, but the update events arrive after
   button driver is resumed, ex., Surface Pro 3;
5. Some platforms never send "open" events, _LID returns value sticks to
   "close", ex., Surface Pro 1.
Currently, only case 1,3 works fine with systemd 229.

Case 2,4 can be treated as an order issue. This patch first fixes this
issue by defer sending initial lid state 10 seconds later after resume,
which ensures acpi_ec_resume() is always invoked before
acpi_button_resume().

However we can see different problems due to systemd bugs:
  systemd won't suspend right after seeing "close" event, it has a timeout,
  within the timeout, user may opens lid again. But even lid
  firmware/driver properly deliver this "open" to user space, when the
  timeout tickes, systemd still suspends the platform.
  Then user has to close/open again to wake the system up. Noticing that
  the first close event will remain in firmware, after resume, user space
  can still see a "close" followed by "open", and nothing can stop systemd
  from suspending again.
This problem can only be fixed by continously updating lid state. Thus
this patch doesn't kill the timer after seeing the BIOS notification, but
continously sending _LID return value to the input layer for
button.lid_init_state=method mode.

The users can configure update interval via button.lid_update_interval.

Cc: 
Cc: Benjamin Tissoires 
Cc: Peter Hutterer 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/button.c | 36 +---
 1 file changed, 29 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index e19f530..fd8eff6 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -79,6 +80,7 @@ MODULE_DEVICE_TABLE(acpi, button_device_ids);
 static int acpi_button_add(struct acpi_device *device);
 static int acpi_button_remove(struct acpi_device *device);
 static void acpi_button_notify(struct acpi_device *device, u32 event);
+static void acpi_lid_timeout(ulong arg);
 
 #ifdef CONFIG_PM_SLEEP
 static int acpi_button_suspend(struct device *dev);
@@ -104,6 +106,7 @@ static struct acpi_driver acpi_button_driver = {
 struct acpi_button {
unsigned int type;
struct input_dev *input;
+   struct timer_list lid_timer;
char phys[32];  /* for input device */
unsigned long pushed;
int last_state;
@@ -119,6 +122,10 @@ static unsigned long lid_report_interval __read_mostly = 
500;
 module_param(lid_report_interval, ulong, 0644);
 MODULE_PARM_DESC(lid_report_interval, "Interval (ms) between lid key events");
 
+static unsigned long lid_update_interval __read_mostly = 10 * MSEC_PER_SEC;
+module_param(lid_update_interval, ulong, 0644);
+MODULE_PARM_DESC(lid_update_interval, "Interval (ms) between lid state 
updates");
+
 /* --
   FS Interface (/proc)
-- 
*/
@@ -371,17 +378,25 @@ static int acpi_lid_update_state(struct acpi_device 
*device)
return acpi_lid_notify_state(device, state);
 }
 
-static void acpi_lid_initialize_state(struct acpi_device *device)
+static void acpi_lid_tick(struct acpi_device *device)
+{
+   struct acpi_button *button = acpi_driver_data(device);
+
+   mod_timer(>lid_timer,
+ jiffies + msecs_to_jiffies(lid_update_interval));
+}
+
+static void acpi_lid_timeout(ulong arg)
 {
+   struct acpi_device *device = (struct acpi_device *)arg;
+
switch (lid_init_state) {
case ACPI_BUTTON_LID_INIT_OPEN:
(void)acpi_lid_notify_state(device, 1);
break;
case ACPI_BUTTON_LID_INIT_METHOD:
-   (void)acpi_lid_update_state(device);
-   break;
-   case ACPI_BUTTON_LID_INIT_IGNORE:
-   default:
+   acpi_lid_update_state(device);
+   acpi_lid_tick(device);
break;
}
 }
@@ -432,6 +447,8 @@ static int acpi_button_suspend(struct device *dev)
struct acpi_device *device = to_acpi_device(dev);
struct acpi_button *button =

[systemd-devel] [RFC PATCH v5 2/2] ACPI: button: Add a quirk mode for Surface Pro 1 like laptop

2017-06-07 Thread Lv Zheng 
Some platforms never send "open" events, _LID returns value sticks to
"close", ex., Surface Pro 1.

Such platforms cannot work well with systemd 229 in
button.lid_init_state=method mode, but button.lid_init_state=open
workaround is available for them to work with systemd 229 and they can work
perfectly with systemd 233 in button.lid_init_state=ignore mode.

This patch introduces a boot parameter to mark such platform lid device as
unreliable to replace old button.lid_init_state=ignore mode. So that users
can use this quirk to make such platforms working with systemd 233. Since
such platform only sends "close", old complicated "open" complement event
mechanism is replaced by a simpler one of always prepending "open" before
any events.

Cc: 
Cc: Benjamin Tissoires 
Cc: Peter Hutterer 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/button.c | 164 --
 1 file changed, 66 insertions(+), 98 deletions(-)

diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index fd8eff6..02b85c1 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -56,9 +56,8 @@
 #define ACPI_BUTTON_DEVICE_NAME_LID"Lid Switch"
 #define ACPI_BUTTON_TYPE_LID   0x05
 
-#define ACPI_BUTTON_LID_INIT_IGNORE0x00
+#define ACPI_BUTTON_LID_INIT_METHOD0x00
 #define ACPI_BUTTON_LID_INIT_OPEN  0x01
-#define ACPI_BUTTON_LID_INIT_METHOD0x02
 
 #define _COMPONENT ACPI_BUTTON_COMPONENT
 ACPI_MODULE_NAME("button");
@@ -109,23 +108,20 @@ struct acpi_button {
struct timer_list lid_timer;
char phys[32];  /* for input device */
unsigned long pushed;
-   int last_state;
-   ktime_t last_time;
bool suspended;
 };
 
+static DEFINE_MUTEX(lid_device_lock);
 static BLOCKING_NOTIFIER_HEAD(acpi_lid_notifier);
 static struct acpi_device *lid_device;
 static u8 lid_init_state = ACPI_BUTTON_LID_INIT_METHOD;
 
-static unsigned long lid_report_interval __read_mostly = 500;
-module_param(lid_report_interval, ulong, 0644);
-MODULE_PARM_DESC(lid_report_interval, "Interval (ms) between lid key events");
-
 static unsigned long lid_update_interval __read_mostly = 10 * MSEC_PER_SEC;
 module_param(lid_update_interval, ulong, 0644);
 MODULE_PARM_DESC(lid_update_interval, "Interval (ms) between lid state 
updates");
 
+static bool lid_unreliable __read_mostly = false;
+
 /* --
   FS Interface (/proc)
-- 
*/
@@ -149,79 +145,12 @@ static int acpi_lid_notify_state(struct acpi_device 
*device, int state)
 {
struct acpi_button *button = acpi_driver_data(device);
int ret;
-   ktime_t next_report;
-   bool do_update;
-
-   /*
-* In lid_init_state=ignore mode, if user opens/closes lid
-* frequently with "open" missing, and "last_time" is also updated
-* frequently, "close" cannot be delivered to the userspace.
-* So "last_time" is only updated after a timeout or an actual
-* switch.
-*/
-   if (lid_init_state != ACPI_BUTTON_LID_INIT_IGNORE ||
-   button->last_state != !!state)
-   do_update = true;
-   else
-   do_update = false;
-
-   next_report = ktime_add(button->last_time,
-   ms_to_ktime(lid_report_interval));
-   if (button->last_state == !!state &&
-   ktime_after(ktime_get(), next_report)) {
-   /* Complain the buggy firmware */
-   pr_warn_once("The lid device is not compliant to SW_LID.\n");
 
-   /*
-* Send the unreliable complement switch event:
-*
-* On most platforms, the lid device is reliable. However
-* there are exceptions:
-* 1. Platforms returning initial lid state as "close" by
-*default after booting/resuming:
-* https://bugzilla.kernel.org/show_bug.cgi?id=89211
-* https://bugzilla.kernel.org/show_bug.cgi?id=106151
-* 2. Platforms never reporting "open" events:
-* https://bugzilla.kernel.org/show_bug.cgi?id=106941
-* On these buggy platforms, the usage model of the ACPI
-* lid device actually is:
-* 1. The initial returning value of _LID may not be
-*reliable.
-* 2. The open event may not be reliable.
-* 3. The close event is reliable.
-*
-* But SW_LID is typed as input switch event, the input
-* layer checks if the event is redundant. Hence if the
-* state is not switched, the userspace cannot see this
-

Re: [systemd-devel] Systemd license vs. libcryptsetup license

2017-06-07 Thread Lennart Poettering 
On Wed, 07.06.17 09:49, Krzysztof Jackiewicz (k.jackiew...@samsung.com) wrote:

> I guess the "conflict" was not the best word to describe it. 
> 
> If I want to release a product with systemd the libryptsetup option will
> force me to release it under GPL. Is that correct?

Not sure what "release product under GPL" is supposed to mean. Note
that the libcryptsetup dep is optional anyway, and only used by the
systemd-cryptsetup helper, not PID 1 itself.

Unless you link your own more restrictive code into systemd-cryptsetup
the GPL dep that is libcryptsetup should not affect you in any way. At
least not more than the Linux kernel's own GPL license does. I mean,
systemd doesn't support any other kernels anyway...

IANAL, so better ask a lawyer if you want definitive answers. But
whether something is GPL or not only matters whether your program
links to to it or not, and systemd only does so in one of its
processes (and not in PID 1), but even if it did link in PID 1 to
libcryptsetup it wouldn't matter, as long as you don't insert your own
non-free stuff into PID 1 too...

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] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

2017-06-07 Thread Lennart Poettering 
On Tue, 06.06.17 21:57, Michael Biebl (mbi...@gmail.com) wrote:

> 2017-06-06 20:07 GMT+02:00 Steve Dickson :
> > Finally, the whole idea of systemd randomly/silently
> > strip off mount options is crazy... IMHO...
> 
> Personally, I would prefer if systemd simply logged a warning/error
> message but would *not* strip the bg option.

What good does that do if "bg" doesn't actually work properly?

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] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

2017-06-07 Thread Lennart Poettering 
On Tue, 06.06.17 14:07, Steve Dickson (ste...@redhat.com) wrote:

> Hello,
> 
> On 05/29/2017 06:19 PM, NeilBrown wrote:
> > 
> > Systemd does not, and will not, support "bg" correctly.
> > It has other, better, ways to handle "background" mounting.
> The only problem with this is bg mounts still work at least
> up to 4.11 kernel... 
> 
> It appears there is a problem with a 4.12 kernel. The mount no 
> longer errors out with ECONNREFUSED it just hangs in the 
> kernel trying forever... It sounds like a bug to me but 
> maybe that change was intentional.. Anna?? Trond???
> 
> So I'm a bit hesitant to commit this since not accurate, yet.
> 
> Finally, the whole idea of systemd randomly/silently 
> strip off mount options is crazy... IMHO... 
> 
> Just because a concept that has been around for years
> does not fix well in the systemd world it gets
> rip out??? IDK... but I think we can do better than that.

Well "bg" doesn't really work on systemd systems, and this was never
different, hence I think it's only fair to document that it is
incompatible with systemd. In addition, I have the suspicion it is not
used very widely, since I never actually got complaints about it.

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] Systemd license vs. libcryptsetup license

2017-06-07 Thread Krzysztof Jackiewicz 
I guess the "conflict" was not the best word to describe it. 

If I want to release a product with systemd the libryptsetup option will
force me to release it under GPL. Is that correct?

Thanks,

Krzy

-Original Message-
From: Zbigniew Jędrzejewski-Szmek [mailto:zbys...@in.waw.pl] 
Sent: Tuesday, June 06, 2017 5:00 PM
To: Krzysztof Jackiewicz
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] Systemd license vs. libcryptsetup license

On Tue, Jun 06, 2017 at 04:33:11PM +0200, Krzysztof Jackiewicz wrote:
> Hi,
> 
> I noticed that when systemd is configured with libcryptsetup option 
> enabled it will link to libcryptsetup which is distributed under GPL 
> 2.0. It seems like a license conflict to me. Can anyone explain it?

A license conflict appears when two pieces of software are combined and the
licenses have incompatible terms, so they cannot be both satisfied at the
same time. Systemd is LGPL which is compatible with GPL and pretty much
anything else. Also, we don't distribute the combined product, which is the
only thing LGPL and GPL put any conditions on.

Zbyszek


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

Re: [systemd-devel] Why does nspawn need two child processes?

2017-06-07 Thread Lennart Poettering 
On Wed, 31.05.17 20:40, Luke Shumaker (luke...@lukeshu.com) wrote:

> 
> So my question becomes: what has to be done *after* unsharing the
> mount namespace, but *before* unsharing the PID namespace?

The various types of namespaces are not orthogonal even if they are
exposed in supposedly independent bits in the clone() flags parameter:
if a new namespace (in particular a file system namespace CLONE_NEWNS
and a PID namespace CLONE_NEWPID) is created at the same time as a
CLONE_USER user namespace, then those namespaces will be "owned" by
the user namespace. That has various effects, in particular on who may
mount/umount mount points in that namespace and on what is exposed in
/proc. There are some mounts we never want the host to see, but which
also shall not be able to be modified by the container itself, for
example the container's root directory (which is mounted to a
temporary subdirectory of /tmp), hence we do it in a new file system
namespace that is not the host's, but also not the container's but
inherited into it: i.e. between the two CLONE_NEWNS.

I hope that makes sense?

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] Systemd license vs. libcryptsetup license

2017-06-07 Thread Lennart Poettering 
On Tue, 06.06.17 16:33, Krzysztof Jackiewicz (k.jackiew...@samsung.com) wrote:

> Hi,
> 
> I noticed that when systemd is configured with libcryptsetup option enabled
> it will link to libcryptsetup which is distributed under GPL 2.0. It seems
> like a license conflict to me. Can anyone explain it?

systemd is licensed under LGPL2.1+ in its entirety (well, there are
some specific exceptions for very specific files for historic reasons
or because they originate elsewhere) so that we can liberally move
things around within our own tree. During runtime we might link to
more restrictively licensed libraries wich will effectively downgrade
the relevant bits of our code to that more restrictive license too
(which LGPL permits). Or in other words: GPL and LGPL are of course
compatible, and that's what we mix in some of our processes and is
hence fine. Of course, if we end up mixing two libraries in the same
process with conflicting licenses we need to be careful, but GPL+LGPL
are not that.

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] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

2017-06-07 Thread Lennart Poettering 
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.

> 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!

Thanks for working on this,

Lennart

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