Anzeige:
Ergebnis 1 bis 12 von 12

Thema: execl() kombination aus script und binary - wie am Besten?

  1. #1
    Registrierter Benutzer
    Registriert seit
    Sep 2000
    Beiträge
    86

    execl() kombination aus script und binary - wie am Besten?

    Hallo,

    ich bin in einem c-programm, habe ein child ge-forked.
    Dieses soll ein paar kleinere (typische script) aufgaben erledigen, u.a. den kompilierprozess eines c-codes ausführen
    anschließend das resultierende binary starten.

    Bisher habe ich das in 3 Schritten gemacht:
    1) fork
    2) über meherere systm() aufrufe die scriptaufgaben erledigt (also z.B. den Kompilierprozess gestartet)
    3) nachdem das auszuführende binary in 2) gebaut wurde mache ich execl um das binary auszuführen

    Mein Problem: system() forked ein weiteres kind (also ein kind-kind). Ich brauche die CPU/Speicherlast aber sozusagen auf dem Kindprozess (weil ich den monitore).

    -> system vermeiden und direkt 2) und 3) als ein execl ausführen wäre eine Lösung.
    Ich könnte ein shellscript schreiben welches 2) erledigt und dann das binary startet und dieses dann per execl ausführen
    execl("/bin/sh", "sh", "/path/to/my/script.sh", (char *) NULL);

    Ich frage mich ob das einen extra overhead erzeugt? Welche shell sollte man dafür verwenden? Da ich eine vielzahl solcher binaries starte wäre es wichtig daß der footprint (mem und cpu) vergleichbar zur ursprünglichen Lösung bleibt.


    Danke!
    Alexander

  2. #2
    Registrierter Benutzer
    Registriert seit
    Apr 2009
    Ort
    Erde
    Beiträge
    2.814
    Was kommt nach 3 bzw was willst du eigentlich genau machen (oder wenigstens genauer) - die Unterschiede zwischen system, fork und exec sind dir klar oder?
    Gruß nopes
    (,,,)---(^.^)---(,,,) /var/log/messages | grep cat

  3. #3
    Registrierter Benutzer
    Registriert seit
    Sep 2000
    Beiträge
    86
    Ja, die unterschiede sind mir klar:
    kurz gesagt:
    fork macht eine kopie der ursprünglichen umgebung
    system macht etwa: fork, execl, wait
    und execl ersetzt die ursprünliche umgebungskopie durch die eine neue für das auszuführende programm.

    ich habe einen parent. der soll mehrere kinder starten. diese kompilieren ihren code und führen das binary dann aus.

    meine frage ist eigentlich: wenn ich statt execl(path,binary) execl(path, shellscript) und im shellscript dann ./binary ausführe -> habe ich dann nennenswert overhead?

  4. #4
    Registrierter Benutzer
    Registriert seit
    Sep 2000
    Beiträge
    86
    vielleicht doch nochmal genauer:
    ich habe einen master-Prozeß sagen wir mit 'PID-master'.
    Dieser soll kinder starten, welche ihren code kompilieren und das resultierende binary dann ausführen.
    Dabei sollen keine kindeskinder entstehen.

    Hätte ich alle binaries, würde ich im master einen fork und dann execl(binary_x) ausführen.
    Der Master kenn die PID des children und ich kann im master code alos z.B. cpu usage des kindes ermitteln.

    Bei meiner bisherigen Lösung (mit system zwischenschritt) läuft der compile-schritt in einem kindeskind (das system intern forked).
    Wenn system zurückkehrt wird per execl das binary gestartet und ab da ist alles ok.

    Kann ich den compile und ausführungsschritt des kindes in ein execl zusammenfassn?
    Oder forked die per execl aufgerufene shell sowieso auch wieder um das im shell-script aufgerufene binary auszuführen???

  5. #5
    Registrierter Benutzer
    Registriert seit
    Apr 2009
    Ort
    Erde
    Beiträge
    2.814
    Ok nicht ganz was ich meinte, ich meinte:
    https://www.gnu.org/software/libc/ma...mono/libc.html - 26.1 Running a Command - was ich da meine:
    ...
    This function executes command as a shell command. In the GNU C Library, it always uses the default shell sh to run the command.
    ...
    vs 26.5 Executing a File - für execv bzw execl:
    ...
    This section describes the exec family of functions, for executing a file as a process image. You can use these functions to make a child process execute a new program after it has been forked.
    ...
    This is similar to execv, but the argv strings are specified individually instead of as an array. A null pointer must be passed as the last such argument.
    ...
    Die system Funktion ist also teurer als eine der exec Funktionen, weil dabei auch _immer_ "sh" ausgeführt wird. Die schlankste Variante ist also
    1) fork
    2) execX - für den "build", vermutlich was in der art "make x build" oder so
    3) parent wartet auf das "ende von fork"
    4) fork
    5) execX - für das vorher gebaute
    Dabei kannst du theoretisch einige Aufrufe von "sh" einsparen und wenn du scharf nachdenkst wirst du auch bemerken, dass das alles nicht viel bringt, wenn du zum bauen ein Shell Skript ansprichst (weil der ja das ausführen "sh" impliziert), da müsstest du halt direkt auf make, gcc oder sowas runter.

    Hoffe das hilft
    Geändert von nopes (04.01.17 um 20:26 Uhr)
    Gruß nopes
    (,,,)---(^.^)---(,,,) /var/log/messages | grep cat

  6. #6
    Registrierter Benutzer
    Registriert seit
    Sep 2000
    Beiträge
    86
    Danke für die Infos.
    Bei Deiner Variante muß der master halt n x forken, d.h. n verschiedene child-pids nacheinander 'beobachten'.
    Die befehle sind direkt gcc aufrufe zum kompilieren und linken, also keine makefiles oder sowas.
    Mehrere aufrufe z.b. von gcc (um verschieden objekte zu bauen und dann abschließend zu linken) bekomme ich also wohl einfach nicht in einen child prozess.

    Ist vielleicht die sauberste variante jeden aufruf einzeln als fork/exec machen und zu 'beobachten'

    Danke!
    Alex

  7. #7
    Registrierter Benutzer
    Registriert seit
    Apr 2009
    Ort
    Erde
    Beiträge
    2.814
    Ich denke makefiles kannst du schon verwenden, ist halt nicht so zielführend, wenn man sagt, ich optimiere "sh" Aufrufe weg und dann am Ende doch wieder Skripte bzw. Programme aufruft, die ein Ausführen von "sh" benötigen. Ich sag mal so, fork+exec "sind etwas näher am Blech" als system.

    Aber Linux ist ja ein freies System, aus der Doku: The easy way to run another program is to use the system function - gibt also auch andere Wege (eigene system Funktion oder eigenes "sh" oder oder ) - wie du aber ja schon bemerkt hast, bedeutet es halt mehr Arbeit für einen selbst - logisch, man ist ja auch nicht mehr auf dem einfachen Weg unterwegs
    Gruß nopes
    (,,,)---(^.^)---(,,,) /var/log/messages | grep cat

  8. #8
    Registrierter Benutzer
    Registriert seit
    Sep 2000
    Beiträge
    86
    Hmm,
    aber wenn ichs richtig verstanden habe führt fork, execl(sh,shellscript) (erstest Kind) intern auch wieder zu einem fork (zweite ebene) - oder habe ich das falsch verstanden?
    bsp:
    #/bin/sh
    gcc -Wall hello.c -o hello.bin
    ./hello.bin

    wenn ein hauptprogramm fork(child1-pid), execl(sh dieses shellcript) aufruft - läuft dann nur ein kindprozess unter child1-pid, oder startet die shell für gcc bzw ./hello.bin weitere prozesse (deren footprint dann ja nicht mehr im child1-pid beitragen)?
    Gruß
    Alex

  9. #9
    Elefantenversteher Avatar von florian0285
    Registriert seit
    Jun 2016
    Beiträge
    1.054
    Auch wenn das erledigt zu sein scheint. Etwas Code wäre interessant. Der Grund deiner Prozessorgie ist auch nicht so verständlich [emoji12]

    Mein C ist etwas altbacken und eingerostet, aber wenn ich das in java machen würde denke ich sofort an threads und nicht an betriebssystem prozesse.

    So gesehen bin ich auch nur neugierig welches programm jenseits von malware sich selbst kompilieren muss. [emoji51]

    Also falls du das näher beschreiben willst und/oder code veröffentlichen möchtest... sonst schweigen sie bitte für immer [emoji12]
    Matthäus 7:3 Was siehst du aber den Splitter in deines Bruders Auge, und wirst nicht gewahr des Balkens in deinem Auge?

  10. #10
    Registrierter Benutzer
    Registriert seit
    Apr 2009
    Ort
    Erde
    Beiträge
    2.814
    Ob Prozess oder Thread macht nicht so viel Unterschied, aber ja Threads sind ein klein bisschen billiger, dafür viel anstrengender im weiteren Verlauf, ein komplett eigenes App-Image für ein Thread ist afaik nicht so ohne weiteres möglich - http://stackoverflow.com/questions/8...esses-in-linux

    Ich würde erwarten, dass du dabei im Vergleich zu system nichts sparst (weil "sh" so oder so ausgeführt wird wenn ich mal unterstelle das zeile 1 eigentlich shebang sein sollte) und das hello.bin ein Kindprozess ist, du kannst das aber auch einfach probieren, system entspricht sh -c zum nachstellen reich sowas:
    Code:
    sh -c foo # wobei foo dein skript ist
    top, htop, pstree, ps oder sowas daneben und du kannst beobachten was passiert.
    Gruß nopes
    (,,,)---(^.^)---(,,,) /var/log/messages | grep cat

  11. #11
    Elefantenversteher Avatar von florian0285
    Registriert seit
    Jun 2016
    Beiträge
    1.054
    Joa wie gesagt mein C ist altbacken und eingerostet. Ein Java Thread ist da nämlich viel günstiger als ein neuer Prozess.

    Was ich bei ihm aber raus lese sind "viele" Prozesse? Kleinvieh macht auch misst [emoji12] und die Neugierde was er denn vor hat gibts auch noch [emoji51]

    Edit: was mir im Nachgang dazu dann noch einfällt ist, dass der Prozess vermutlich mehr "Overhead" erzeugt als vermutet. Immerhin benötigt er ja die Kompilier-Komponente nur ein einziges mal je Child und durch den fork würde dieser ganze Balast in den neuen Prozess mitgeschleppt. Das betrifft grundsätzlich den Gedanken den ganzen Parent-Prozess zu forken.
    Geändert von florian0285 (05.01.17 um 13:35 Uhr)
    Matthäus 7:3 Was siehst du aber den Splitter in deines Bruders Auge, und wirst nicht gewahr des Balkens in deinem Auge?

  12. #12
    Registrierter Benutzer
    Registriert seit
    Sep 2000
    Beiträge
    86
    Nix Malware. Multiagentensimulation. Jeder Agent braucht seinen Prozess, ich muß aber die Aufwände (inklusive kompilieraufwand) vom Hauptprozess, der alle Agenten startet ermitteln können.
    Grüße
    Alexander

Ähnliche Themen

  1. Script -> Binary neustart
    Von nr8 im Forum Linux Allgemein
    Antworten: 12
    Letzter Beitrag: 06.05.08, 09:45
  2. Bash-Script --- Binary ausführen
    Von Bronks im Forum Linux Allgemein
    Antworten: 4
    Letzter Beitrag: 17.11.06, 07:56
  3. Wo / Wie bindet man am besten -iptables-Script ein ?
    Von xxandyxx im Forum Sicherheit
    Antworten: 2
    Letzter Beitrag: 23.03.03, 20:37
  4. Antworten: 5
    Letzter Beitrag: 29.11.02, 22:40
  5. vi zu execl
    Von joey.brunner im Forum Anwendungen Allgemein, Software
    Antworten: 16
    Letzter Beitrag: 08.11.02, 12:55

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •