SVN: Änderungen an updatefhem

[Martin Fischer]

Hiya,

da wir (Rudi, Boris und ich) derzeit einiges an Umstrukturierungen in Fhem
vornehmen, die wir nach Möglichkeit vollkommen transparent und möglichst ohne
notwendige grösseren Eingriffe Eurerseits umsetzen, kommt es zur Zeit vermehrt
zu Aktualisierungen im SVN bei den dazu notwendigen Modulen.

An dieser Stelle möchte ich nochmal betonen, das ein updatefhem zur Zeit noch
_immer_ auf eine Entwicklerversion zugreift, die mitunter auch mal einen
Fehler enthalten kann! Obwohl wir stets bemüht sind, Fehler möglichst
auszuschliessen, sind auch wir davon nicht befreit

Gestern habe ich den neuen Befehl 'backup' im SVN veröffentlicht. Um die Sache
nun mit 'updatefhem' anzugleichen, wurde der Befehl updatefhem erneut
überarbeitet (kann vor Veröffentlichung der 5.3 noch öfter vorkommen ).

Die von 'updatefhem' genutzte interne Backup-Routine wurde komplett entfernt.
'updatefhem' nutzt nun den neuen Befehl 'backup'. Bei _jedem_ update wird
_vorher_ _immer_ ein Backup der Installation angelegt. Dieses Verhalten kann
über das neue globale Attribut beeinflusst werden. Man
sollte aber wissen, was man macht, wenn diese automatischen Backups
ausgeschaltet werden!

Dadurch hat sich auch der Aufruf von 'updatefhem' in sofern geändert, das der
Parameter nicht mehr existiert.

Es sei hiermit angekündigt, das es noch weitere strukturelle Änderungen folgen
werden und dadurch ggf. auch noch einige Befehle überarbeitet werden. Zur Zeit
ist die aktuelle Version von 'updatefhem' nur ein Zwischenschritt!

Der Entwicklungsstand, bzw. die Diskussion dazu kann in der Google-Group
groups.google.com/group/fhem-developers verfolgt werden.

Nachfolgend der Auszug aus der commandref.html zu dem geänderten 'updatefhem':

global Attributes:

backup_before_update
If this attribute is set to 0, updatefhem skip always backing up your
installation via the backup command. The default is to backup always before
updates.
Note: Set this attribute only if you know what you do!
This Attribute is used by the updatefhem command.
Example:
    attr global backup_before_update 0

Command:

updatefhem

    updatefhem [| [] []|
[]]

Update the fhem modules and documentation from a nightly SVN checkout. For
this purpose Fhem contacts http://fhem.de/fhemupdate, compares the stored
timestamps of the local files with the filelist on the server, and downloads
the files changed on the server. For all downloaded modules a reload will be
scheduled if the corresponding module is loaded.

Note: Since Version 5.3 a new directory structure is used by Fhem. The
WebInterface pgm2 is separated from modpath/FHEM directory. The directory
modpath/www/pgm2 is the new home of pgm2 and of its files. It is recommended
to update to the new structure via the arguments.

The complete installation of Fhem will be saved via the backup command on
every update. You can skip this backups by setting the global attribute
backup_before_update to 0.

If an explicit is given, then only this file will be downloaded.

If is specified, then updatefhem switch your Fhem installation
to the new directory structure for the pgm2 WebInterface. The old files are
archived like the argument and the new files are stored to
modpath/www/pgm2. None of the existing files of pgm2 in modpath/FHEM will be
deleted, but are no longer in use.
If you like to delete the no more needed files for pgm2 in modpath/FHEM, you
should call with the argument . All files of pgm2
are removed from modpath/FHEM and files like .*example.*, .gplot, .html .css,
.js, and .(gif|jpg|png|svg) are moved to modpath/www/pgm2.

If is specified, you could preserve the old directory structure.
All files of pgm2 are updated and stored in modpath/FHEM like the former
(before Fhem 5.3) updatefhem funktion. To update an explicit file to the old
structure append the file as .
Note: After running the housekeeping process, the argument is no
longer necessary and no more supported.

Notes:
If the main program (fhem.pl) is changed, a manual restart of fhem will be
necessary to apply the changes.
After running it is recommended to restart Fhem.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[LuckyDay]

                                         

Hallo Martin,

warum baust du in die Routine nicht die Abfrage ein ?
ob überhaupt "attr global backup_before_update" in der fhem config
gesetzt ist.
Falls nicht gesetzt, dann die Frage wie der User es denn haben will ?
yes or no
Weil du glaubst doch nicht, das jeder erst die Googlegroops liest und
als zugabe die comandref
bevor er updatefhem eingibt.

ich persönlich möchte kein backup, ohne logs und meine geänderten
Dateien.
und vorallem das Backup auf einer anderen Platte(Rechner).

Hary

