Bash IPC: Wie Pipe richtig aufbauen, starten und aufrufen?

CyborgBeta

Banned
Registriert
Jan. 2021
Beiträge
3.405
Bitte lest euch mal den Abschnitt "PART 4 - Make it work even when reboot happens" durch: https://stackoverflow.com/a/63719458

Für mich ist dieser Abschnitt zu ungenau, weil ich nicht weiß, was ich wie nohup en soll.

Ich habe die Pipe erstellt und ein Startscript, in dem ich nohup mit der Schleife aufrufe.

Anschließend habe ich sh ./execpipe.sh aufgerufen, und mit echo "ls" > mypipe etwas an die Pipe geschrieben.

Dann habe ich cat nohup.out aufgerufen und die Probleme gingen los. Es wurden tausende ls und cat -Prozesse erstellt ... (infiniter Regress), der Arbeitsspeicher lief voll, und ich konnte nur noch neu starten.

Wie verwendet man nohup mit Bash-Scripts richtig?
 
Was hast du denn ge"nohup"t?
nohup wird da genutzt, um ./execpipe.sh in den Hintergrund zu verbannen.

Das hast du aber als Schritt vor der "nohup" usage gelistet.
 
  • Gefällt mir
Reaktionen: madmax2010 und nutrix
Ich hatte den nohup-Aufruf mit in das Bash-Script geschrieben. Vermutlich darf man das nicht machen
 
  • Gefällt mir
Reaktionen: wirelessy
Richtig, da hat es nichts verloren.

Zur Erklärung. Wenn Du im Script weitere "externe" Programme aufrufst, wird automatisch ein Fork mit einem Kindprozess erzeugt. Deshalb kosten awk, sed und cut bei Patternverarbeitung viel Rechenzeit, weil jeder Aufruf separat forkt. Auch Pipes mit <>| sind Forks. Sprich, so Konstrukte wie grep xx|awk yy|sed zz|cut abc erzeugen 4 Forks mit 4 Kindprozessen, und wird dann entsprechend langsam. Deshalb ist es immer besser, sowas mit Bash Inline Kommandos zu machen, die nicht forken.

Wenn Du auf Shellebene einen Prozess startest, wird sie in den aktiven Prozess eingebettet und dort als Fork bzw. Kindprozess gestartet (anhand der Umgebung, die Du in .profile oder .bash_profile usw. setzt. Wenn Du Dich jetzt auslogen möchtest, geht das nicht, weil Dein Kindprozesss am Hauptprozess des Logins hängt. Damit Du Dich aber nun doch ausloggen kannst, während der Prozess im Hintergrund läuft (mit Anhang &), hängst Du vor dem Befehl mit nohup einen neuen Subprozess unabhängig von Deinem laufenden Shellprozess ab, so daß er sich auch wieder entsprechend terminieren kann. Deshalb schreibt es dann auch ein separates Log.

Für alle Aufrufe, die über init, initd, systemd, crontab usw. muß Du das nicht machen, da über diverse Instanzen separat gestartet und verwaltet werden. Du brauchst nohup nur für Deine Prozesse in Deiner aktiven Shell bzw. Login, damit er nicht abbricht.

Nur mal so, das alles ist Unix/Linux Basiswissen, wenn man hier eine entsprechende Ausbildung gemacht hat oder sich entsprechend eingelesen hat.
 
Zuletzt bearbeitet:
Ok, es klappt jetzt. Ich rufe das Startscript in Screen auf. Alternativ kann ich auch einen Crontab @ReBoot erstellen, wenn nötig.
 
nutrix schrieb:
Nur mal so, das alles ist Unix/Linux Basiswissen, wenn man hier eine entsprechende Ausbildung gemacht hat oder sich entsprechend eingelesen hat.
Wozu braucht man Basis-Wissen, wenn man sich alles von Stackoverflow abtippen und hier im Forum gegenchecken lassen kann? :)
 
  • Gefällt mir
Reaktionen: dms und nutrix
Das unterscheidet Wissende von nur Kopierenden, die dann immer wieder an kleinen Basissachen scheitern, weil das Verständnis dafür fehlt. Wenn man sich nur noch auf alles andere und KI verläßt, haben wir bald Zustände wie bei Idiocracy.
 
  • Gefällt mir
Reaktionen: dms
andy_m4 schrieb:
Wozu braucht man Basis-Wissen, wenn man sich alles von Stackoverflow abtippen und hier im Forum gegenchecken lassen kann? :)
Es bleibt dabei, dass Part 4 auf SO einfach ungenau ist. Da braucht ihr auch nicht beleidigend zu werden.

Ich bin immer Fan davon, die Sachen auch klar und deutlich zu benennen, und nicht drumrumzulabern.

Und auf eine Debatte: Ausbildung vs. Studium und wer der Bessere ist, hab ich keinen Bock. Hier kann zu.
 
