Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #763507 > unrolled thread

Bug#836135: umountiscsi.sh indiscriminately umounts all LVM based filesystems when no iSCSI sessions are found.

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#836135: umountiscsi.sh indiscriminately umounts all LVM based filesystems when no iSCSI sessions are found. Frank Fegert <fra.nospam.nk@gmx.de> - 2016-08-30 22:10 +0200
    Bug#836135: umountiscsi.sh indiscriminately umounts all LVM based filesystems when no iSCSI sessions are found. Christian Seiler <christian@iwakd.de> - 2016-08-30 22:30 +0200
      Bug#836135: umountiscsi.sh indiscriminately umounts all LVM based filesystems when no iSCSI sessions are found. Frank Fegert <fra.nospam.nk@gmx.de> - 2016-08-31 23:00 +0200
        Bug#836135: umountiscsi.sh indiscriminately umounts all LVM based filesystems when no iSCSI sessions are found. Christian Seiler <christian@iwakd.de> - 2016-08-31 23:30 +0200
          Bug#836135: umountiscsi.sh indiscriminately umounts all LVM based filesystems when no iSCSI sessions are found. Frank Fegert <fra.nospam.nk@gmx.de> - 2016-09-09 19:20 +0200
            Bug#836135: umountiscsi.sh indiscriminately umounts all LVM based filesystems when no iSCSI sessions are found. Christian Seiler <christian@iwakd.de> - 2016-09-09 19:30 +0200
              Bug#836135: umountiscsi.sh indiscriminately umounts all LVM based filesystems when no iSCSI sessions are found. Frank Fegert <fra.nospam.nk@gmx.de> - 2016-09-09 21:10 +0200

#763507 — Bug#836135: umountiscsi.sh indiscriminately umounts all LVM based filesystems when no iSCSI sessions are found.

Package: open-iscsi
Version: 2.0.873+git1.4c1f2d90-2

Dear open-iscsi maintainers,

probably just an odd corner case, but it seems that umountiscsi.sh
indiscriminately tries to umount *all* LVM based filesystems - even
those on local disks - when no iSCSI sessions are found by the code
in function "enumerate_iscsi_devices()". I've tried to explain the
experienced issue in greater detail here:
  http://www.bityard.org/blog/2016/08/28/backporting_open-iscsi_debian_jessie

A quick'n'dirty solution which worked for me can be found here:
  https://github.com/frank-fegert/debian_open-iscsi/commit/5118af7fb23ed90281c7a5db3fde0e09bc61b225

Can you please take a look at this and possibly confirm this issue?

Thanks & best regards,

    Frank Fegert

[toc] | [next] | [standalone]

#763508

Control: tags -1 + confirmed
Control: severity -1 important

On 08/30/2016 10:05 PM, Frank Fegert wrote:
> probably just an odd corner case, but it seems that umountiscsi.sh
> indiscriminately tries to umount *all* LVM based filesystems - even
> those on local disks - when no iSCSI sessions are found by the code
> in function "enumerate_iscsi_devices()". I've tried to explain the
> experienced issue in greater detail here:
>   http://www.bityard.org/blog/2016/08/28/backporting_open-iscsi_debian_jessie

Yeah, that's not intended. Thanks for catching this!

> A quick'n'dirty solution which worked for me can be found here:
>   https://github.com/frank-fegert/debian_open-iscsi/commit/5118af7fb23ed90281c7a5db3fde0e09bc61b225
> 
> Can you please take a look at this and possibly confirm this issue?

While not having tested this, from just looking at the code with
your explanation in mind, yes, you're right about that.

