☰

Mount und Umount verhalten sich unterschiedlich, wenn sie unter Cron ausgeführt werden

tag-icon • tag-icon mount cron centos-6 fuse umount
Mount und Umount verhalten sich unterschiedlich, wenn sie unter Cron ausgeführt werden

Ich verwende CentOS 6 in AWS und was ich sehe, verwirrt mich.

Es gibt eine s3fsEinbindung, /etc/fstabdie manchmal ihre Lese- und Schreibfähigkeit verliert. Ich habe einen Cron-Job, der monatelang super funktioniert hat. Er hat einfach jede Minute getestet, ob die Einbindung in Ordnung war, und wenn die Verbindung jemals verloren ging, hat er einfach umountdie mountFreigabe gelöscht. Die Einbindung ging im Leerlauf häufiger verloren als unter tatsächlicher Belastung, also war das eine tolle Lösung.

Aus irgendeinem Grund funktionierte dies nicht mehr und jetzt können die Maschinen nicht mehr von der Freigabe lesen/schreiben, da das Erste, was die Maschinen nach dem Booten nach der Bereitstellung tun, umountdie mountFreigabe ist.

Beim Versuch zu lesen erhalte ich folgende Fehlermeldung:

cp: cannot open `/app/canary.txt' for reading: Input/output error

Darin /var/log/messagessehe ich Folgendes:

kernel: s3fs[3077]: segfault at e66000 ip 00007f833663d94e sp 00007ffc849c5b18
error 4 in libc-2.12.so[7f83365b4000+18a000]

Wenn ich jetzt genau dasselbe Skript als Root in der Konsole ausführe, funktioniert es einfach perfekt. Das Laufwerk wird ausgehängt und wieder eingehängt und in einem funktionierenden Zustand belassen.

Meine erste Vermutung war, dass etwas in der Umgebung den Unterschied verursachte, also fügte ich source /root/.bash_profilemeinem Skript ein hinzu, jedoch ohne Erfolg.

Die Zeile in /etc/fstab ist ein Monster, aber nach vielen Feinabstimmungsversuchen haben wir herausgefunden, dass dies am besten funktioniert:

ourbucket /app fuse.s3fs _netdev,allow_other,endpoint=us-west-2,url=https://s3-us-west-2.amazonaws.com,use_path_request_style,use_sse,gid=1001,umask=0007,use_cache=/srv/s3fs,retries=20,parallel_count=30,connect_timeout=30,readwrite_timeout=60,stat_cache_expire=86400,max_stat_cache_size=100000 0 0

So sieht das Cronfile aus:

* * * * * root /usr/bin/sudo /root/check_mount.sh

Ich habe es mit und ohne Sudo versucht, da ich dachte, es könnte die Umgebung beeinträchtigen.

Ich habe viele Variationen des Skripts ausprobiert, aber die meisten dieser Befehle wurden irgendwann einmal verwendet. Das Problem tritt immer wieder auf, egal, welche Art von umountSkript ich ausführe.

\cp /app/canary.txt /tmp/canary.txt
retVal=$?
sleep 1
if [ ${retVal} -ne 0 ]; then
    echo "Copy failed, trying to umount"
    umount /app
    echo "umount returned $?"
    sleep 1
    echo "Trying umount -f"
    umount -f /app
    echo "umount -f returned $?"
    sleep 1
    echo "Trying fusermount -u"
    /usr/local/bin/fusermount -u /app
    echo "fusermount returned $?"
    sleep 1
    echo "Trying to mount"
    mount /app
    echo "mount returned $?"
    sleep 1
    echo "Trying copy after mount"
    \cp /app/canary.txt /tmp/canary.txt
fi

Dieses Skript war ursprünglich in python, wobei die wichtigsten Teile nur bis zu ausgaben os.system, aber ich wollte das aus der Gleichung entfernen. Es gab die gleichen Probleme.

Antwort1

Hier ist meine Komplettlösung:

Zuerst habe ich das Audit.log visuell geprüft. Um die richtigen Dinge und nur die richtigen Dinge zu erfassen, habe ich audit2alloweine Richtlinie und eine Regel zur Typdurchsetzung erstellt.

grep mount /var/log/audit/audit.log | audit2allow -R -M mounts3fs

Ich suche nach Mount, damit ich nur die richtigen Dinge bekomme.

Dadurch entstand einemounts3fs.ppUndmounts3fs.teDatei. Diemounts3fs.tesieht aus wie das:

policy_module(mounts3fs, 1.0)

require {
    type file_t;
    type var_t;
    type mount_t;
    type cert_t;
    class dir { write remove_name add_name };
    class file { create unlink link setattr };
}

#============= mount_t ==============
#!!!! The source type 'mount_t' can write to a 'dir' of the following types:
# user_home_t, etc_runtime_t, var_run_t, mount_var_run_t, mount_tmp_t, user_home_dir_t, etc_t, nfs_t, tmpfs_t, tmp_t, var_t

allow mount_t cert_t:dir { write remove_name add_name };
allow mount_t cert_t:file { create unlink };
allow mount_t file_t:dir { remove_name add_name };
allow mount_t file_t:file { unlink link setattr };
allow mount_t var_t:file link;

Um die Richtlinie zu installieren, führe ich Folgendes aus:

semodule -i mounts3fs.pp

Ich habe festgestellt, dass dies für bestimmte Vorgänge nicht ganz ausreicht, daher habe ich eine zusätzliche Richtlinie wie diese erstellt:

module s3fs 1.0;

require {
    type file_t;
    type mount_t;
    class dir create;
    class file create;
}

#============= mount_t ==============

#!!!! This avc is allowed in the current policy
allow mount_t file_t:dir create;
allow mount_t file_t:file create;

selinuxkann immer noch direkt zur Hölle fahren.

verwandte Informationen