[systemd-devel] [networkd] Unable to set MTU with .link file

[Ian Pilcher]

I am tearing my hair out trying to figure out why I an unable to set the
MTU of an OVS port with a .link file.

I am trying to create this:

++  ++
||  ||
|  eno1  |  |  eno2  |
|  (MTU = 8996)  |  |  (MTU = 8996)  |
||  ||
+---++  +---++
|   |
+---+---+
|
+---++
||
|  bond0 |
|  (MTU = 8996)  |
||
+---++
|
+---++
||
|  ovs0  |
|  (MTU = 8996)  |
||
+---++
|
+---+---+
|   |
+---++  +---++
||  ||
| vlan248|  | vlan250|
|  (MTU = 8996)  |  |  (MTU = 1500)  |
||  ||
++  ++

Everything works, except that vlan250 is inheriting the jumbo MTU from
ovs0.  I've created a link file to set the MTU to 1500:

/etc/systemd/network/98-vlan250.link:

[Match]
OriginalName=vlan250

[Link]
MTUBytes=1500

For some reason, this isn't working.

I've set udev_log="debug" in /etc/udev/udev.conf and rebuilt my
initramfs.  I've also created a drop-in for systemd-networkd that sets
SYSTEMD_LOG_LEVEL=debug.

A full boot log with these settings can be found at:

  http://www.penurio.us/journal.txt

Any ideas or debugging techniques very much appreciated.

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
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

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jun 08, 2017 at 10:00:03PM +0300, Uoti Urpala wrote:
> On Thu, 2017-06-08 at 17:14 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Jun 08, 2017 at 06:03:37PM +0200, Julian Andres Klode wrote:
> > > I'm not sure where you get that from. The usual interpretation is that
> > > linking to a GPLed library means the linked work must be GPL as well.
> > 
> > I don't think that's true. It only must have a compatible license.
> 
> I think that is the default FSF position. There are at least some cases
> where it's likely not automatic (for example, if there's a widespread
> API/ABI that is provided by both GPLed and differently-licensed
> libraries, an executable that works with both seems to have at least a
> reasonable claim to not being a derivative work). However, assuming
> that using a library may make the executable a derivative work seems to
> be the only safe default assumption.

Yes, FSF seems to be saying that, but I don't think this makes sense.
The copyright is about protecting the creative part of a given work,
and just using the API does not incorporate or copy the creative
process used to create the library.

> If the only thing you know is that some code uses the library, that may
> mean things like nontrivial inline functions being included in the
> compiled code, or copy relocations copying arbitrary amounts of data
> into an executable. It seems pretty clear that this can be considered a
> derived work. So I don't think you can ever claim that GPL wouldn't
> cover the linked work without at least some analysis of the specific
> library in question and how it's used in the program.
(I'm ignoring copy relocations which happen at runtime.)
You are right that a program compiled against a "header library" would
be most likely be a derivative work. But still, this is a special
case. I'm not claiming that GPL wouldn't apply ever, but that it
doesn't in the common case of a program calling a few functions from a
separately distributed library.

Zbyszek

P.S. I think there's a lot of politicking on the FSF website, which
undermines their credibility:
"GNU/Linux is used by millions, though many call it “Linux” by mistake."
"We recommend installable versions of GNU (more precisely, GNU/Linux 
distributions)"
Seriously.
___
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.

[NeilBrown]

On Thu, Jun 08 2017, J. Bruce Fields wrote:

> On Thu, Jun 08, 2017 at 03:16:52PM +1000, NeilBrown wrote:
>> So I think I've found a solution for systemd to handle "bg" nfs mounts
>> correctly.   I'll submit some pull requests for consideration.
>
> Out of curiosity, after that change is there still any reason you'd
> recommend any new user actually use "bg" (as opposed to an automount)?

Me? Recommend?  Who would listen?  Who would even hear?
For the last few years I've been recommending that automount should
be used for *all* NFS mounts at every opportunity.  I think I've had two
opportunities.