Your fix is also correct, but I'm not sure I like the endless
list of -o -n repeats... I'll think about it for a while and if
I can't find a better solution, I'll commit your fix to git.
(And if I find a better solution, I'll commit that. ;-)) I'll
let the current version migrate to testing first before another
upload though, because I want to get iscsiuio into testing first.

Speaking of: you appear to be interested in a backport of
open-iscsi into Jessie because you want to use offloading via
iscsiuio. I've been thinking about uploading open-isns and
open-iscsi to jessie-backports myself (precisely to have iscsiuio
support available for Jessie users), but was unsure whether
there's enough people who'd be interested in that. Would that be
something you'd use yourself? Or would you want to continue to
use your special backported version instead? Since you're
actively using iscsiuio, I'd like to hear your opinion on that
first.

Regards,
Christian

[toc] | [prev] | [next] | [standalone]

#763756

Hello Christian,

On Tue, Aug 30, 2016 at 10:24:22PM +0200, Christian Seiler wrote:
> While not having tested this, from just looking at the code with
> your explanation in mind, yes, you're right about that.

thanks for your confirmation!

> Your fix is also correct, but I'm not sure I like the endless
> list of -o -n repeats... I'll think about it for a while and if
> I can't find a better solution, I'll commit your fix to git.
> (And if I find a better solution, I'll commit that. ;-))

By all means, please do! I'm also not particularly happy with this
temporary fix, but "it did get the job done"[TM] ;-)

> Speaking of: you appear to be interested in a backport of
> open-iscsi into Jessie because you want to use offloading via
> iscsiuio. I've been thinking about uploading open-isns and
> open-iscsi to jessie-backports myself (precisely to have iscsiuio
> support available for Jessie users), but was unsure whether
> there's enough people who'd be interested in that. Would that be
> something you'd use yourself? Or would you want to continue to
> use your special backported version instead? Since you're
> actively using iscsiuio, I'd like to hear your opinion on that
> first.

No, i'd definitely prefer an "official" backported version of the
package, provided it's based on reasonably recent open-iscsi upstream
sources - there are several important fixes as of late not covered by
the current Jessie package sources. I particularly like your idea of
putting iscsiuio into its own package.
What's a real pain though, is the whole hassle with "_netdev", "LVM-
GROUPS", and still having to tweak the multipath init script. Well,
that's at least what i ended up with to get the order of things at
boot time at least almost right :-( Compared to the straightforward
use of targets through full iSOEs like e.g. the QME8262 cards, this
just feels awkward. Maybe it's just me doing something terribly wrong
;-)

Thanks & best regards,

    Frank

[toc] | [prev] | [next] | [standalone]

#763762

Hello Frank,

On 08/31/2016 10:46 PM, Frank Fegert wrote:
> On Tue, Aug 30, 2016 at 10:24:22PM +0200, Christian Seiler wrote:
>> Your fix is also correct, but I'm not sure I like the endless
>> list of -o -n repeats... I'll think about it for a while and if
>> I can't find a better solution, I'll commit your fix to git.
>> (And if I find a better solution, I'll commit that. ;-))
> 
> By all means, please do! I'm also not particularly happy with this
> temporary fix, but "it did get the job done"[TM] ;-)

I haven't had time to test it yet (might even still have shell
syntax errors), but I've come up with the following:

get_lvm_vgs() {
        # handle the case where we didn't get passed any PVs
        # at all
        [ $# -gt 0 ] || return
        # subshell for pwd change
        (
                cd /dev
                $PVS --noheadings -o vg_name "$@" 2>/dev/null
        )
}

and later:

for _vg in $(get_lvm_vgs $iscsi_disks $iscsi_partitions $iscsi_multipath_disks $iscsi_multipath_partitions) $LVMGROUPS ; do

Will do some tests in the next couple of days and upload a
fixed version.

>> Speaking of: you appear to be interested in a backport of
>> open-iscsi into Jessie because you want to use offloading via
>> iscsiuio. I've been thinking about uploading open-isns and
>> open-iscsi to jessie-backports myself (precisely to have iscsiuio
>> support available for Jessie users), but was unsure whether
>> there's enough people who'd be interested in that. Would that be
>> something you'd use yourself? Or would you want to continue to
>> use your special backported version instead? Since you're
>> actively using iscsiuio, I'd like to hear your opinion on that
>> first.
> 
> No, i'd definitely prefer an "official" backported version of the
> package, provided it's based on reasonably recent open-iscsi upstream
> sources - there are several important fixes as of late not covered by
> the current Jessie package sources.

Ok, then I'll see to that. I'll have to talk to Ritesh (the other
co-maintainer of open-iscsi) first, and probably want to clarify
something with the backports ftp-masters, so it might take a couple
of weeks until it's in, but if you want, I can notify you via email
once I've created the corresponding packages, even if they are
stuck in the NEW queue for a while.

As for "recent-ness" of backports: the rules for jessie-backports
are that Stretch has to be tracked. Since open-iscsi with iscsiuio
will migrate to Stretch tomorrow (barring a last-minute RC bug),
that's going to be the lowest possible version that's going to
land in backports. And until Stretch is released, jessie-backports
would get all further improvements. (Though to be honest, I don't
see that many major changes happening until Stretch; iscsiuio and
the earlier rework of the startup logic were the big ones on my
list, and those are done.)

> I particularly like your idea of
> putting iscsiuio into its own package.

Yes. While it isn't harmful, I don't think having the daemon
started on every system, even those without bnx2 cards, is a
sensible default. ;-)