On 2 Jun., 19:13, Martin Fischer wrote:
> Hiya,
>
> da wir (Rudi, Boris und ich) derzeit einiges an Umstrukturierungen in Fhem
> vornehmen, die wir nach Möglichkeit vollkommen transparent und möglichst ohne
> notwendige grösseren Eingriffe Eurerseits umsetzen, kommt es zur Zeit vermehrt
> zu Aktualisierungen im SVN bei den dazu notwendigen Modulen.
>
> An dieser Stelle möchte ich nochmal betonen, das ein updatefhem zur Zeit noch
> _immer_ auf eine Entwicklerversion zugreift, die mitunter auch mal einen
> Fehler enthalten kann! Obwohl wir stets bemüht sind, Fehler möglichst
> auszuschliessen, sind auch wir davon nicht befreit
>
> Gestern habe ich den neuen Befehl 'backup' im SVN veröffentlicht. Um die Sache
> nun mit 'updatefhem' anzugleichen, wurde der Befehl updatefhem erneut
> überarbeitet (kann vor Veröffentlichung der 5.3 noch öfter vorkommen ).
>
> Die von 'updatefhem' genutzte interne Backup-Routine wurde komplett entfernt.
> 'updatefhem' nutzt nun den neuen Befehl 'backup'. Bei _jedem_ update wird
> _vorher_ _immer_ ein Backup der Installation angelegt. Dieses Verhalten kann
> über das neue globale Attribut beeinflusst werden. Man
> sollte aber wissen, was man macht, wenn diese automatischen Backups
> ausgeschaltet werden!
>
> Dadurch hat sich auch der Aufruf von 'updatefhem' in sofern geändert, das der
> Parameter nicht mehr existiert.
>
> Es sei hiermit angekündigt, das es noch weitere strukturelle Änderungen folgen
> werden und dadurch ggf. auch noch einige Befehle überarbeitet werden. Zur Zeit
> ist die aktuelle Version von 'updatefhem' nur ein Zwischenschritt!
>
> Der Entwicklungsstand, bzw. die Diskussion dazu kann in der Google-Group
> groups.google.com/group/fhem-developers verfolgt werden.
>
> Nachfolgend der Auszug aus der commandref.html zu dem geänderten 'updatefhem':
>
> global Attributes:
>
> backup_before_update
> If this attribute is set to 0, updatefhem skip always backing up your
> installation via the backup command. The default is to backup always before
> updates.
> Note: Set this attribute only if you know what you do!
> This Attribute is used by the updatefhem command.
> Example:
>     attr global backup_before_update 0
>
> Command:
>
> updatefhem
>
>     updatefhem [| [] []|
> []]
>
> Update the fhem modules and documentation from a nightly SVN checkout. For
> this purpose Fhem contactshttp://fhem.de/fhemupdate, compares the stored
> timestamps of the local files with the filelist on the server, and downloads
> the files changed on the server. For all downloaded modules a reload will be
> scheduled if the corresponding module is loaded.
>
> Note: Since Version 5.3 a new directory structure is used by Fhem. The
> WebInterface pgm2 is separated from modpath/FHEM directory. The directory
> modpath/www/pgm2 is the new home of pgm2 and of its files. It is recommended
> to update to the new structure via the arguments.
>
> The complete installation of Fhem will be saved via the backup command on
> every update. You can skip this backups by setting the global attribute
> backup_before_update to 0.
>
> If an explicit is given, then only this file will be downloaded.
>
> If is specified, then updatefhem switch your Fhem installation
> to the new directory structure for the pgm2 WebInterface. The old files are
> archived like the argument and the new files are stored to
> modpath/www/pgm2. None of the existing files of pgm2 in modpath/FHEM will be
> deleted, but are no longer in use.
> If you like to delete the no more needed files for pgm2 in modpath/FHEM, you
> should call with the argument . All files of pgm2
> are removed from modpath/FHEM and files like .*example.*, .gplot, .html .css,
> .js, and .(gif|jpg|png|svg) are moved to modpath/www/pgm2.
>
> If is specified, you could preserve the old directory structure.
> All files of pgm2 are updated and stored in modpath/FHEM like the former
> (before Fhem 5.3) updatefhem funktion. To update an explicit file to the old
> structure append the file as .
> Note: After running the housekeeping process, the argument is no
> longer necessary and no more supported.
>
> Notes:
> If the main program (fhem.pl) is changed, a manual restart of fhem will be
> necessary to apply the changes.
> After running it is recommended to restart Fhem.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

hallo hary,

Am Samstag, 2. Juni 2012, 15:40:30 schrieb fhem-hm-knecht:
> warum baust du in die Routine nicht die Abfrage ein ?
> ob überhaupt "attr global backup_before_update" in der fhem config
> gesetzt ist.

die abfrage besteht bereits...

> Falls nicht gesetzt, dann die Frage wie der User es denn haben will ?
> yes or no

...nur genau andersrum: falls nicht gesetzt, dann ist das backup per default
beim update _an_ und nicht _aus_ und das ist auch so gewollt

aufgrund der bevorstehenden änderungen, müssen wir einfach sicherstellen, das
keine lokalen / veränderten / zusätzlich angelegten dateien ggf. beim update
verloren gehen. wer ein backup beim update nicht möchte, der kann es ja per
globalem attribut ausschalten.

> Weil du glaubst doch nicht, das jeder erst die Googlegroops liest und
> als zugabe die comandref
> bevor er updatefhem eingibt.

das mag sein, aber du kannst auch nicht davon ausgehen, das immer alle fragen
hier beantwortet werden, wenn sie dann _explizit_ in der commandref stehen