But no, I would not recommend "bg".  I would recommend automount and
then when they reported problems,  I would help fix them.

I would be much happier recommending automount if it were easier.
Setting up /etc/auto.direct with automountd is fairly easy, but you need
to actually enable it but modifying auto.master or auto.master.d, which
is slightly annoying.

systemd does make it easier to do direct mounts, but it is ugly.
You need to include "comment=systemd.automount" or "x-systemd.automount"
in /etc/fstab instead of just "automount" or "ondemand".  I understand
exactly why they did that and I cannot fault the logic.  But it still
looks clumsy.

With systemd, you cannot divorce the timeout that an application has to
wait when accessing the mountpoint while the server is down, from the
timeout imposed on the mount program.  i.e., mount cannot keep trying
in the background. - that could be useful if you want really-short
timeouts... at least it seems to me that they should be separate.

The timeout is configured differently if mounting from a device, or
mounting from anything else such as NFS.  The first uses
x-systemd.device-timeout.  The other needs x-systemd.mount-timeout.


But I'm ranting... I should probably shut up and send patches.
A generator for /etc/fstab.auto??

>
> I appreciate the effort to keep existing systems working, I'm just
> curious.

Compatibility with existing practice is certainly the main driver.

Thanks,
NeilBrown


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

[systemd-devel] [networkd] Unable to set MTU with .link file

[Ian Pilcher]

I am tearing my hair out trying to figure out why I an unable to set the
MTU of an OVS port with a .link file.

I am trying to create this:

++  ++
||  ||
|  eno1  |  |  eno2  |
|  (MTU = 8996)  |  |  (MTU = 8996)  |
||  ||
+---++  +---++
|   |
+---+---+
|
+---++
||
|  bond0 |
|  (MTU = 8996)  |
||
+---++
|
+---++
||
|  ovs0  |
|  (MTU = 8996)  |
||
+---++
|
+---+---+
|   |
+---++  +---++
||  ||
| vlan248|  | vlan250|
|  (MTU = 8996)  |  |  (MTU = 1500)  |
||  ||
++  ++

Everything works, except that vlan250 is inheriting the jumbo MTU from
ovs0.  I've created a link file to set the MTU to 1500:

/etc/systemd/network/98-vlan250.link:

[Match]
OriginalName=vlan250

[Link]
MTUBytes=1500

For some reason, this isn't working.

I've set udev_log="debug" in /etc/udev/udev.conf and rebuilt my
initramfs.  I've also created a drop-in for systemd-networkd that sets
SYSTEMD_LOG_LEVEL=debug.

A full boot log with these settings can be found at:

  http://www.penurio.us/journal.txt

Any ideas or debugging techniques very much appreciated.

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


___
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.

[Steve Dickson]

On 06/07/2017 12:08 PM, J. Bruce Fields wrote:
> On Wed, Jun 07, 2017 at 06:04:12AM -0400, Steve Dickson wrote:
>> # ps ax | grep mount
>>   980 ?Ss 0:00 /sbin/mount.nfs nfssrv:/home/tmp /mnt/tmp -o rw,bg
> 
> Right, but I think we also need to see a "systemctl status
> remote-fs.target", or something, to verify whether that's the forked
> background process or just the foreground process that's still hanging
> up some part of the boot process (even though it's gotten far enough
> along that you can log in--unless logins aren't permitted till remote
> fs's are mounted, I don't know.)
It succeeds... 

# 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 systemd[1]: Reached target Remote File Systems.

The reason being, as Neil pointed out, the mount.nfs gets the 
ECONNREFUSED right away because the server is down. So a
child is quickly forked that continues to try the mount... 
Basically sneaking around systemd back... Which is hard
to do... these day 8-)  

steved.
___
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.

[Steve Dickson]

On 06/08/2017 01:16 AM, NeilBrown wrote:
> 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.
I'm seeing this now... the server has to be up to cause this hang.

> 
> 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).
No... Systemd is doing the right thing in this case... Letting
bg mounts work... 

> 
> If you try 

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