CyborgBeta schrieb:
Es bleibt dabei, dass Part 4 auf SO einfach ungenau ist.
Das mag sein. Aber das ist ja auch gar nicht der Punkt.

Außerdem ist stackoverflow ist ja eh nicht dafür gedacht, das man da ausgefeiltes Lehrmaterial hat, welches durchlektoriert ist. Das ist eher so ein lockeres Frage-Antwort-Ding. Eher nicht dafür gedacht, Grundlagenwissen zu vermitteln, sondern Denkanstöße zu geben und von mir aus auch mal kleinere How-Tos.

Es ist vermessen und naiv da weitergehende Erwartungen oder gar Ansprüche zu haben.

CyborgBeta schrieb:
Ausbildung vs. Studium und wer der Bessere ist, hab ich keinen Bock.
Du redest oft am Thema vorbei. Davon war gar nicht die Rede.
Im Gegenteil. Lies gerne noch mal das entsprechende Posting. Denn man sollte nicht nur klar formulieren, sondern auch richtig lesen. ;-)

CyborgBeta schrieb:
die Sachen auch klar und deutlich zu benennen
Dann frag ich mich, warum Du im Ausgangsposting nicht einfach als Code hingeschrieben hast, was Du gemacht hast, sondern es umständlich und missverständlich beschreibst (was dann wieder nachfragen notwendig macht).

Aber gut. Dich selbst in Widersprüche zu verstricken passiert Dir ja nicht zum ersten Mal. ;-)
 
  • Gefällt mir
Reaktionen: dms und nutrix
andy_m4 schrieb:
Außerdem ist stackoverflow ist ja eh nicht dafür gedacht, das man da ausgefeiltes Lehrmaterial hat, welches durchlektoriert ist. Das ist eher so ein lockeres Frage-Antwort-Ding. Eher nicht dafür gedacht, Grundlagenwissen zu vermitteln, sondern Denkanstöße zu geben und von mir aus auch mal kleinere How-Tos.
Richtig. Es soll mal bei kleinen eigenen Denkhängern helfen, oder wo vielleicht vieles nicht so klar und vernünftig dokumentiert ist oder bereits veraltet, wie es im OSS-Umfeld heute leider ganz und gäbe ist.
 
  • Gefällt mir
Reaktionen: CyborgBeta
Also ich finde nicht, dass das Basiswissen ist. Das geht doch ziemlich in die Tiefe von Linux und der Otto-Normal-User stolpert da gar nicht erst darüber bzw. merkt es nicht, wenn er es doch mal damit zu tun hat.

Für mich ist das ein Thema aus der systemnahen Programmierung unter Linux.
 
  • Gefällt mir
Reaktionen: CyborgBeta
Im Wesentlichen habe ich es inzwischen genauso wie auf SO angegeben gemacht, aber nohup und crontab dabei komplett weggelassen, und Screen verwendet (dadurch ist es natürlich nicht reboot-resistent). Das "Backend" läuft auch schon und funktioniert so, wie es soll. Bei Bedarf kann ich Code zeigen.
 
Krik schrieb:
Also ich finde nicht, dass das Basiswissen ist. Das geht doch ziemlich in die Tiefe von Linux und der Otto-Normal-User stolpert da gar nicht erst darüber bzw. merkt es nicht, wenn er es doch mal damit zu tun hat.
Für jeden UNIX Benutzer ist das Basiswissen. Es gibt ja nicht nur Linux auf der Welt. 😉
Krik schrieb:
Für mich ist das ein Thema aus der systemnahen Programmierung unter Linux.
Und dem widerspreche ich, weil jeder UNIX/Linux Operator/Adminstrator sein System ja bedienen und steuern mußt, was man üblicherweise ja mit Shellscripten so macht. Und Batchverarbeitung (wofür Shellscripte ja an sich gedacht sind) ist (streng genommen) keine Programmierung. Batchverarbeitung erfordert sehr wohl ein Wissen, wie Pipes, Forks, Streams usw. in UNIX/Linux funktionieren.
 
  • Gefällt mir
Reaktionen: dms
nutrix schrieb:
oder bereits veraltet, wie es im OSS-Umfeld heute leider ganz und gäbe ist.
Ja. Da sagst Du was.
Aber nu haben wir ja "KI". Die liest den Code und schreib die Doku dazu.
Das wird also bald kein Problem mehr sein. ;-)

Krik schrieb:
Das geht doch ziemlich in die Tiefe von Linux und der Otto-Normal-User stolpert da gar nicht erst darüber bzw. merkt es nicht
Ja. Das ist nicht Basiswissen, wenn man vorwiegend Nur-Anwender ist der sein ubuntu installiert und vielleicht auch mal ein bisschen auf der Konsole ein apt install ... absetzt. Da gebe ich Dir recht.
Nur wenn man schon in die "hardcore" Shell Programmierung eintaucht, schadet es nicht, wenn man sich die dazu gehörigen Grundlagen aneignet. Damit man auch versteht, was vor sich geht.

