nullpointer.at Entwicklung, Fotografie und mehr

22Apr/121

Mit Bash prüfen ob das eigene Script gerade läuft

Verfasst von

Die Problemstellung

Ein Script soll alle x Minuten laufen und eine bestimmte Tätigkeit auf dem Server ausführen.

Nun kann es vorkommen, dass das Script aber länger braucht als die Zeitspanne bis zum nächsten Aufruf desselben Scripts (z.B. Kopier und Backup Jobs, Mails abholen, ...)

Natürlich sollte so ein Script dann nicht ein 2tes Mal gestartet werden sondern die Ausführung übersprungen werden. Zu diesem Zweck möchte ich hier ein kleines Bash Script zeigen, das genau diesen Zweck erfüllt.

Die Lösung

#!/bin/bash
#
# testpid.sh - demo script to show how to check if a script
# with the same name is currently running
#
# by Leo Eibler
# resources:
#    http://www.eibler.at
#    http://leo.sprossenwanne.at
#    http://www.nullpointer.at
#

# PID - pid of the current script
PID=$$
# SCRIPTNAME - current name of the script without directory prefix
SCRIPTNAME=`basename $0`
# PIDFILE - where to write the current pid
PIDFILE=/tmp/$SCRIPTNAME.pid

# ENDEXECUTION - if 1 then stop script, if 0 everything is ok and continue
ENDEXECUTION=0

if [ -f "$PIDFILE" ]
then
    RUNNINGPID=`cat "$PIDFILE"`
    echo "got pid from $RUNNINGPID from pidfile '$PIDFILE'"
    PROGRAMPID=`ps -e | grep "$SCRIPTNAME" | grep -v grep | awk '{print $1;}'`
    for PIDEL in $PROGRAMPID
    do
        echo "testing pid of running scripts '$PIDEL' == '$RUNNINGPID' from pidfile"
        if [ "$PIDEL" == "$RUNNINGPID" ]
        then
            echo "found PID $RUNNINGPID current running - end execution"
            ENDEXECUTION=1
            break
        fi
    done
fi

if [ "$ENDEXECUTION" == "1" ]
then
    echo "Current script '$SCRIPTNAME' already running (pid $RUNNINGPID) - end execution"
    exit 1
fi
# writing PID to pidfile
echo $PID > $PIDFILE

#
# ---- START ----
#

echo "do your stuff here ..."
sleep 5
echo "... end script"

#
# ---- END ----
#

# delete pidfile
rm $PIDFILE
exit 0

Die Erklärung

Zuerst holt sich das Script den eigenen Namen mit basename $0 ($0 würde ebenfalls den Pfad des Scriptaufrufs enthalten aber hier würde der spätere Aufruf von ps bzw. das automatische Erstellen und Auslesen des passenden pid-Files scheitern).

Mit dem Namen des Scripts wird dann versucht ein pid-File (welches die Process-ID des aktuell laufenden Scripts enthält) auszulesen. Der Pfad des pid-Files kann beliebig gewählt werden, jedoch muss das Script natürlich Schreibrechte auf die Datei besitzen.

Falls kein pid-File existiert kann das Script davon ausgehen, dass es derzeit nicht bereits läuft und seine eigentliche Arbeit aufnehmen.

Falls jedoch ein pid-File vorhanden ist, wird dieses ausgelesen und mit allen derzeit laufenden Process-IDs von Prozessen mit dem gleichen Namen wie das Script verglichen.

Wird hierbei eine Übereinstimmung gefunden, dann läuft das Script bereits und durch Setzen der Variable $ENDEXECUTION auf 1 wird der Abbruch signalisiert.

Dieser Vergleich mit den Process-IDs von Prozessen die bereits laufen ist deswegen wichtig, da es ja sein könnte, dass das Script beim vorherigen Aufruf zwar ein pid-File angelegt hat, aber danach abgebrochen wurde (z.B. manuell durch den Benutzer) und das pid-File dadurch nicht gelöscht wurde.

Ist die Überprüfung auf eine laufende Instanz negativ, muss zuerst das pid-File angelegt werden (Die Variable $$ enthält die pid des aktuellen Prozesses).

Nach Beendigung der Arbeit sollte danach das pid-File wieder gelöscht werden um einen sauberen Abschluss zu bilden.

Das Script als Download gibts hier.

 

Leo Eibler