[Uoti Urpala]

On Thu, 2017-06-08 at 17:14 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Jun 08, 2017 at 06:03:37PM +0200, Julian Andres Klode wrote:
> > I'm not sure where you get that from. The usual interpretation is that
> > linking to a GPLed library means the linked work must be GPL as well.
> 
> I don't think that's true. It only must have a compatible license.

I think that is the default FSF position. There are at least some cases
where it's likely not automatic (for example, if there's a widespread
API/ABI that is provided by both GPLed and differently-licensed
libraries, an executable that works with both seems to have at least a
reasonable claim to not being a derivative work). However, assuming
that using a library may make the executable a derivative work seems to
be the only safe default assumption.

If the only thing you know is that some code uses the library, that may
mean things like nontrivial inline functions being included in the
compiled code, or copy relocations copying arbitrary amounts of data
into an executable. It seems pretty clear that this can be considered a
derived work. So I don't think you can ever claim that GPL wouldn't
cover the linked work without at least some analysis of the specific
library in question and how it's used in the program.

___
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

[Uoti Urpala]

On Thu, 2017-06-08 at 22:00 +0300, Uoti Urpala wrote:
> compiled code, or copy relocations copying arbitrary amounts of data
> into an executable. It seems pretty clear that this can be considered a

Rereading that, copy relocations are actually not that good an example
since the copying normally happens at runtime. So better consider just
inline functions.

___
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

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jun 08, 2017 at 06:03:37PM +0200, Julian Andres Klode wrote:
> On Thu, Jun 08, 2017 at 01:47:56PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Thu, Jun 08, 2017 at 09:40:17AM +0200, Krzysztof Jackiewicz wrote:
> > > > 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.
> > > 
> > > Then how would you interpret the following statements:
> > > https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic
> > > https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
> > > https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
> > 
> > I interpret them as FSF wanting to drum up the importance of GPL a bit
> > by purposefully not clarifying this area. The case of linking non-GPL
> > software with GPL libraries is quite common and important,
> 
> I'm not sure where you get that from. The usual interpretation is that
> linking to a GPLed library means the linked work must be GPL as well.
I don't think that's true. It only must have a compatible license.

(For example, pure proprietary code would not be allowed to link with
a GPL library because of the restrictions of the proprietary license,
the GPL side would be OK with that, as long as the resulting whole
is not distributed.)

> That's
> why the LGPL exists in the first place: It allows linking to from 
> GPL-incompatible
> works (as long as the LGPLed component can be replaced, either by dynamic
> linking or by providing object files for relinking).
Yes, that's the original reason, but there can be different motivations.
After all, the strength of both GPL and LGPL is that they describe their
requirements in high level terms, without mentioning specific technical
details, which makes both licenses so versatile and long-lived.

> And of course, that's the whole reason for the GPL linking exception
> used by classpath which explicitly starts with:
> 
> "Linking this library statically or dynamically with other modules is
>  making a combined work based on this library. Thus, the terms and
>  conditions of the GNU General Public License cover the whole combination."
> 
> Before specifying the exception.

LGPL says "A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a work,
in isolation, is not a derivative work of the Library, [...]". 

(Whether something is a derivative work is question of human
creativity, and the license that is later attached only matters for
whether the creation can be legally distributed, and not for the fact
of being a derivate or not. This definition applies generally, and
matches how I understand the mere fact of using a few bits from a
public interface.)

> > > IMHO it's not so obvious and it may depend on a specific
> > > case. Perhaps in case of runtime dynamic linking when GPL library
> > > existence is not required for the application to run it will be
> > > treated as a mere aggregation. With all due respect I think that to
> > > solve it we'd need a lawyer indeed :)
> > 
> > Well, will all respect due to (a) lawyer, to solve it once and for
> > all, we'd probably need a body of binding court decisions in multiple
> > jurisdictions ;)
> > 
> > In the GPL there's very little about what derived means. Various
> > interpretations in the FSF FAQ are post-factum, and not part of the
> > license. I'm pretty sure that the interpretation that independent
> > works distributed as parts of a distro are still independent is in
> > agreement with both the spirit and the letter of the GPL.
> > In Galoob v. Nintendo, in appeal, it was ruled that the derivative
> > work "must incorporate a portion of the copyrighted work in some form",
> > which does not happen when you just put two rpms side by side.
> 
> In the Oracle vs Google appeal, it was determined that APIs are
> copyrightable (mostly), hence any use of a GPLed API would create a
> GPLed derivate work.

