Control: reassign -1 ifupdown 0.8.5
Control: tag -1 patch
Martin Pitt [2016-01-03 16:02 +0100]:
> Michael Biebl [2015-12-18 14:55 +0100]: > Am 18.12.2015 um 11:12 schrieb
> Martin Pitt:
> > I agree that this sounds like an upstream bug. If there is not explicit
> > Conflicts=shutdown.target, I do
Michael Biebl [2015-12-18 14:55 +0100]: > Am 18.12.2015 um 11:12 schrieb Martin
Pitt:
> I agree that this sounds like an upstream bug. If there is not explicit
> Conflicts=shutdown.target, I don't see why the instance should be
> stopped. That would be very inconsistent and unexpected behaviour.
Am 18.12.2015 um 11:12 schrieb Martin Pitt:
> If this was really deliberate and we can't prevent instantiated units
> from getting stopped during shutdown, then I propose as a fallback we
> just drop the ExecStop=ifdown (or replace it with some "echo not
> supported blabla, please use ifdown direct
Control: forwarded -1 https://github.com/systemd/systemd/issues/2189
I now bisected this and understand what's going on. Further details
are in the upstream issue.
If this was really deliberate and we can't prevent instantiated units
from getting stopped during shutdown, then I propose as a fallb
Control: tag -1 upstream
Martin Pitt [2015-12-18 9:06 +0100]:
> Apparently 228 (or perhaps 227) changed behaviour so that
> ifup@.service always gets stopped, even if they have
> DefaultDependencies=no and thus no Conflicts=shutdown.target.
This applies to any instantiated unit apparenlty. Easil
Control: reopen -1
Control: found -1 228-2
This bug is back in 228-2, ifup@.service now again gets stopped during
shutdown.
Apparently 228 (or perhaps 227) changed behaviour so that
ifup@.service always gets stopped, even if they have
DefaultDependencies=no and thus no Conflicts=shutdown.target.
Hello
On Mon, Oct 5, 2015 at 11:15 AM, Martin Pitt wrote:
>> However, when the network is brought down (manually, or automatically
>> during system shutdown), the mountpoint is not unmounted, causing a
>> number of issues.
>
> This sounds very similar to https://launchpad.net/bugs/1492546 .
> ifu
Control: tag -1 pending
Hello Michael,
Michael Biebl [2015-10-05 12:11 +0200]:
> Originally I designed it that way: no Conflicts=shutdown.target and
> letting networking.service do the clean up on shutdown.
>
> ifup@.service was changed in the mean time. I wonder if the
> PartOf=network.target b
Am 05.10.2015 um 11:15 schrieb Martin Pitt:
> Or we just declare that we don't support manual stops, and you are
> supposed to run "sudo ifdown ethX" to stop an interface. This is also
> reasonable as we consider ifup@.service more like an internal helper
> unit, not an user-visible/actionable one.
Michael Biebl [2015-10-05 12:11 +0200]:
> Can someone check if ifup@.service units are stopped on shutdown?
I already did this morning before I wrote that reply, they do get
stopped. I added an "echo XXX; systemctl is-system-running" to
ExecStop=, and I see these on shutdown.
Martin
--
Martin Pi
Am 05.10.2015 um 12:07 schrieb Michael Biebl:
> The ifup@.service unit file has DefaultDependencies=no and *no*
> Conflicts=shutdown.target, which means it should *not* be stopped on
> shutdown. This was done this way for exactly the reason you mention.
Originally I designed it that way: no Confli
Am 05.10.2015 um 11:15 schrieb Martin Pitt:
> Hello,
>
> Giuseppe Bilotta [2014-09-16 20:15 +0200]:
>> My fstab includes the line
>>
>> labrador:/oneforall /oneforall nfs auto,exec 0 0
>>
>> and the nfs share is automatically mounted when a network interface that
>> can resol
Hello,
Giuseppe Bilotta [2014-09-16 20:15 +0200]:
> My fstab includes the line
>
> labrador:/oneforall /oneforallnfs auto,exec 0 0
>
> and the nfs share is automatically mounted when a network interface that
> can resolve `labrador` is brought up. I don't use NM nor wicd,
Dear Maintainer,
i am running jessie and I have exactly the same bug as described in post #25. My system is connected to the net by wlan (NM).
Regards,
Jürgen
On Tue, Sep 16, 2014 at 9:06 PM, Michael Biebl wrote:
> Am 16.09.2014 um 20:15 schrieb Giuseppe Bilotta:
>> Most significantly, if I shutdown the system after bringing up the
>> network, the shutdown process will hang while waiting for the
>> un-mounting of /oneforall, which cannot happen because
Am 16.09.2014 um 20:15 schrieb Giuseppe Bilotta:
> Package: systemd
> Version: 215-4
> Severity: normal
>
>
> My fstab includes the line
>
> labrador:/oneforall /oneforallnfs auto,exec 0 0
>
> and the nfs share is automatically mounted when a network interface that
> can
16 matches
Mail list logo