Ing. Leo Eibler arbeitet hauptberuflich im Bereich IT Service Management doch es verschlägt ihn immer wieder zurück zur Technik. Programmieren, Hardware (Mikrocontroller) und Musik sind seine Hobbies.

More Posts - Website

Ähnliche Artikel:

8Apr/120

Mehrsprachigkeit WordPress Plugins

Verfasst von

Aus aktuellem Anlass (Erstellung meines ersten WordPress Plugins GarageSale) habe ich mich auch mit dem Thema Multilingualität und Übersetzungen auseinandergesetzt (Jetzt weiß ich auch woher I18N kommt - 18 Buchstaben zwischen i und n im Wort internationalization ;-)

Grundsätzlich muss die zu übersetzende WordPress Komponente natürlich die Funktionen __("text","domain") oder _e("text","domain") verwenden. Siehe hierzu I18N for WordPress Developers.

WordPress stellt für die Übersetzung einige Werkzeuge auf dem Subversion Host bereit. Aber zunächst einmal ein Schritt nach dem Anderen.

Schritt 1 - Download der Tools für Windows

Da ich auf den Clients Windows einsetze habe ich mich dazu entschlossen auch die Entwicklungswerkzeuge für Windows (in meinem Fall noch das gute alte Windows XP aber es sollte keinen Unterschied machen) einzusetzen  und zu beschreiben.

Wir beginnen also mit dem Download von folgenden Komponenten:

Und danach installieren wird zunächst einmal alle 4 Programme mit dem Windows Installer.

Schritt 2 - gettext und php einrichten

Damit die Gettext Werkzeuge funktionieren sollten Sie noch zum Windows Pfad hinzugefügt werden. Dies kann man entwededer dauerhaft machen unter Systemsteuerung -> System -> Erweitert -> Umgebungsvariablen oder aber direkt vor dem Aufruf des Übersetzungswerkzeugs in der Commandshell.

Ich habe gettext einfach in das Standardverzeichnis c:\Programme\GnuWin32 installiert. Da die Utilities im Unterverzeichnis bin liegen muss also der vollständige bin Pfad hinzugefügt werden:

c:\Programme\GnuWin32\bin

Wie gesagt die Alternative lautet, direkt vor dem Aufruf der Übersetzungstools den Pfad in der Commandline mittels set PATH=%PATH%;c:\Programme\GnuWin32\bin hinzufügen.

Analog zu gettext wird dies mit PHP gemacht. Also falls php in das Standard-Verzeichnis c:\Programme\php installiert wird, dann muss dieses ebenfalls zur Umgebungsvariable Path hinzugefügt werden.

Schritt 3 - Entwicklerwerkzeuge von WordPress aus SVN holen

Um mit der Übersetzung zu beginnen benötigt man jetzt die Entwicklerwerkzeuge von WordPress. Diese holt man sich mittels Subversion (in unserem Fall komfortabel mit dem Tool tortoiseSVN) von der Adresse http://i18n.svn.wordpress.org/tools/trunk

Hierzu erstellt man am Besten ein leeres Verzeichnis (z.B. c:\Work\wp-i18n\) und dort drückt man die rechte Maustaste und wählt SVN Checkout. Im darauffolgendem Tortoise Fenster gibt man unter URL of repository http://i18n.svn.wordpress.org/tools/trunk und drückt auf OK.

Schritt 4 - WP i18n tool starten