I don't think the decision in that case made much sense to most
programmers. But even if we accept Oracle v. Google as given,
there is a big difference between recreating the whole thing to
fulfill an API, and narrow use of a very small portion of an API.
I don't think Oracle v. Google has much bearing on the question
in this thread, and certainly you can't generalize it to *any*
use of an API.

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

[Krzysztof Jackiewicz]

> I interpret them as FSF wanting to drum up the importance of GPL a bit by
> purposefully not clarifying this area. The case of linking non-GPL
software with
> GPL libraries is quite common and important, and if they wanted to add an
entry
> to the FAQ, they certainly would. They talk a lot about "plugins", but
that's a
> significantly different case, because a plugin is very closely tied to the
program
> that loads it.

> In the GPL there's very little about what derived means. Various
interpretations
> in the FSF FAQ are post-factum, and not part of the license. I'm pretty
sure that
> the interpretation that independent works distributed as parts of a distro
are
> still independent is in agreement with both the spirit and the letter of
the GPL.
> In Galoob v. Nintendo, in appeal, it was ruled that the derivative work
"must
> incorporate a portion of the copyrighted work in some form", which does
not
> happen when you just put two rpms side by side.

That's an interesting point of view. I have no further questions :)

Thanks,

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

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jun 08, 2017 at 09:40:17AM +0200, Krzysztof Jackiewicz wrote:
> > 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.
> 
> Then how would you interpret the following statements:
> https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic
> https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
> https://www.gnu.org/licenses/gpl-faq.html#MereAggregation

I interpret them as FSF wanting to drum up the importance of GPL a bit
by purposefully not clarifying this area. The case of linking non-GPL
software with GPL libraries is quite common and important, and if they
wanted to add an entry to the FAQ, they certainly would. They talk a lot
about "plugins", but that's a significantly different case, because a
plugin is very closely tied to the program that loads it.

> IMHO it's not so obvious and it may depend on a specific
> case. Perhaps in case of runtime dynamic linking when GPL library
> existence is not required for the application to run it will be
> treated as a mere aggregation. With all due respect I think that to
> solve it we'd need a lawyer indeed :)

Well, will all respect due to (a) lawyer, to solve it once and for
all, we'd probably need a body of binding court decisions in multiple
jurisdictions ;)

In the GPL there's very little about what derived means. Various
interpretations in the FSF FAQ are post-factum, and not part of the
license. I'm pretty sure that the interpretation that independent
works distributed as parts of a distro are still independent is in
agreement with both the spirit and the letter of the GPL.
In Galoob v. Nintendo, in appeal, it was ruled that the derivative
work "must incorporate a portion of the copyrighted work in some form",
which does not happen when you just put two rpms side by side.

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

[Krzysztof Jackiewicz]

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

Yeah, it seems so :) Initially I thought that the answer is more obvious.


___
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

[Krzysztof Jackiewicz]

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

Then how would you interpret the following statements:
https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic
https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
https://www.gnu.org/licenses/gpl-faq.html#MereAggregation

IMHO it's not so obvious and it may depend on a specific case. Perhaps in case 
of runtime dynamic linking when GPL library existence is not required for the 
application to run it will be treated as a mere aggregation. With all due 
respect I think that to solve it we'd need a lawyer indeed :)

Krzy

___
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.

[Mantas Mikulėnas]

On Thu, Jun 8, 2017 at 8:16 AM, NeilBrown  wrote:

> 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).
>

Cleaning up background processes for successful mounts would break every
FUSE filesystem.

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