crontab soll mount -a ausführen

  • Ich habe zwar die NAS-Laufwerke in fstab eingetragen, das mounten funktioniert aber nicht beim Hochfahren. Mit [font="Courier New"]sudo mount -a[/font] geht es dann.

    Jetzt möchte ich mount -a ein mal als cron-job ausführen und zwar mit einem der beiden Befehle (gefunden in den Weiten des Internets)

    Code
    @reboot /bin/mount -a | at now + 2 minutes
    
    
    @reboot sudo /bin/mount -a | at now + 2 minutes

    Da das nicht funktioniert hat, habe ich testweise in die Crontab eingetragen:

    Code
    */1 * * * * /bin/mount -a
    
    
    */1 * * * * /bin/mount -a
    
    
    */1 * * * * sudo mount -a
    
    
    */1 * * * * mount -a

    In keinem Fall hat er gemountet.

    Was läuft da falsche?

    Einmal editiert, zuletzt von haidi (3. Juli 2016 um 18:53)

  • Als erstes: Wieso über crontab? Kennst du den genauen Zeitpunkt wann @reboot oder "*" ausgeführt wird? Ist das spät genug sodass das als Lösung genutzt werden kann?

    Als zweites: In welche Crontab hast du das eingetragen? Wie lautet der exakte(!!) Befehl?

    Als drittes: */1 entspricht *, also Ausführung jede Minute. Blöde Idee ;)

  • 1) Ich will den Befehl über die crontab 2 oder 3 Minuten nach dem Booten ausführen (siehe den ersten Code-Spoiler), die anderen waren reine Versuche, um nicht 2 Fehlerquellen zu haben

    2) und 3) sind nur "Testaufbauten", ich konnte die Crontab im Editor offen lassen, eine Änderung durchführen, abspeichern und eine Minute darauf lief der Test. Ist wieder deaktiviert.

    2)

    Code
    sudo cronab -e
  • ... Ich will den Befehl über die crontab 2 oder 3 Minuten nach dem Booten ausführen...


    Verzögerungsgesteuerte Aktionen sind immer naheliegend wenn man weiss dass eine Aktion, von der eine weitere Aktion abhängt, eine gewisse Zeit dauert. Die Wartezeit versucht man natürlich so kurz wie möglich zu halten. Erfahrungsgemäss kommt es aber immer mal wieder vor, dass die Zeit nicht ausreicht und man dann sehr blöde nachfolgende Effekte hat, die intermittierend auftreten.

    Ich rate dazu nicht verzögerungszeitgesteuert eine Aktion zu starten sonden aktiv auf ein Ereignis oder Zustand zu prüfen der definitiv sagt, dass das Ereignis, stattgefunden hat und dann die abhängige Aktion zu starten. Du bekommst dadurch weniger graue Haare :D

  • /etc/fstab: füge _netdev als Mount-Option hinzu

    Danke - das war die Lösung des Problems, dass er beim Start nicht gemountet hat.


    Verzögerungsgesteuerte Aktionen sind immer naheliegend wenn man weiss dass eine Aktion, von der eine weitere Aktion abhängt, eine gewisse Zeit dauert. Die Wartezeit versucht man natürlich so kurz wie möglich zu halten. Erfahrungsgemäss kommt es aber immer mal wieder vor, dass die Zeit nicht ausreicht und man dann sehr blöde nachfolgende Effekte hat, die intermittierend auftreten.

    Ich rate dazu nicht verzögerungszeitgesteuert eine Aktion zu starten sonden aktiv auf ein Ereignis oder Zustand zu prüfen der definitiv sagt, dass das Ereignis, stattgefunden hat und dann die abhängige Aktion zu starten. Du bekommst dadurch weniger graue Haare :D


    Mein Problem in diesem Thread war, dass Crontab den Befehl mount nicht ausgeführt hat, da wüsste ich immer noch gerne, warum.


  • 1) Ich will den Befehl über die crontab 2 oder 3 Minuten nach dem Booten ausführen (siehe den ersten Code-Spoiler), die anderen waren reine Versuche, um nicht 2 Fehlerquellen zu haben

    2) und 3) sind nur "Testaufbauten", ich konnte die Crontab im Editor offen lassen, eine Änderung durchführen, abspeichern und eine Minute darauf lief der Test. Ist wieder deaktiviert.

    2)

    Code
    sudo cronab -e

    Die Zeitangabe bezieht sich aber nicht auf "nach dem boot" sondern auf die aktuelle Zeit. */1 bedeutet Jede Minute, 1 würde bedeuten zB 12:01, 13:01, 14:01 usw sofern es Jede Stunde sein sollte...

    Es gibt unterschiedliche Crontabs. Deshalb war meine Frage auch nach dem exakten Befehl wie Du die crontab bearbeitest. Es bringt zB nichts einen mount Befehl in die Benutzercrontab von "pi" einzutragen wenn der Befehl aber root Rechte erfordert.

    Siehe dazu auch FAQ => Nützliche Links / Linksammlung => crontab

    Dh Crontab führt definitiv "mount" aus, wenn man denn die Hintergründe versteht: "mount" darf nur root ausführen. @reboot wird derart früh ausgeführt dass das Netzwerk evtl. noch nicht aktiv ist und somit ein mount.cifs o.ä. nicht funktioniert... Deshalb auch meine Frage ob du den Zeitpunkt kennst wann @reboot ausgeführt wird.

    Mithilfe des Befehls systemd-analyze plot > /tmp/startup.svg kann man sich visuell darstellen lassen wann welcher Dienst beim Bootvorgang gestartet wird. Diese startup.svg Datei kannst du dann mit deinem Webbrowser betrachten.
    Darüber erkennst du zum Beispiel:
    local-fs-pre.target sowie local-fs.target wird früher ausgeführt als networking.service ... local-fs-pre.target verarbeitet /etc/fstab und mounted alle "local mount points". Da du deine NAS-Freigabe aber nicht als "network device" markiert hast ist der Zeitpunkt also zu früh und genau deshalb scheitert es ;)
    cron.service wird zwar später ausgeführt, garantiert deshalb aber nicht das die NAS-Freigabe auch zu dem Zeitpunkt verfügbar ist...

  • Die Zeitangabe beim Test bezieht sich natürlich auf die aktuelle Zeit und in der Art soll es nicht im Echtbetrieb laufen.
    Im Echtbetrieb hätte ich mit @reboot gearbeitet, damit wäre der Befehl immer nach dem Booten ausgeführt worden, egal wann gebootet wird.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!