stell dir vor, das backup würde nicht per default eingeschaltet sein und wir
überschreiben / löschen beim update eine datei und der benutzer hat kein
backup. _das_ "geschrei" möchte ich hier dann nicht erleben

und da es sich bei dem 'updatefhem' um einen direkten eingriff in die
installation der anwender handelt, informiere ich lieber einmal mehr (für die,
die eben nicht die commandref lesen).

ich zitiere hier mal bewusst rudi aus einer diskussion in fhem-developers,
dessen meinung ich vollkommen teile:

Am Freitag, 25. Mai 2012, 09:15:10 schrieb Rudolf Koenig:
> In meinem Augen ist updatefhem fuer Experimentierfreudige, die gerne die
> Entwicklerversion haben, und beim testen mithelfen wollen. Wenn man kein
> Risiko eingehen will, dann macht man den Upgrade auf einem zweiten fhem
> Server, man testet alles durch, und spielt die Aenderungen erst danach auf
> die Produktion ein.

und weiterhin:

Am Freitag, 1. Juni 2012, 09:49:42 schrieb Rudolf Koenig:
> Ich bin da nach etwas nachdenken anderer Meinung: wer updatefhem macht, dem
> ist bewusst (bzw. sollte sein), dass an seinem System Aenderungen
> durchgefuehrt werden, die das System evtl. unbrauchbar machen. Wer keine
> Ueberraschungen haben will, der soll es vorher testen oder per Hand machen,
> oder updatefhem nicht aufrufen.
>
> Wer update gemacht hat, der ist auf dem neuesten Stand, ohne wenn und aber.
> Darauf sollte sich der Entwickler und der Anwender verlassen koennen.

wie gesagt: ich teile die zitate von rudi zu 100%. allerdings gehört dazu auch
die information an den benutzer, damit er weiss was auf ihn bei einem update
zukommt.

die aktuelle version von 'updatefhem' ist auch nur ein zwischenstand, da es
noch weitere veränderungen geben wird. aktuell ist erstmal wichtig, die
funktionsfähigkeit der unterschiedlichen und angepassten installationen trotz
der umstellungen möglichst ohne störungen aufrecht zu erhalten. und ich denke,
bisher haben wir da gute arbeit geleistet

künftig soll es möglich sein, beim update wählen zu können ob man aus
oder updaten / upgraden will. ausserdem wird man die möglichkeit haben
sich _vor_ einen update die änderungen / neuerungen anzusehen und kann dann
immer noch entscheiden, ob man ein update durchführen will. ausserdem wird man
wählen können was man updaten will (alles, oder nur fhem oder pgm2) soviel mal
als kleiner ausblick.

> ich persönlich möchte kein backup, ohne logs und meine geänderten
> Dateien.
> und vorallem das Backup auf einer anderen Platte(Rechner).

leider kann man es nicht jedem recht machen. dennoch gibt es genau für solche
"anforderungen" wie deine eine lösung: genau dafür gibt es ja das globale
attribut und . siehe commandref

das backup berücksichtigt bereits alle deine geänderten dateien mit ausnahme
der logfiles ( allein bei mir sind es >3 gb (logs seit 2008 in verbose 4
für mehr als 60 aktive aktoren / sensoren in fhem ).

ich zitiere hier mal Peter (PanTau):
Am Mittwoch, 30. Mai 2012, 13:36:25 schrieb PanTau:
> keine logfiles gesichert => gut ! (bin auch messi )

wie du siehst, hat jeder eine andere vorstellung. aber ich denke, wir haben da
sehr viel flexibilität und freiheiten bei voller funktionsfähigkeit mit den
befehlen backup und updatefhem realisiert.

wenn du das backup auf einer anderen platte / rechner sichern willst, kannst
du mittels den pfad festlegen ( man kann natürlich auch mittels
nfs oder cifs ( für die windows fraktion ) speicherplatz von einem anderen
rechner mounten und den pfad dann unter eintragen ) oder mittels
dein eigenes backupscript aufrufen. backup übergibt dem script
alle zu sichernden dateien / verzeichnisse exclusive den logdateien ( wie im
beispiel zu in commandref beschrieben ). den pfad der logdateien
an die von backup übergebenen dateien / verzeichnisse anzuhängen, wäre in dem
eigenen script eine leichte aufgabe. dann könntest du in dem script auch
selber wählen, in welcher form und wo archiviert wird.

zusammengefasst:
'updatefhem' macht per default _immer_ ein backup in $modpath/backup, sofern
a) das backup nicht mittels ausgeschaltet wird und
b) _nicht_ auf einen anderen pfad gesetzt wurde oder
c) man seine eigene backupmethode mittels eingerichtet hat.

randbemerkung:
davon mal abgesehen mache auch ich einiges anders als hier vorgegeben. meine
sämtlichen daten vom server werden mittels rsync auf ein nas gesichert,
welches wiederum mittels rsync in ein rechenzentrum gesichert wird damit
habe ich immer auf 3 medien (jeweils mit raid 5) ein backup und das ganze
sogar täglich, wöchentlich sowie alle 3 monate rollierend und das betrifft
nicht nur meine fhem installation, sondern alle meine daten (mehrere TByte).

um nun einen datenverlust zu erfahren muss also mein server explodieren, mein
nas aus dem rack heraus geklaut werden _und_ ein meteorid ins rechenzentrum
fallen

gruss martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Hallo,
super dass an der "UpdateFront" so fundamental der "State of the Art"
einzieht .

Eine "Verbesserung" würde ich mir hierzu wünschen. (wenn eventuell schon
vorgesehen - verzeiht mir meine Unwissenheit)
Ein "Force Modus" der einfach alle Dateien aus dem SVN lädt und
überschreibt. Dass ich dabei eventuell unnötige Dateien runterlade belastet
zwar das Volumenkontingent aber damit könnte ich "leben".
 
Hintergrund dafür ist dass ich schon seit geraumer Zeit mit dem Problem "Can't
get filetimes.txt from fhem.de:80" kämpfe und denke damit aus diesem
Deadlock herauszukommen.

Gruß,
Thoralf

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Und wieder eine neue Änderung im SVN eingecheckt:

updatefhem kennt nun den Parameter und man kann Dateien von einem
Update ausschließen. Sinnvoll z.B. wenn man lokal eine originale Datei (z.B.
ein Modul, ein Icon, eine .css Datei, ein .gplot, etc.) verändert oder
ausgetauscht hat.

Beispiel:
fhem> list global
Internals:
   DEF        
   NAME       global
   NR         1
   STATE      
   TYPE       Global
   currentlogfile /var/log/fhem/fhem-2012-06.log
   logfile    /var/log/fhem/fhem-%Y-%m.log
Attributes:
   autoload_undefined_devices 1
   configfile /etc/fhem.cfg
   exclude_from_update 99_updatefhem.pm

fhem> updatefhem changed
List of new / modified files since last update:
2012-06-03_07:45:09 ./CHANGED
2012-06-03_17:16:10 FHEM/10_CUL_HM.pm
2012-06-03_07:45:09 FHEM/99_updatefhem.pm ==> excluded from update!

List of changes:
- SVN
  - feature: new Module 59_Twilight.pm to calculate current daylight
  - feature: internal NotifyOrderPrefix: 98_average.pm is more straightforward
  - feature: the usb command tries to flash unflashed CULs on linux
  ...
  ...

fhem> updatefhem
tar: Entferne führende ,,/" von Elementnamen
backup done: FHEM-20120603_175926.tar.gz (1165138 Bytes)
updated ./CHANGED
updated FHEM/10_CUL_HM.pm
excluded FHEM/99_updatefhem.pm
update finished


Nachfolgend ein Auszug aus der commandref:

Command:

updatefhem

updatefhem [|| [] []|
[]]

[...]

Have you change or replace original files of the Fhem Distribution, these
files will normally be overwritten during an update. To protect your locally
modified or replaced files during an update, you can exclude these files with
the global attribute exclude_from_update.

If is specified, updatefhem returns a list of new or modified files
since the last update. Furthermore it returns the last changes from the
CHANGED file (if the file exists on the update server).

[...]


global Attributes:

[...]

exclude_from_update
Contains a space separated list of file which will be excluded by an update.
This Attribute is used by the updatefhem command.
Example:
    attr global exclude_from_update 21_OWTEMP.pm temp4hum4.gplot FS20.on.png

[...]

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Hallo Thoralf,

Am Sonntag, 3. Juni 2012, 03:35:04 schrieb SiberianHusky:
> super dass an der "UpdateFront" so fundamental der "State of the Art"
> einzieht .

danke für die positive Rückmeldung!

> [...]
> Hintergrund dafür ist dass ich schon seit geraumer Zeit mit dem Problem
> "Can't get filetimes.txt from fhem.de:80" kämpfe und denke damit aus diesem
> Deadlock herauszukommen.

das sollte nicht sein und ich kann es mir auch nicht erklären.

kannst du bitte mal die ersten 20 zeilen von 99_updatefhem.pm hier posten.

gruss martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Sonntag, 3. Juni 2012 18:24:19 UTC+2 schrieb Martin Fischer:

>> kannst du bitte mal die ersten 20 zeilen von 99_updatefhem.pm hier
posten.


Hallo,
Danke für die Unterstützung  .
Hier die ersten 20 Zeilen "meiner" 99_updatefhem.pm

##############################################
# $Id: 99_updatefhem.pm 1519 2012-05-01 16:13:44Z rudolfkoenig $
package main;
use strict;
use warnings;
use IO::Socket;

sub CommandUpdatefhem($$);
sub CommandCULflash($$);
sub GetHttpFile($$@);

my $server = "fhem.de:80";
my $sdir   = "/fhemupdate";
my $ftime  = "filetimes.txt";
my $dfu    = "dfu-programmer";


#####################################
sub
updatefhem_Initialize($$)


Gruss,
Thoralf
 

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Hallo Thoralf,

Am Sonntag, 3. Juni 2012, 13:00:05 schrieb SiberianHusky:
> Am Sonntag, 3. Juni 2012 18:24:19 UTC+2 schrieb Martin Fischer:
> >> kannst du bitte mal die ersten 20 zeilen von 99_updatefhem.pm hier
> [...]
> ##############################################
> # $Id: 99_updatefhem.pm 1519 2012-05-01 16:13:44Z rudolfkoenig $
> [...]
> my $server = "fhem.de:80";
> my $sdir   = "/fhemupdate";
> my $ftime  = "filetimes.txt";
> my $dfu    = "dfu-programmer";

also du hast definitiv noch eine alte version. aktuell von heute ist release
1601 (ab morgen früh verfügbar).

lösch bitte mal per hand die datei filetimes.txt in deinem $modpath/FHEM
verzeichnis (bei default installation auf einem rechner ist das
/usr/share/fhem/FHEM/filetimes.txt, bei der fritzbox liegt glaub ich alles in
einem verzeichnis).

dann ruf updatefhem erneut auf und berichte hier bitte.

gruß martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guido]

                                                       

Hallo,

Das neue automatische Backup vor einem Update gefällt mir grundsätzlich
gut, nur habe ich gemerkt das es meine Fritzbox doch mächtig zum schwitzen
bringt die CPU Last steigt während des Backups auf 100%.

Da meine Fritzbox auch beim anzeigen großer Logdateien in FHEM abschmiert
und rebootet könnte ich mir vorstellen das dies bei entsprechender
Auslastung beim Update auch passiert.

Außerdem sollten Fritzboxuser auch darauf achten das wenn kein attr global
backupdir gesetzt ist der interne Speicher der Box durch die angelegten
Backups irgendwann voll ist.

Kann man die CPU Nutzung durch FHEM auf der Fritzbox irgendwie begrenzen um
ein abschmieren zu verhindern ?



Am Sonntag, 3. Juni 2012 22:40:05 UTC+2 schrieb Martin Fischer:
>
> Hallo Thoralf,
>
> Am Sonntag, 3. Juni 2012, 13:00:05 schrieb SiberianHusky:
> > Am Sonntag, 3. Juni 2012 18:24:19 UTC+2 schrieb Martin Fischer:
> > >> kannst du bitte mal die ersten 20 zeilen von 99_updatefhem.pm hier
> > [...]
> > ##############################################
> > # $Id: 99_updatefhem.pm 1519 2012-05-01 16:13:44Z rudolfkoenig $
> > [...]
> > my $server = "fhem.de:80";
> > my $sdir   = "/fhemupdate";
> > my $ftime  = "filetimes.txt";
> > my $dfu    = "dfu-programmer";
>
> also du hast definitiv noch eine alte version. aktuell von heute ist
> release
> 1601 (ab morgen früh verfügbar).
>
> lösch bitte mal per hand die datei filetimes.txt in deinem $modpath/FHEM
> verzeichnis (bei default installation auf einem rechner ist das
> /usr/share/fhem/FHEM/filetimes.txt, bei der fritzbox liegt glaub ich alles
> in
> einem verzeichnis).
>
> dann ruf updatefhem erneut auf und berichte hier bitte.
>
> gruß martin
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Am Montag, 4. Juni 2012, 07:22:49 schrieb Guido:
> Das neue automatische Backup vor einem Update gefällt mir grundsätzlich
> gut, nur habe ich gemerkt das es meine Fritzbox doch mächtig zum schwitzen
> bringt die CPU Last steigt während des Backups auf 100%.

das ist einerseits schön ( das es dir gefällt ) aber auch nicht so schön mit
der cpu last der fritzbox.

zwar habe ich 5 fritzboxen im einsatz aber die sollen sich ums internet und
telefon kümmern. deshalb ist mein support für die fritzbox eher beschränkt.
letztlich ist es aber auch ein linux

> Da meine Fritzbox auch beim anzeigen großer Logdateien in FHEM abschmiert
> und rebootet könnte ich mir vorstellen das dies bei entsprechender
> Auslastung beim Update auch passiert.

um das zu verhindern, kannst du präventiv das backup mittels
abschalten, bis es eine lösung gibt. dann musst du halt
das backup zwischendurch mal per hand aufrufen und für den augenblick mit der
hohen last leben.

> Außerdem sollten Fritzboxuser auch darauf achten das wenn kein attr global
> backupdir gesetzt ist der interne Speicher der Box durch die angelegten
> Backups irgendwann voll ist.

das ist richtig!

> Kann man die CPU Nutzung durch FHEM auf der Fritzbox irgendwie begrenzen um
> ein abschmieren zu verhindern ?

eine idee die mir da kommt:
ich habe ja auch das attribut bereitgestellt. das dient ja dazu,
das man sein eigenes backupscript einbinden kann.

du könntest folgendes setzen:
attrib global backupcmd backup.sh

backup.sh müsste dann folgendes beinhalten (achtung nicht getestet!)

---- backup.sh start --------------------------------------
#!/bin/sh

# set all commandline arguments to one variable
PATHS=$@

# get Time and Date
dateTime=`date +%Y%m%d_%H%M%S`

# destination for backups
DST=

(nice 10 tar -cf - ${PATHS} | gzip > /${DST}/FHEM-${dateTime}.tar.gz) 2>&1

echo "backup done"
---- backup.sh end --------------------------------------

damit wird das backup mit einer geringeren priorität gestartet ( -20 hohe
priorität 19 geringste priorität). damit kannst du ja mal spielen.

bei DST= muss natürlich der reale pfad angegeben werden, wohin das archiv
geschrieben werden soll.