> What's a real pain though, is the whole hassle with "_netdev", "LVM-
> GROUPS",

So _netdev will need to stay, I don't see how to improve that. I do
want to get rid of LVMGROUPS in the long term (because I think that
is a layering violation), so in Stretch we'll recommend to use
lvmetad for activating LVM volumes (while still supporting the old
way until after the Stretch release). Doesn't help you for Jessie
though, because lvmetad is broken there. (And as far as I understood
it, the fix is too complicated to be pushed via a stable update.)

> and still having to tweak the multipath init script.

Could you be more specific here? What exactly do you need to do?
I still have an item on my TODO list to take a look at multipath
vs. iSCSI in Jessie (in Stretch it works), because there was a
bug report on debian-user about it - I just didn't manage to do
so yet. If you are using that and have already looked into it,
it would be great, then I could probably try to also get that
sorted. (No guarantees for 8.6 though, because that'll happen on
Sep. 17th, so the time window is a bit short there.)

> Compared to the straightforward
> use of targets through full iSOEs like e.g. the QME8262 cards, this
> just feels awkward. Maybe it's just me doing something terribly wrong
> ;-)

If you have specific suggestions for how things could be done
in a simpler manner, even if it's just documentation, then I'm
all ears. I do think it's the job of Debian packaging to provide
a good integration of software. But once you get to know a bit
of software very well, you don't necessarily see all the
usability issues, because you know how to do stuff. So if you
have any suggestions, just tell us.

Regards,
Christian

[toc] | [prev] | [next] | [standalone]

#766028

Hello Christian,

sorry for the delayed reply!

