Du musst die build-essentials installieren. Ggf. musst du noch weitere Bibliotheken installieren. Das hängt von dem Code ab. Ist das ein öffentliches Projekt? Nach Möglichkeit gibt es vielleicht binaries (apt-cache search ...). Ansonsten schau mal, ob du eine README oder INSTALL Datei findest. Dort sollten die Abhängigkeiten beschrieben sein. Wenn du Glück hast, dann gibt es ein configure-Skript oder zumindest eine Makefile. Im Normalfall läuft das ganze so ab
tar xzf projekt.tar.gz # entpacken des projekts
cd projekt # in das Verzeichnis wechseln
./configure # Abhängigkeiten suchen, konfigurieren, Makefiles erzeugen
make # Kompilieren
sudo make install # Installieren
Irgendwie hab ich bis jetzt nie im Detail darüber nachgedacht. Ich hab kurz zwei Artikel quer gelesen, jetzt ist mir das auch klar. In jedem Fall, vielen Dank für die Hilfe.
Wenn du keine Schreibrechte auf das übergeordnete Verzeichnis hast, dann musst du der Benutzer sein, der welche hat um ein Unterverzeichnis erstellen zu können. Und in der "Verzeichnis-Wurzel" muss man 'glaub immer root sein.
Hi zusammen
Um alle Dienste unserer Applikation sauber via SIGTERM zu beenden und nach einer maximalen Reaktionszeit einen Neustart zu erzwingen, haben wir folgendes Skript erstellt:
#!/bin/sh
export remote='emc-remote'
export harvester='emc-harvester'
export maxWaitTime=90
kill -SIGTERM `ps ax | grep 'emc-remote' | grep -v grep | awk '{print $1}'` 2>/dev/null
kill -SIGTERM `ps ax | grep 'emc-harvester' | grep -v grep | awk '{print $1}'` 2>/dev/null
echo -n 'Awaiting EMC service shutdown...'
secondsPassed=0
while [ $secondsPassed -lt $maxWaitTime ]; do
psOutput=`ps ax`
echo $psOutput | grep ".*$remote" >/dev/null
remotePresent=$?
echo $psOutput | grep ".*$harvester" >/dev/null
harvesterPresent=$?
if [ $remotePresent -eq 1 -a $harvesterPresent -eq 1 ]; then
break
fi
let ++secondsPassed
sleep 1
echo -n '.'
done
echo -e "\n"
reboot
Das Skript an sich funktioniert so weit. Nun kann es allerdings vorkommen, dass der Impuls zum Neustart von einem der zu beendenden Programme aus kommt. Effektiv im Programm sähe das dann so aus:
void ConfigBasedRemoteServer::restartSystem() const {
::system("emc-reboot &");
}
Nun ist es in diesem Fall aber so, dass der aufrufende Prozess stets bis zur maximalen Wartezeit hängen bleibt. Deswegen habe ich das '&' angehängt, um dafür zu sorgen, dass der Prozess nicht auf die Beendigung des Kommandos wartet. Das ist soweit in Ordnung, die Methode läuft sofort durch, aber beendet wird der Prozess durch das SIGTERM-Signal dennoch nicht.
Liegt das an der Eltern-Kind-Beziehung und wie liesse sich das umgehen?
Danke für Ideen und Hinweise!
Beste Grüsse
Kessi
Ethon__ schrieb:
Ja, std::ifstream::read benutzt einen Buffer, den du aber ausschalten kannst, der Sinn davon ist es möglichst selten den Syscall read aufzurufen, da der recht teuer ist.
Der Syscall read buffert nicht garantiert, wird es aber zu 99,99% tun, da es noch viel teurer ist, Daten von der Platte zu laden und man freie I/O-Kapazitäten der Platte auf jeden Fall nutzt.
Platte -> Kernel-Buffer -> read -> ifstream-Buffer -> ifstream::read wäre so die gewöhnliche Reihenfolge, wenn ifstream auf fread aufsetzt, wäre noch ne Bufferschicht dazwischen.
Was open mit der Frage zu tun hat, versteh ich grad nicht ganz.
Wie hast Du die 99,99% ermittelt? Meine Messungen haben 99,973% ergeben.
Ja, so wurde es in DOS implementiert. Das war furchtbar spaßig, wenn man komplexere Batch-Files von Diskette gestartet hatte.
Auf Linux können Pipes aber mehr. Den Schreiber bremsen, wenn der Leser nicht schnell genug ist. Und im RAM bleiben.
Für die, die nicht verstehen, worum es hier geht:
http://en.wikipedia.org/wiki/GNU/Linux_naming_controversy
Linux ist ein Betriebssystemkernel. Ein Betriebssystemkernel kennt sich mit Hardware aus, hat Treiber, verwaltet Speicher, so ein Kram eben. Aber er stellt der Anwendungssoftware bloß eine abstrahierte Schnittstelle für die Hardware zur Verfügung, ein Anwender kann mit dem Kernel alleine herzlich wenig machen.
GNU (GNU is not Unix) ist, trotz des Namens, die wohl bedeutendste Implementierung des Unix-Betriebssystems. Das ist das, was man als Anwender tatsächlich sieht: Die Konsole, die ganzen Tools, der GCC und auch die ganze Oberfläche GNOME gehören dazu. GNU selber hat aber keine Ahnung von Hardware, es braucht irgendeinen unterliegenden Kernel, um überhaupt zu laufen.
Und die Kombination GNU mit Linux als Kernel ist das, was hier im Thread (und überhaupt umgangssprachlich) als Linux bekannt ist.
(Es gibt auch einen eigenen Betriebssystemkernel von GNU, GNU Hurd. Aber dessen Entwicklungsgeschichte lese man selber nach, falls man noch nie davon gehört hat. Ist eine interessant Geschichte von Fehlschlägen.)
Hmm. Scheint nichts zu ändern. Würde es vllt helfen, wenn man anstatt forkpty, selber ein pty über open öffnet und dann forked...? Könnte mir da jemand helfen einen Code zusammen zu basteln?
Fabulus schrieb:
Ja, lsof ist mir bekannt. Gibt es denn so eine Funktion auch in C, die quasi das gleiche macht?
Laut strace geht lsof den manuellen Weg, indem es /proc von vorne bis hinten durchsucht. Wenn es einen eleganteren Weg geben würde, würde lsof den wahrscheinlich verwenden.
So,
ich melde mich mal wieder. Nun ich habe fast die selbe Ausgangsstellung.
Nun steht mir X aber nicht mehr zur Verfügung. Ich starte also
Pragramm 1 in tty1 und irdgendwann soll durch ein Befehl Prgramm 2 in tty2 ausgeführt werden.
Das einzig brauchbare aus der Googlesuche ist folgender Befehl:
programm &>/dev/tty2 </dev/tty2
Leider sieht man dabei nicht mehr die Ausgabe von Prgramm1 und ich muss mich erst auf den verschiedenen ttyx anmelden.
Gruß
Juri
d_reclen gibt nicht die Länge des Namens an, sondern (siehe man: readdir(3)) "length of this record". Also die Länge des gesamten dirent-Eintrags. Die Länge des Namens bekommst du mit strlen bzw. dem Macro _D_EXACT_NAMLEN.
PS. S_Pfad und I_Hilfe sind aber sehr merkwürdige Variablennamen
exec* überschreibt den aktuellen Prozess mit einem neuen Prozess. Wie Bashar bereits gesagt hast, musst du daher vorher einen neuen Prozess anlegen. Das geht mit man: fork bzw. man: vfork.
pid_t pid = vfork();
if(pid == -1) {
perror("vfork");
return 1;
}
else if(pid == 0) { // Neuer Prozess
if(execlp(...) == -1) {
perror("execlp");
}
_exit(1);
}
else {
int status;
if(waitpid(pid, &status, 0) == -1) {
perror("waitpid");
return 1;
}
if(WEXITSTATUS(status) != 0) { // Prozess hat mit einem Fehler beendet.
// ...
}
}