und wer seine logfiles auch noch sichern will (z.b. Hary), kann z.b. noch eine
variable
LOGS=
definieren und passt schreibt die variable nocht hinter ${PATHS}, also
(nice 10 tar -cf - ${PATHS} ${LOGS} | ...

natürlich könnte man das script dann auch noch erweitern, das es vorher prüft
ob noch genügend speicherplatz vorhanden ist, wenn nicht, das auch an fhem
zurückmeldet, usw. usw. da fallen mir gerade viele schweinereien ein

ABER, wie gesagt: das obige script ist ungetestet, sollte aber funktionieren.
wenn das von mehreren verifiziert wurde, kann ich auch gerne ein globales
attribut für nice einbauen, damit das direkt von fhem gesetzt werden kann und
man kein eigenes script benötigt.

gruss martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guido]

                                                       

Hallo Martin,

danke erstmal für die schnelle Rückmeldung, das script funktioniert
grundsätzlich erstmal bis auf einen kleinen Fehler der Aufruf von nice muss
mit nice -10 bzw nice --10 erfolgen.

Leider bringt es in punkto CPU Auslastung bei der Fritzbox keinen Erfolg,
ich hab mit verschiedenen Werten das Backup aufgerufen und die CPU
Auslastung steigt jedesmal auf 100% aber gefühlt würde ich sagen ist die
Fritzbox GUI bei positiven nice werten nicht ganz so träge.

Ich kann damit leben, durch die verschiedenen Attribute ist das Backup ja
sehr flexibel.

Danke nochmal und weiter so

Gruß Guido

Am Montag, 4. Juni 2012 19:42:58 UTC+2 schrieb Martin Fischer:
>
> Am Montag, 4. Juni 2012, 07:22:49 schrieb Guido:
> > Das neue automatische Backup vor einem Update gefällt mir grundsätzlich
> > gut, nur habe ich gemerkt das es meine Fritzbox doch mächtig zum
> schwitzen
> > bringt die CPU Last steigt während des Backups auf 100%.
>
> das ist einerseits schön ( das es dir gefällt ) aber auch nicht so schön
> mit
> der cpu last der fritzbox.
>
> zwar habe ich 5 fritzboxen im einsatz aber die sollen sich ums internet
> und
> telefon kümmern. deshalb ist mein support für die fritzbox eher
> beschränkt.
> letztlich ist es aber auch ein linux
>
> > Da meine Fritzbox auch beim anzeigen großer Logdateien in FHEM
> abschmiert
> > und rebootet könnte ich mir vorstellen das dies bei entsprechender
> > Auslastung beim Update auch passiert.
>
> um das zu verhindern, kannst du präventiv das backup mittels
> abschalten, bis es eine lösung gibt. dann musst du
> halt
> das backup zwischendurch mal per hand aufrufen und für den augenblick mit
> der
> hohen last leben.
>
> > Außerdem sollten Fritzboxuser auch darauf achten das wenn kein attr
> global
> > backupdir gesetzt ist der interne Speicher der Box durch die angelegten
> > Backups irgendwann voll ist.
>
> das ist richtig!
>
> > Kann man die CPU Nutzung durch FHEM auf der Fritzbox irgendwie begrenzen
> um
> > ein abschmieren zu verhindern ?
>
> eine idee die mir da kommt:
> ich habe ja auch das attribut bereitgestellt. das dient ja
> dazu,
> das man sein eigenes backupscript einbinden kann.
>
> du könntest folgendes setzen:
> attrib global backupcmd backup.sh
>
> backup.sh müsste dann folgendes beinhalten (achtung nicht getestet!)
>
> ---- backup.sh start --------------------------------------
> #!/bin/sh
>
> # set all commandline arguments to one variable
> PATHS=$@
>
> # get Time and Date
> dateTime=`date +%Y%m%d_%H%M%S`
>
> # destination for backups
> DST=
>
> (nice 10 tar -cf - ${PATHS} | gzip > /${DST}/FHEM-${dateTime}.tar.gz) 2>&1
>
> echo "backup done"
> ---- backup.sh end --------------------------------------
>
> damit wird das backup mit einer geringeren priorität gestartet ( -20 hohe
> priorität 19 geringste priorität). damit kannst du ja mal spielen.
>
> bei DST= muss natürlich der reale pfad angegeben werden, wohin das archiv
> geschrieben werden soll.
>
> und wer seine logfiles auch noch sichern will (z.b. Hary), kann z.b. noch
> eine
> variable
> LOGS=
> definieren und passt schreibt die variable nocht hinter ${PATHS}, also
> (nice 10 tar -cf - ${PATHS} ${LOGS} | ...
>
> natürlich könnte man das script dann auch noch erweitern, das es vorher
> prüft
> ob noch genügend speicherplatz vorhanden ist, wenn nicht, das auch an fhem
> zurückmeldet, usw. usw. da fallen mir gerade viele schweinereien ein
>
>
> ABER, wie gesagt: das obige script ist ungetestet, sollte aber
> funktionieren.
> wenn das von mehreren verifiziert wurde, kann ich auch gerne ein globales
> attribut für nice einbauen, damit das direkt von fhem gesetzt werden kann
> und
> man kein eigenes script benötigt.
>
> gruss martin
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

hallo guido,

Am Dienstag, 5. Juni 2012, 04:28:58 schrieb Guido:
> danke erstmal für die schnelle Rückmeldung, das script funktioniert
> grundsätzlich erstmal bis auf einen kleinen Fehler der Aufruf von nice muss
> mit nice -10 bzw nice --10 erfolgen.

wie ich ja schon schrieb: das script habe ich "aus der hüfte geschossen", also
ungetestet..

ABER: ich glaube wir beide lagen falsch und das nice -10 auch nicht richtig
ist!

zitat aus dem manual:
-n, --adjustment=N
add integer N to the niceness (default 10)

ich weiss nicht wie es auf der fritzbox aussieht. aber es könnte sein, das du
mit "nice -10" dem tar prozess _mehr_ process scheduling zugewiesen hast. denn
es heisst ja:
"Nicenesses range from -20 (most favorable scheduling) to 19 (least
favorable)."