Nach dem Checkout befinden sich jetzt die WordPress i18n Übersetzungs Tools im Verzeichnis c:\Work\wp-i18n. Wir öffnen nun ein Commandline Fenster und wechseln in diesen Ordner (wichtig, falls oben in Schritt 2 die Methode mit der dauerhaften Pfad Anpassung gewählt wurde, darf ein jetzt bereits schon offenes Commandline Fenster nicht weiterverwendet werden, da sich die Umgebungsvariablen Änderung nicht auf bereits geöffnete Fenster auswirkt!

Eine Eingabe des Kommandos xgettext sollte nun eine Informationszeile auswerfen ebenso wie eine Eingabe des Befehlst php -v. Falls dies nicht funktioniert, nochmal zurück zu Schritt 2 und prüfen ob die Pfade auch wirklich korrekt gesetzt wurden.

Nun kann die Übersetzung eines Plugins gestartet werden. Zu diesem Zweck muss folgendes Kommando ausgeführt werden: php makepot.php wp-plugin <Pfad des WordPress Plugins>

wp-plugin steht hierfür für den Typ des zu übersetzenden Objekts (in diesem Fall ein WordPress Plugin).

In diesem Beispiel übersetze ich mein eigenes Plugin welches sich im Pfad y:\ktzv-fischamend.at\www\wp-content\plugins\garagesale befindet.

Nach dem Fehlerfreien Durchlauf des makepot.php Scripts (zu erkennen an keiner Ausgabe) befindet sich nun eine pot Datei mit dem Namen des Plugins im aktuellen Verzeichnis (in diesem Beispiel garagesale.pot).

Schritt 5 - Mit POEdit die POT Sprach Datei editieren

Nun starten wir das Programm POEdit und öffnen die pot Datei. Um sie zu öffnen muss der Dateityp Filter auf *.* gestellt werden.

Nach dem Laden der pot Datei kann sofort mit dem Übersetzen begonnen werden. In der linken Spalte sind immer die Original (englischen) Begriffe zu sehen und in der rechten Spalte die bereits übersetzten (deutschen) Begriffe. Man wählt einfach den zu übersetzenden Begriff aus und tippt die Übersetzung in das unterste der Eingabefelder.

Vor dem Speichern sollten jetzt noch die Katalog Optionen angepasst werden. Diese finden sich unter dem Menüpunkt Katalog -> Optionen. Wird auf Deutsch übersetzt sollte nicht nur bei Sprache "German" sondern auch bei Land "GERMANY" ausgewählt werden (der Ländercode für Deutsch lautet nämlich üblicherweise de_de und nicht de_at, weil man übersetzt üblicherweise nicht extra ins Österreichische - obwohl das sicher witzig wäre ;-)

Nach dem Speichern findet sich dann zusätzlich zur geänderten Quellsprachdatei garagesale.pot (die jetzt auch die deutschen Übersetzungen enthält) eine Datei namens garagesale.mo. Dies ist die Datei, die für WordPress notwendig ist um das Plugin dann in der korrekten Sprache anzuzeigen.

Wie in dem Screenshot zu sehen, muss diese .mo Datei mit dem richtigen Namen in das Plugin Verzeichnis kopiert werden: <PluginName>-<Länder-und-Sprach-Code>.mo (in diesem Beispiel garagesale-de_DE.mo).

Schritt 6 - Hinzugekommene Begriffe und erneute Übersetzung

Wie das so ist, kommt man nach der fertigen Übersetzung drauf, dass man doch noch eine Funktionalität vergessen hat. Zu diesem Zweck muss man natürlich nochmals das makepot.php Script aus Schritt 4 starten. ABER VORSICHT!

Vor dem erneuten Start muss unbedingt die bereits übersetzte .pot Datei umbenannt werden in z.B. garagesale-translated.pot - Das Extraktionsscript überschreibt kommentarlos eine eventuell bereits bestehende <pluginname>.pot Datei!

Nach erneuter Erstellung der garagesale.pot Datei (in der sich nun auch die zusätzlichen, noch nicht übersetzten Begriffe befinden, können nun mit dem gettext Tool msgmerge die beiden .pot Dateien gemerget werden:

msgmerge -N [bereits-übersetzte-pot-Datei.pot] [neu-generierte-pot-datei.pot] > neue-Pot-Datei.pot

Nun befindet sich im aktuellen Verzeichnis eine Datei namens garagesale_new.pot die wieder mit POEdit um die zusätzliche Begriffe ergänzt werden kann und anschließend muss wieder die .mo Datei entsprechend der oben genannten Namenskonvention in das Plugin Verzeichnis kopiert werden.

 

 

Leo Eibler

Ing. Leo Eibler arbeitet hauptberuflich im Bereich IT Service Management doch es verschlägt ihn immer wieder zurück zur Technik. Programmieren, Hardware (Mikrocontroller) und Musik sind seine Hobbies.

More Posts - Website

Ähnliche Artikel:

1Apr/120

Java 7 Compiler in Maven

Verfasst von

Lang ist’s her dass ich hier was technisches gebracht hab. Die Fotographie und einige private Dinge haben mich davon ab gehalten. Doch die Zeit der dürre ist vorbei, ich hab wieder begonnen meine Erfahrungen für den Blog festzuhalten :D

Möchte man Java 7 in einem Maven Projekt verwenden muss man dem Maven Compiler Plugin das auch mitteilen. Dieses würde atm. ansonsten versuchen das Projekt mit gutem alten Java 5 zu bauen.

Dazu muss das Plugin über folgende Angaben in der pom.xml umkonfiguriert werden:

<build>
    
    <plugins>
        
        <plugin>
            <groupid>org.apache.maven.plugins</groupid>
            <artifactid>maven-compiler-plugin</artifactid>
            <configuration>
                <source>1.7</source>
                <target>1.7</target>
                <showdeprecation>true</showdeprecation>
                <showwarnings>true</showwarnings>
                <executable>${env.JAVA_7_HOME}/bin/javac</executable>
                <fork>true</fork>
            </configuration>
        </plugin>
    </plugins>
</build>

Natürlich muss der Entwickler dafür die Umgebugnsvariable JAVA_7_HOME auf den Rootordner des JDKs der Version 7 linken.

Weitere Infos gibts auf der Seite des Maven Compiler Plugin. Unter Examples gibt es auch den Punkt “Compile Using A Different JDK” der die Vorgehenswiese dabei analog beschreibt. Dabei wird auch eine Möglichkeit aufgezeigt wie der Entwickler den Path JAVA_7_HOME in seiner Maven settings setzen kann.

Have Fun mit Java 7

Thomas Pummer

Thomas Pummer ist Softwareentwickler an der Universität Wien. In seiner Freizeit betreut er das Open Source Projekt TrayRSS und werkt an diversen anderen kleinen Projekten. Er ist sehr interessiert an Open Source und Webentwicklung und testet gern neue Programmiersprachen.

More Posts - Website

Follow Me:
TwitterGoogle PlusFlickr

Ähnliche Artikel:

20Dez/110

Android Entwickeln: Emulatorprobleme unknown option: -

Verfasst von

Startet man zwecks Debugging für Android den arm Emulator über Eclipse, oder direkt aus dem AVD Manager kann es zu folgender Fehlermeldung kommen:

"unknown option: - please use -help for a list of valid options"

Dieser Fehler tritt auf wenn der SDK-Manager unter einem Pfad installiert wurde, der Leerzeichen enthält zB "C:\Program Files (x86)\sdk-manager". Über die Kommandozeile startet der Emulator dennoch:

"C:\Program Files (x86)\sdk-manager\tools\emulator.exe -avd <emulatorname>"

Möchte man den Aufruf also nicht immer per Konsole starten, wäre ein verschieben der SDK-Manager Installation in ein Verzeichnis ohne Leerzeichen empfohlen.

Happy androiding!

Thomas Pummer

Thomas Pummer ist Softwareentwickler an der Universität Wien. In seiner Freizeit betreut er das Open Source Projekt TrayRSS und werkt an diversen anderen kleinen Projekten. Er ist sehr interessiert an Open Source und Webentwicklung und testet gern neue Programmiersprachen.

More Posts - Website

Follow Me:
TwitterGoogle PlusFlickr

Ähnliche Artikel:

19Dez/110

Android Entwickeln – Debug certificate expired

Verfasst von

Am Wochenende wars soweit, ich wollte endlich mal wieder für mein Smartphone programmieren und meine Kenntnisse mit einem erneuten "Hello Android!" auffrischen. Kaum starte ich meine nun seit gut einem Jahr angestaubte Eclipse IDE springt mir auch schon eine Fehlermeldung unter Problems entgegen:

Error generating final archive: Debug Certificate expired on 13.09.11 17:43

Das hier angesprochene Zertifikat war ganze 365 Tage gültig, und kann als solches nicht verlängert werden. Als Lösung muss man sich ein Neues erzeugen lassen. Dazu im Home Verzeichnis im Unterordner .android die Datei debug.keystore löschen und danach im Eclipse unter Project -> Clean... die Projekte bereinigen und neu bauen lassen.

Happy Android Debugging - die nächsten 365 Tage ;)

Thomas Pummer

Thomas Pummer ist Softwareentwickler an der Universität Wien. In seiner Freizeit betreut er das Open Source Projekt TrayRSS und werkt an diversen anderen kleinen Projekten. Er ist sehr interessiert an Open Source und Webentwicklung und testet gern neue Programmiersprachen.

More Posts - Website

Follow Me:
TwitterGoogle PlusFlickr

Ähnliche Artikel: