Zitat von Ghost

von unserer Seite besteht da kein Interesse. Das ist immer noch eine Settop Box. Und 99% der Leute benötigen kein cron. Und wir selber auch nicht.

Und die die es schaffen eine Crontab anzulegen können auch den rest selber anlegen.

Das ist völlig OK so. Ich sehe keinen Sinn drin dass DMM jetzt wertvolle Entwicklerzeit drauf verschwendet cron in ein eigenes Paket auszulagern und nochmal testet. Ich glaub net dass mehr als eine handvoll von uns crontabs anlegen wird.

Ich habe mein posting, welches ich zum copypaste nehme wenn ich mir mal wieder das flash kaputt gespielt habe, auch updated.

Bin ebenfalls gerade darüber gestolpert, weil ich von einem Linux-System erwarte, das cron einfach funktioniert.
Deswegen habe ich drei Dreamboxen, keine Clones und auch nix anderes.

Zitat von gutemine

Wenn 95% der User den crond gar nicht benutzen und der unnötig Memory und CPU und Startzeit kostet - warum sollte DMM den standardmässig enablen, schon weil du im enigma2 wunderbar services getimed starten kannst.

Was evt. Sinn machen würde wäre ein busybox-cron-startup ipk das dann der user nach Bedarf/Wunsch nachinstallieren kann und das Plugins die cron brauchen/benutzen als dependency definieren könnten. Das ipk muss ja eh nur den Link bzw. des Startscript anlegen, mein altes Cronmanager ipk hat das ja auch so gemacht nur ist es halt nicht mehr zeitgemäß.

Unnötig CPU & Startzeit ? ist bei cron vs. der Python-Suppe im Enigma2 jetzt wohl eher ein Witz, oder?
Der Overhaed ist (ohne Benutzung) sicher nichtmal messbar!

Für einfache (Wartungs-)Aufgaben ist cron perfekt, wenn man sich denn auskennt. Und meine Mama hätte bestimmt auch keine zwei Dreamboxen, wenn es nur um "95% der Anwender" ginge sondern irgendeinen Taiwan-Receiver ausm Baumarkt; denkt mal drüber nach..

Hintergrund (cron) war übrigens das das Fancontrol2-Enigma-Plugin nach einem Stromausfall nach 2 Wochen vergessen hat, wie es eingestellt war und die dm8000 damit weiter gekocht wurde, weil der Lüfter aus war (wenn schon Python/Enigma2: dann bitte ne Warnmeldung ins OSD, das die Kiste 80° hat und man Spiegeleier drauf machen kann..)
Also wollte ich die Sache halt per collectd/Nagios zukünftig überwachen, mit hddtemp fährt die Platte hoch (nicht zielführend), mit smartctl nicht, also crontab.. Kann man bestimmt auch ganz toll mit 100 Zeilen Python lösen, aber im Shell-script ist es eine Zeile.

Makki

Edit/P.S.: Ich entwickle selbst Embedded Linux-Systeme und genau deswegen, weil ich den Aufwand kenne, kauf ich mir gerne ne Dreambox; aber wenn so Basics wie cron nicht mehr gehen, nervt das einfach.

Hallo Makki,

Führe doch einmal die Zeile in https://www.dream-multimedia-t…&postID=130565#post130565 aus, dann geht cron wieder wie auf jeder anderen Linux Kiste. Und den POerformance Verlust kann man wirklich vergessen, der ist nicht messbar.

Ok
Also update-rc.d busybox-cron defaults bekomme ich schon echt auch alleine hin
Aber man muss eben:

mkdir -p /etc/cron/crontabs
update-rc.d busybox-cron defaults
/etc/init.d/busybox-cron start
(restart geht nicht, falls es vorher nicht schon lief, weil das init-script einfach sehr schlecht gemacht ist !?!)
Und ab hier kann man weniger versierten Nutzern wieder sagen: "Schreibs halt einfach in die crontab: .. ssh/putty, crontab -e, ...."

Leute die keinen Pinguin aufm T-Shirt tragen dürften da aber deutlich scheitern und selbst mich hat es lästige 15-30 Minuten gekostet;
Daher bitte einfach beim nächsten Image fixen, die Resourcenbenutzung ist nichtmal in der Nähe einer schlechten Ausrede. Problem zugeben, fixen, fertig.

Makki