es müsste also korrekt heissen: "nice -n 10".

und um es wahrschinlich komplett richtig zu machen, müsste die zeile lauten:

(nice -n 10 tar -cf - ${PATHS} | nice -n 10 gzip >
/${DST}/FHEM-${dateTime}.tar.gz) 2>&1

und dann kannst du ja noch den wert von beiden nice z.b. auf max. 19 setzen.

versuch das bitte nochmal. ich denke, das sollte dann greifen.

gruss martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Mr. P]

                                                       

Hej hej,

nice ändert auch nichts an der max. CPU-Auslastung.
Es wird nur zur Priorisierung einzelner Prozesse verwendet. Wenn der
FritzBox aber gerade langweilig ist, dann bekommt der Prozess genauso
knappe 100% CPU zur Verfügung gestellt. Der einzige Unterschied ist
der, dass wenn andere (System-)Prozesse mit einer höheren Priorität
laufen, dass das Backup zurückstecken muss.
Wenn dir die FritzBox beim Plot zeichnen gelegentlich mal abschmiert,
dann kann dir nice also auch unter Umständen auch dabei weiter helfen,
damit Systemprozesse auch sicher bevorzugt behandelt werden.
Zwei Dinge noch zu nice, die ich noch im Kopf hab:
1) Priorität 10 ist für gewöhnlich (ich nehme an, auch auf der
FritzBox) die Standard-Priorität, also wirst du erst Änderungen
merken, wenn du die Zahl nach oben oder unten drehst.
2) Prioritäten mit Minus-Zahlen sollten ausschließlich für
Systemprozesse verwendet werden.

Greetz,
   Gerhard


