Iscsi and un responsiveness at shutdown

My YunoHost server

Hardware: rack server i7 with 10G RAM allocated to yunohost vm and 4vCore
YunoHost version: 4.1.8
I have access to my server : Through SSH | through the webmin or VNC of the vm
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : yes

    • The VM is linked to several iscsi devices located on another VM truenas which has several zvol allocated to this yunohost VM.
    • the first one is for the nextcloud data
    • The second one is for the yunohost backup
    • the third one is for the multimedia rep
    • I’ve included several binds also in the fstab for that purpose:
/media/back/yunohost.backup     /home/yunohost.backup   none    defaults,bind   0   0
/media/media_share/yunohost.multimedia  /home/yunohost.multimedia       none    defaults,bind   0   0
/media/media_share/funkwhale  /home/yunohost.app/funkwhale      none    defaults,bind   0   0
/media/media_share/peertube   /home/yunohost.app/peertube       none    defaults,bind   0   0

/media/web/www  /var/www        none    defaults,bind   0       0

Description of my issue

I guess it’s race condition issue during shutdown and maybe during boot up too
But it would be nice to know if someone got the settings right for the use of iscsi.

On peut aussi en discuter en français si certains ont des idées.

So,
I’ve experimented a bit and this is my findings, I will describe it in french but I can translate in english if someone will need it someday

iscsiadm

supprimer les mauvaises entrées dans discoverydb ( c’est ce qu’on peut voir avec le nombre de ping sur la photo précédemment, il y en a trop pour le nombre de liens qu’il est sensé y avoir).
iscsiadm -m discoverydb -t sendtargets -p 172.20.0.83:3206 -o delete
grâce à cette pièce de documentation

mais si il y a des entrées malformées et que donc on ne peut pas utiliser la ligne de commande il faut supprimer la référence dans le dossier iscsi
ex:
rm -R /etc/iscsi/send_targets/IP_Adresse,3260/

ensuite supprimer les nodes qui ne nous concernent pas et auxquels on aurait aussi accès
iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:stor.ada.storj -o delete
mais si c’est un duplciata d’une autre connection au même endroit ça va nous dire qu’on est connecté il faut donc d’abord se logout
iscsiadm -m node -T iqn.2005-10.org.freenas.ctl:stor.ada.storj -u
et puis on peut refaire la commande précédente

trouvé grâce à ça
et ça

ensuite en suivant les conseils de ce problème-là

et en cherchant /etc/default/bootlogd qui ne s’y trouve plus
ça m’a donné l’envie de voir ce qu’il y avait à
/etc/default/open-iscsi

plein d’options intéressantes comme pour ce cas-ci et qui sont initialisées à rien du tout ou à 0

    # Additional mounts to exclude at shutdown.
    #
    # If you have additional mounts on iSCSI that shouldn't be umounted at
    # shutdown by open-iscsi (by default, open-iscsi excludes / and on
    # systemd systems als /usr), place them here. iSCSI sessions that carry
    # these mounts will also be kept open.
    #
    # If any of these mountpoints contain spaces, please use the same
    # escaping as in /etc/fstab, i.e. replace the spaces with \040.
    EXCLUDE_MOUNTS_AT_SHUTDOWN=""

et

# Don't logout from ANY iSCSI session on shutdown
#
# When shutting down, if the root filesystem is on iSCSI, open-iscsi
# tries to determine which sessions are still required for the root
# filesystem. By default, the host will still logout from all other
# sessions.
#
# If you are running a very complicated setup of your root filesystem
# (multiple mapping levels stacked on top of each other), it may be the
# case that the autodetection logic doesn't work propery. You may then
# enable this setting to keep around all iSCSI sessions.
#
# Note that /etc/iscsi/iscsi.initramfs must exist for this option to
# have any effect at all.
#
# This was the default behavior in previous versions of this package
# up to the version that shipped with Debian 8 (Jessie).
#
ISCSI_ROOT_KEEP_ALL_SESSIONS_AT_SHUTDOWN=0

(AAAAAAH le bonheur des changements de fichier de configuraiton lors des upgrade, qui n’ont aucun sens )

on pourrait modifier ISCSI_ROOT_KEEP_ALL_SESSIONS_AT_SHUTDOWN=0 à 1
et mettre aussi les points de montage nécessitant une exception mais il faut trouver la bonne syntaxe.
Quoiqu’il en soit je les ai donc initiliasié un par un /home/yunohost.multimedia,/home/yunohost.back etc
Aussi dans le même temps il nous faut récupérer un iscsi initramfs
mais par chance des braves ont trouvé le temps de créer des setup raspi sans disk

ce qui nous donne

iscsi name for the RPi

ISCSI_INITIATOR=iqn.1993-08.lan.internal.rpi:01:6df87742251d

iscsi target (eg: your NAS)

ISCSI_TARGET_NAME=iqn.2004-04.com.qnap:ts-419pii:iscsi.rpi.d55618
ISCSI_TARGET_IP=192.168.1.100

cette ligne là ISCSI_INITIATOR=iqn.1993-08.lan.internal.rpi:01:6df87742251d on va aller la chercher dans /etc/iscsi/initiatorname.iscsi
les deux autres lignes on les connait déjà un peu de part les commandes précédentes. L’IP elle, on la connait
la target on va l’afficher grâce à iscsiadm -m node

Avec tout ça vous vous débarasserez déjà du failed au démarrage de iscsi.
Le problème maintenant étant que la machine virtuelle ne s’éteint jamais et cela est évidemment dû aux connexions qu’ils ne peut pas terminer mais le système aurait quand même du le faire par lui-même puisque c’était sensé être ça le principe du fichier de configuration. Que le système sync les disques et puis éteigne les connexions ou éteignent le système.

A mon sens, on va remettre la ligne originales pour les points de montage, et laisser la dernière option activée à 1 donc à true et voir si ça fait une différence.

Le problème vient de peertube qui ne se ferme pas correctement en début de cycle de shutdown.
Ce qui laisse son dossier de stockage ouvert et du coup /home ne se ferme pas correctement ce qui peut poser souci aux connexions iscsi.

Mais comme les maintainer ne répondent pas concernant ce qui leur faudrait comme infos pour régler ce bug de fermeture, le seul Workaround possible est de fermer le service peertube manuellement et plus de problème pour la fermeture.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.