On Wed, Aug 31, 2016 at 11:18:41PM +0200, Christian Seiler wrote:
> I haven't had time to test it yet (might even still have shell
> syntax errors), but I've come up with the following:
> 
> get_lvm_vgs() {
>         # handle the case where we didn't get passed any PVs
>         # at all
>         [ $# -gt 0 ] || return
>         # subshell for pwd change
>         (
>                 cd /dev
>                 $PVS --noheadings -o vg_name "$@" 2>/dev/null
>         )
> }
> 
> and later:
> 
> for _vg in $(get_lvm_vgs $iscsi_disks $iscsi_partitions $iscsi_multipath_disks $iscsi_multipath_partitions) $LVMGROUPS ; do
> 
> Will do some tests in the next couple of days and upload a
> fixed version.

Also not testet, this looks reasonable. 

> Ok, then I'll see to that. I'll have to talk to Ritesh (the other
> co-maintainer of open-iscsi) first, and probably want to clarify
> something with the backports ftp-masters, so it might take a couple
> of weeks until it's in, but if you want, I can notify you via email
> once I've created the corresponding packages, even if they are
> stuck in the NEW queue for a while.

Yes please, that would be great.

> As for "recent-ness" of backports: the rules for jessie-backports
> are that Stretch has to be tracked. Since open-iscsi with iscsiuio
> will migrate to Stretch tomorrow (barring a last-minute RC bug),
> that's going to be the lowest possible version that's going to
> land in backports. And until Stretch is released, jessie-backports
> would get all further improvements. (Though to be honest, I don't
> see that many major changes happening until Stretch; iscsiuio and
> the earlier rework of the startup logic were the big ones on my
> list, and those are done.)

Ok, can i instead ask to please add this upstream commit:
  https://github.com/open-iscsi/open-iscsi/commit/efdd487c70269749f03be8342c4fde8fd3b59f8a

as a patch to the stretch/jessie-backports package? It's a really
annoying bug that may or may not be triggered. For me it triggered
on Intel E5 v4 based systems, but wouldn't show up on Intel E5 v3
based systems :-(
 
> > and still having to tweak the multipath init script.
> 
> Could you be more specific here? What exactly do you need to do?
> I still have an item on my TODO list to take a look at multipath
> vs. iSCSI in Jessie (in Stretch it works), because there was a
> bug report on debian-user about it - I just didn't manage to do
> so yet. If you are using that and have already looked into it,
> it would be great, then I could probably try to also get that
> sorted. (No guarantees for 8.6 though, because that'll happen on
> Sep. 17th, so the time window is a bit short there.)

Sorry, i had a wrong memory of this - probably too many tests and
workarounds that in the end didn't quite work. The issue with multi-
path wasn't with the init script itself, but actually the one de-
scribed here:
  https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1431650
  https://github.com/hreinecke/multipath-tools/commit/841977fc9c3432702c296d6239e4a54291a6007a

Once i added the above patch to a otherwise standard jessie multi-
path package, the issues on boot disappeared. This worked even
with the old version of activate-storage.sh script:
  https://github.com/frank-fegert/debian_open-iscsi/blob/master/debian/extra/activate-storage.sh

Thanks & best regards,

    Frank

[toc] | [prev] | [next] | [standalone]

#766030

On 09/09/2016 07:08 PM, Frank Fegert wrote:
> sorry for the delayed reply!

No worries, I was busy with other stuff anyway.

>> As for "recent-ness" of backports: the rules for jessie-backports
>> are that Stretch has to be tracked. Since open-iscsi with iscsiuio
>> will migrate to Stretch tomorrow (barring a last-minute RC bug),
>> that's going to be the lowest possible version that's going to
>> land in backports. And until Stretch is released, jessie-backports
>> would get all further improvements. (Though to be honest, I don't
>> see that many major changes happening until Stretch; iscsiuio and
>> the earlier rework of the startup logic were the big ones on my
>> list, and those are done.)
> 
> Ok, can i instead ask to please add this upstream commit:
>   https://github.com/open-iscsi/open-iscsi/commit/efdd487c70269749f03be8342c4fde8fd3b59f8a
> 
> as a patch to the stretch/jessie-backports package?

Thanks for the pointer, I'll try to upload a new version to sid
today with that patch + the fix for umountiscsi.sh.

(Also, thanks for having that as an upstream pull request, I wanted
to talk to upstream soon anyway and prod them to officially release
a new version at some point - it's much easier to tell them "we have
commit XYZ in Debian atm, + pull requests A, B and C.")

>>> and still having to tweak the multipath init script.
>>
>> Could you be more specific here? What exactly do you need to do?
>> I still have an item on my TODO list to take a look at multipath
>> vs. iSCSI in Jessie (in Stretch it works), because there was a
>> bug report on debian-user about it - I just didn't manage to do
>> so yet. If you are using that and have already looked into it,
>> it would be great, then I could probably try to also get that
>> sorted. (No guarantees for 8.6 though, because that'll happen on
>> Sep. 17th, so the time window is a bit short there.)
> 
> Sorry, i had a wrong memory of this - probably too many tests and
> workarounds that in the end didn't quite work. The issue with multi-
> path wasn't with the init script itself, but actually the one de-
> scribed here:
>   https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1431650
>   https://github.com/hreinecke/multipath-tools/commit/841977fc9c3432702c296d6239e4a54291a6007a

Thanks for the pointer. Unfortunately, the window for updates for
the next Jessie point release have closed, (well, technically there
are a couple of hours left today, but I'm not the maintainer of
multipath-tools, and while I could work with them to make it happen,
it won't be in time), so this will have to wait for the point release
after that. I'll look into this issue though until then.

Regards,
Christian

[toc] | [prev] | [next] | [standalone]

#766040

Hello Christian,

On Fri, Sep 09, 2016 at 07:21:12PM +0200, Christian Seiler wrote:
> (Also, thanks for having that as an upstream pull request, I wanted
> to talk to upstream soon anyway and prod them to officially release
> a new version at some point - it's much easier to tell them "we have
> commit XYZ in Debian atm, + pull requests A, B and C.")

just FYI, getting back to regular releases was already mentioned a few
times on the mailing list. The latest occasion i can remember was:
  https://groups.google.com/d/msg/open-iscsi/4E3SAp3T3CQ/G76ShAAvBAAJ

Personally, i would also welcome this. So maybe a little nagging from
distribution package maintainers wouldn't hurt ;-)

Thanks & best regards,

    Frank

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web