Am 5. Juni 2012 13:28 schrieb Guido :
> Hallo Martin,
>
> danke erstmal für die schnelle Rückmeldung, das script funktioniert
> grundsätzlich erstmal bis auf einen kleinen Fehler der Aufruf von nice muss
> mit nice -10 bzw nice --10 erfolgen.
>
> Leider bringt es in punkto CPU Auslastung bei der Fritzbox keinen Erfolg,
> ich hab mit verschiedenen Werten das Backup aufgerufen und die CPU
> Auslastung steigt jedesmal auf 100% aber gefühlt würde ich sagen ist die
> Fritzbox GUI bei positiven nice werten nicht ganz so träge.
>
> Ich kann damit leben, durch die verschiedenen Attribute ist das Backup ja
> sehr flexibel.
>
> Danke nochmal und weiter so
>
> Gruß Guido
>
> Am Montag, 4. Juni 2012 19:42:58 UTC+2 schrieb Martin Fischer:
>>
>> Am Montag, 4. Juni 2012, 07:22:49 schrieb Guido:
>> > Das neue automatische Backup vor einem Update gefällt mir grundsätzlich
>> > gut, nur habe ich gemerkt das es meine Fritzbox doch mächtig zum
>> > schwitzen
>> > bringt die CPU Last steigt während des Backups auf 100%.
>>
>> das ist einerseits schön ( das es dir gefällt ) aber auch nicht so schön
>> mit
>> der cpu last der fritzbox.
>>
>> zwar habe ich 5 fritzboxen im einsatz aber die sollen sich ums internet
>> und
>> telefon kümmern. deshalb ist mein support für die fritzbox eher
>> beschränkt.
>> letztlich ist es aber auch ein linux
>>
>> > Da meine Fritzbox auch beim anzeigen großer Logdateien in FHEM
>> > abschmiert
>> > und rebootet könnte ich mir vorstellen das dies bei entsprechender
>> > Auslastung beim Update auch passiert.
>>
>> um das zu verhindern, kannst du präventiv das backup mittels
>> abschalten, bis es eine lösung gibt. dann musst du
>> halt
>> das backup zwischendurch mal per hand aufrufen und für den augenblick mit
>> der
>> hohen last leben.
>>
>> > Außerdem sollten Fritzboxuser auch darauf achten das wenn kein attr
>> > global
>> > backupdir gesetzt ist der interne Speicher der Box durch die angelegten
>> > Backups irgendwann voll ist.
>>
>> das ist richtig!
>>
>> > Kann man die CPU Nutzung durch FHEM auf der Fritzbox irgendwie begrenzen
>> > um
>> > ein abschmieren zu verhindern ?
>>
>> eine idee die mir da kommt:
>> ich habe ja auch das attribut bereitgestellt. das dient ja
>> dazu,
>> das man sein eigenes backupscript einbinden kann.
>>
>> du könntest folgendes setzen:
>> attrib global backupcmd backup.sh
>>
>> backup.sh müsste dann folgendes beinhalten (achtung nicht getestet!)
>>
>> ---- backup.sh start --------------------------------------
>> #!/bin/sh
>>
>> # set all commandline arguments to one variable
>> PATHS=$@
>>
>> # get Time and Date
>> dateTime=`date +%Y%m%d_%H%M%S`
>>
>> # destination for backups
>> DST=
>>
>> (nice 10 tar -cf - ${PATHS} | gzip > /${DST}/FHEM-${dateTime}.tar.gz) 2>&1
>>
>> echo "backup done"
>> ---- backup.sh end --------------------------------------
>>
>> damit wird das backup mit einer geringeren priorität gestartet ( -20 hohe
>> priorität 19 geringste priorität). damit kannst du ja mal spielen.
>>
>> bei DST= muss natürlich der reale pfad angegeben werden, wohin das archiv
>> geschrieben werden soll.
>>
>> und wer seine logfiles auch noch sichern will (z.b. Hary), kann z.b. noch
>> eine
>> variable
>> LOGS=
>> definieren und passt schreibt die variable nocht hinter ${PATHS}, also
>> (nice 10 tar -cf - ${PATHS} ${LOGS} | ...
>>
>> natürlich könnte man das script dann auch noch erweitern, das es vorher
>> prüft
>> ob noch genügend speicherplatz vorhanden ist, wenn nicht, das auch an fhem
>> zurückmeldet, usw. usw. da fallen mir gerade viele schweinereien ein
>>
>>
>> ABER, wie gesagt: das obige script ist ungetestet, sollte aber
>> funktionieren.
>> wenn das von mehreren verifiziert wurde, kann ich auch gerne ein globales
>> attribut für nice einbauen, damit das direkt von fhem gesetzt werden kann
>> und
>> man kein eigenes script benötigt.
>>
>> gruss martin
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Am Dienstag, 5. Juni 2012, 14:14:55 schrieb Gerhard Pfeffer:
> [...]
> Zwei Dinge noch zu nice, die ich noch im Kopf hab:
> 1) Priorität 10 ist für gewöhnlich (ich nehme an, auch auf der
> FritzBox) die Standard-Priorität, also wirst du erst Änderungen
> merken, wenn du die Zahl nach oben oder unten drehst.

das hast du noch richtig im kopf nice -n 10 ist als beispiel gedacht und
muss natürlich hochgesetzt werden, wenn das scheduling andere prozesse
bevorzugen soll. an der cpu last ändert das in der tat nichts, sondern nur die
bevorzugung der anderen prozesse. dadurch sollte aber die fritzbox dennoch
"etwas" flüssiger laufen.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guido]

                                                       

Hallo Martin,

hab jetzt mit mehreren nice Werten getestet, wie schon angemerkt wurde
ändert das nichts an der CPU Auslastung die steigt sofort auf 100%, aber je
höher (positive Zahl) der nice Wert um so flüssiger läst sich die GUI der
Fritzbox bedienen, das ist natürlich alles nur gefühlt und nicht gemessen
und woanders wie an der GUI kann ich das nicht festmachen.
Ich habs bei mir jetzt auf 19 gestellt das funktioniert ganz gut.
 

Gruß Guido

Am Dienstag, 5. Juni 2012 14:10:46 UTC+2 schrieb Martin Fischer:
>
> hallo guido,
>
> Am Dienstag, 5. Juni 2012, 04:28:58 schrieb Guido:
> > danke erstmal für die schnelle Rückmeldung, das script funktioniert
> > grundsätzlich erstmal bis auf einen kleinen Fehler der Aufruf von nice
> muss
> > mit nice -10 bzw nice --10 erfolgen.
>
> wie ich ja schon schrieb: das script habe ich "aus der hüfte geschossen",
> also
> ungetestet..
>
> ABER: ich glaube wir beide lagen falsch und das nice -10 auch nicht
> richtig
> ist!
>
> zitat aus dem manual:
> -n, --adjustment=N
> add integer N to the niceness (default 10)
>
> ich weiss nicht wie es auf der fritzbox aussieht. aber es könnte sein, das
> du
> mit "nice -10" dem tar prozess _mehr_ process scheduling zugewiesen hast.
> denn
> es heisst ja:
> "Nicenesses range from -20 (most favorable scheduling) to 19 (least
> favorable)."
>
> es müsste also korrekt heissen: "nice -n 10".
>
> und um es wahrschinlich komplett richtig zu machen, müsste die zeile
> lauten:
>
> (nice -n 10 tar -cf - ${PATHS} | nice -n 10 gzip >
> /${DST}/FHEM-${dateTime}.tar.gz) 2>&1
>
> und dann kannst du ja noch den wert von beiden nice z.b. auf max. 19
> setzen.
>
> versuch das bitte nochmal. ich denke, das sollte dann greifen.
>
> gruss martin
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com