rpi444 ich hoffe doch stark, dass das so funktioniert, sonst wären die Begrifflichkeiten und Funktionen ziemlich umsonst.
Was soll den funktionieren oder nicht funktionieren? Du hast wohl auch nicht verstanden was ich geschrieben bzw. gemeint habe?
Beiträge von rpi444
-
-
Ja, das ist so, weil ja ExecStartPre und ExecStart Dinge erfolgreich zuende gebracht haben müssen, ...
Aber mit "vollständig ausgeführt" meinte ich ja nicht "ExecStartPre und ExecStart", sondern "/home/pi/db_backup/db_backup.sh" (siehe oben).
-
Ist das so, dass:
warten würde bis
vollständig ausgeführt ist? ich denke mit "ExecStartPre" und "ExecStartPost" wird nur die Reihenfolge der Ausführung bestimmt.
-
Allerdings funktionieren die Events nicht. Beim manuellen Start des Scriptes funktionieren sie.
Evtl. haben die Events eine Abhängigkeit, die z. Zt. nur beim manuellen Start des Scripts erfüllt werden kann.
Poste mal die Ausgabe von:
-
nur als kleiner Einwurf, ich nutze bei meinen Service Units für Python Skripte welche endlos laufen: Type=simple
Ja. BTW: "Type=oneshot" (ist default) + "RemainAfterExit=yes" ist identisch mit "Type=simple".
-
Dann bleibt noch die Frage, warum ich das Module "events" beim manuellen Start nutzen kann, über die Unit aber nicht.
Hast Du auch nach der letzen Änderung, mit dem Modul "events"schon getestet?
-
... ein Aufruf der Website ewig bzw. wird von Safari auch direkt abgebrochen wegen Timeout.
.... Powersafe Modus habe ich aus, jedoch ohne Erfolg.
Safari ist doch MacOS. Dann versuch mal mit .locale (avahi? ... oder wie heißt das auf dem Mac?).
Du könntest im Mac auch einen statischen arp-cache-Eintrag für den PI konfigrieren. Siehe z. B.:
auf deinem Mac.
Wie hast Du auf deinem PI den "Powersafe Modus" deaktiviert?
-
Wenn ich nun aber die Unit über "sudo systemctl start myscript.service" starte, startet die Unit zunächst problemlos und ich kann übers Netzwerk mit meinem Script kommunizieren. Nach einigen Sekunden (ca. 10?) beendet die Unit dennoch mit einer Fehlermeldung.
Versuch mal in der service unit, statt mit "Type=forking", mit:
-
Ich finde da aber keine Konfigzeile fuer dnsmasq dass nur auf bestimmte MAC Adressen reagiert wird
Evtl. könntest Du bestimmte MAC-Adressen blacklisten bzw. ignorieren lassen. Z. B.:
-
Ich habe PolKit nicht aktiv installiert.
Wie ist z. Zt. auf deinem PI, die Ausgabe von:
?
-
Genau das wird ja über PolKit geregelt.
Ja, aber evtl. ist PolKit nicht installiert oder nicht "richtig" installiert.
EDIT:
BTW: Evtl. hätte man hier die service unit auch als user-eigene service unit anlegen bzw. aktivieren können. Z. B.:
-
Welche Meldung kommt wenn Du mit sudo startest?
-
Wie bekomm man heraus, welchen Chipsatz der glitzernde Chip hat? Und passt dazu die Driverversion?
Siehe die Ausgabe von:
Der Treiber ist OK.
EDIT:
Teste mal auch das WLAN-Verhalten deines PI, wenn das WLAN-Interface im "freizügigen" Modus ist:
Wenn Du eine 2. SD-Karte hast, dann evtl. auch mit:
testen.
EDIT 2:
Teste mal ob das onboard-wifi deines PI3 auch bei einem größeren Download (nach /dev/null) via WLAN-Interface, hängen bleibt:
Evtl. auch _ohne_ und mit angeschlossener Tastatur/Bildschirm am PI3, testen.
-
Mein Plan ist es, dass ich am Desktop-PC verschiedene Notizen erstelle und diese dann via Netzwerk an den Raspberry inkl. Monitor anzeigen lassen möchte.
Siehe z. B. diesen Thread im UU.
-
autschi - wLan -wech ... Neustart
OK, dann gro und gso erneut auf off, die mtu auf 1472 setzen:
und in die "/etc/sysctl.conf" folgende Zeilen eintragen:
Alles anzeigenCode- vm.min_free_kbytes = 65536
- net.ipv4.tcp_max_orphans = 128
- net.ipv4.tcp_retries2 = 8
- net.ipv4.tcp_fastopen = 2
- net.ipv4.conf.wlan0.disable_policy = 1
- net.ipv4.conf.wlan0.disable_xfrm = 1
- net.ipv4.neigh.default.gc_thresh3 = 256
- net.ipv4.neigh.default.gc_thresh2 = 128
- net.ipv4.neigh.default.gc_thresh1 = 64
- net.ipv4.tcp_window_scaling = 0
- net.ipv4.tcp_moderate_rcvbuf = 0
- net.ipv4.tcp_timestamps = 1
- net.ipv4.tcp_tw_reuse = 1
- net.ipv4.tcp_mtu_probing = 2
- net.ipv4.tcp_synack_retries = 3
- net.ipv4.xfrm4_gc_thresh = 131072
- net.ipv6.conf.wlan0.autoconf = 0
- net.ipv4.tcp_challenge_ack_limit = 999999999
- vm.swappiness = 5
- net.ipv6.conf.wlan0.accept_dad = 0
- net.core.optmem_max = 4194304
- net.core.rmem_max = 26214400
- net.core.rmem_default = 12582912
- net.ipv4.tcp_rmem = 4194304 12582912 26214400
- net.ipv4.tcp_congestion_control = cubic
- net.ipv4.tcp_fack = 1
- net.ipv4.tcp_slow_start_after_idle = 0
- fs.protected_hardlinks = 1
- fs.protected_symlinks = 1
- net.ipv4.tcp_rfc1337 = 1
- net.ipv4.tcp_no_metrics_save = 0
- net.netfilter.nf_conntrack_checksum = 0
die Datei speichern,
ausführen und erneut testen.
BTW: Vor den nächsten reboot solltest Du noch die Zeile:
in die "/boot/config.txt" eintragen.
EDIT:
Was auch testen bzw. schauen solltest ist, ob auf deinem PI vor dem hängen bleiben, Prozesse mit dem Zustandsflag "D" (uninterruptible sleep (usually IO)) enstehen:
Solche Prozesse können auch dazu führen, dass der PI nicht mehr reagiert. Diese Prozesse können nicht mehr gekillt werden.
-
OK. Befehl soll zeigen ob Du Eintragungen in die /etc/sysctl.conf (oder gleichwertig) gemacht hast.
Teste jetzt mal mit cat und deinem Script bzw. mit deiner großen log-Datei (via onboard-wifi).
-
OK, ok, das ist so:
Und jetzt testen bzw. die Ausgabe von "sudo sysctl -p" noch posten.
-
sudo ethtool -K wlan0 gro off gso off
Cannot get device udp-fragmentation-offload settings: Operation not supported
Cannot get device udp-fragmentation-offload settings: Operation not supported
Das ist normal, wichtig ist jetzt die Ausgabe von:
statt
-
sudo ethtool -k wlan0
Auf meinem PI3 habe ich gro und gso auf off:
Mach mal auf deinem PI:
und teste. Hast Du die Ausgabe von "sudo sysctl -p" schon gepostet?
-
... -> keine Ahnung wie das geht.
Poste mal die Ausgaben von:
EDIT:
Hier z. B. kann man lesen wie der Kernel Aufgaben an die (onborad-)NIC delegiert.
