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
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debia
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,
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
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
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 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.
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
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: 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.
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: 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
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
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.
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
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
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
Processing control commands:
> tag -1 pending
Bug #761909 [systemd] systemd does not unmount nfs shares before bringing down
the network interface
Added tag(s) pending.
--
761909: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761909
Debian Bug Tracking System
Contact ow...@bugs.debian.org wi
Processing control commands:
> reopen -1
Bug #761909 {Done: Martin Pitt } [systemd] systemd does not
unmount nfs shares before bringing down the network interface
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-ad
Processing control commands:
> tag -1 upstream
Bug #761909 [systemd] systemd does not unmount nfs shares before bringing down
the network interface
Added tag(s) upstream.
--
761909: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761909
Debian Bug Tracking System
Contact ow...@bugs.debian.org
Processing control commands:
> forwarded -1 https://github.com/systemd/systemd/issues/2189
Bug #761909 [systemd] systemd does not unmount nfs shares before bringing down
the network interface
Set Bug forwarded-to-address to
'https://github.com/systemd/systemd/issues/2189'.
--
761909: http://bu
Processing control commands:
> reassign -1 ifupdown 0.8.5
Bug #761909 [systemd] systemd does not unmount nfs shares before bringing down
the network interface
Bug reassigned from package 'systemd' to 'ifupdown'.
No longer marked as found in versions systemd/228-2 and systemd/215-4.
Ignoring reque
21 matches
Mail list logo