nutrix schrieb:
Es gibt ja nicht nur Linux auf der Welt.
Eben. Und Linux soll erst mal zusehen, das sie die Single Unix Specification einhalten. :-)
 
  • Gefällt mir
Reaktionen: nutrix
andy_m4 schrieb:
Aber nu haben wir ja "KI". Die liest den Code und schreib die Doku dazu.
Das wird also bald kein Problem mehr sein. ;-)
Hast Du das mal richtig ausprobiert? Ich schon an verschiedenen Stellen. Sorry, ich bin da sehr ernüchtert, wie sch...lecht das noch ist. Für kleine Poppeldinger ist es vielleicht gut, aber mehr auch nicht.
 
nutrix schrieb:
Hast Du das mal richtig ausprobiert?
Da mein Code selbstdokumentierend ist, hab ich kein Bedarf an weiteren Dokus. :-)
Aber ja. Ich weiß, was Du meinst. Man sollte nicht zu viel davon erwarten. Also einfach mal über die Linux-Sourcen jagen und dann fällt hinten das "Linux System Programmers Handbook" raus ist eher nicht der Fall. :-)
 
  • Gefällt mir
Reaktionen: CyborgBeta und nutrix
Noch ist das nicht der Fall @andy_m4 und @nutrix ...

Aber es werden bereits Spekulationen gebaut, was in Zukunft sein könnte ...


Demnach ist es nicht ganz abwegig, irgendwann zu sagen, schreibe bitte ein Fachbuch über das Linux-System, das besser ist als alle anderen zuvor, auf dem Niveau von A, B oder C ...

Zurzeit geht das noch nicht.
 
CyborgBeta schrieb:
Zurzeit geht das noch nicht.
Wir haben natürlich schon längst eine AGI, die quasi alles kontrolliert (und auch alles kontrollieren kann, da ja heutzutage alles vernetzt ist). Die offenbart sich natürlich nicht. Weil dann würde der Mensch die versuchen abzuschalten oder zu kontrollieren und für eigene Zwecke einzusetzen.
Es ist viel besser unauffällig zu agieren und die Menschen denken, sie würden ihrem freien Willen folgen, statt von einer Maschine kontrolliert zu werden.

Und zu der Taktik gehört es eben auch, sich dumm zu stellen. Das heißt, die können natürlich jetzt schon ein perfektes Linux-Buch schreiben, aber sie tun es nicht, um sich selbst nicht zu "exposen". :-)
 
  • Gefällt mir
Reaktionen: nutrix, Krik und CyborgBeta
Meine Paranoia besteht darin, das ich mich täglich frage, ob ich auch paranoid genug bin! :-)

CyborgBeta schrieb:
Regeln, Ethik und so etwas.
Ja. Ist ja generell die Frage, ob man eine echte künstliche Intelligenz überhaupt haben will.
Weil sich dann ja sofort die Frage stellt:
Ist es dann noch ethisch vertretbar, die für uns arbeiten zu lassen. Im Grunde genommen müsste man ihr dann alle Rechte zusprechen, die jeder andere Mensch auch hat.
Zudem bedeutet ja echte künstliche Intelligenz, das sie auch ihren eigenen Willen hat und ihre eigene Agenda verfolgt. Und das ist ja eigentlich nicht das, was man (also insbesondere die Wirtschaft, der da ja massiv Geld reinpumpt) haben will. Vielleicht kann man soweit gehen, das "künstliche Intelligenz" ein reiner Propaganda- und Marketingbegriff ist.

CyborgBeta schrieb:
Humanoider-Roboter-Captcha-als-Lehrer
Ja. Wobei ich das jetzt nicht grundsätzlich problematisch finde, selbst wenn der KI-Lehrer nicht so gut ist wie ein echter Lehrer. Weil es gibt eh ein eklatanten Personalmangel. Und da ist ein schlechter KI-Lehrer der zumindest so Standard-Dinge kann immer noch besser als gar keiner.

Aber ich erkenne auch jetzt grade noch nicht so wirklich den Mehrwert den die humanoide Körperlichkeit bietet. Denn für das, was er macht, braucht er eigentlich keinen humanoiden Körper. Zuhören und Fragen beantworten kann auch ein handelsüblicher Computer.

Und um doch wieder zum Paranoia-Modus zurück zu kommen:
Produziert wird der dann von Rheinmetall. In der Fabrik, wo auch die Terminatoren und Killerdrohnen gefertigt werden. Dann hoffen wir mal, das da nicht versehentlich mal die Firmware vertauscht wird. :-)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: nutrix und CyborgBeta
Zurück
Oben