ERROR - 2x grep auf OpenBSD - Skript local vs. Skript per SSH ausführen

halloICKEbins2

Active Member
Mahlzeit,

ich habe mir ein Skript (/bin/sh) auf meinem OpenBSD-System geschrieben, welche ps aux | grep "begriff1" | grep "begriff2" ausführt. Wenn ich es lokal ausführen, bekomme ich eine Ausgabe mittels echo des Befehls. Führe ich es per SSH mit Python3 remote aus, bekomme ich diese Ausgabe nicht.

Durch Probieren habe ich rausbekommen, dass es an dem doppelten grep-Befehl liegt - bei einem grep funktioniert alles wunderbar.


Jetzt zur Frage: Woran liegt das und gibt es eine Möglichkeit mit mehreren greps hintereinander zu arbeiten?

PS: Hat jemand eine gute Anleitung der Expressions von grep mit Beispielen - als Alternative zu den mehreren greps?
 
Hi,

mir ist gerade überhaupt nicht klar was ssh mit python3 hier zu tun hat.

Bist du sicher das du sh und nicht ksh o.ä. nutzen möchtest?

Du hast das script bei dir lokal erstellt, lokal funktioniert es, dann auf einen remote-host kopiert, dich dort per ssh eingeloggt und es dann ausgeführt und da funktioniert es anders?

Ich habe hier den leisen verdacht das du extrem wichtige teile von dem was du machst uns vorenthälst :)

LG

Zed
 
Vielleicht habe ich mich ja komisch ausgedrückt:

Ich habe ein Skript für /bin/sh geschrieben, welches auf meinem OpenBSD-System liegt, welches mittels grep bestimmte Informationen ausliest. Wenn ich dieses auf meinem OpenBSD-System mittels /bin/sh /home/myuser/myscript.sh ausführe, bekomme ich die gewünschten Ausgaben.

Jetzt rufe ich das selbe Script mittels ssh von einem Ubuntu-System auf und die eine Anzeige mit dem Mehrfach-grep bleibt leer???
 
Hi,

post doch mal exakt dein sh Script sowie den Aufruf auf Ubuntuseite. ssh user@servername /pfad/zum/script?

Ich habe das mit nem OpenBSD Server, Client und einmal nen Ubuntu-Client probiert, das funktioniert jeweils einwandfrei:

Code:
Direkt auf der Shell, alles per SSH:

user@server1:/home/user$ ps aux | grep i | grep init
root         1  0.0  0.0   472   448 ??  S       4:09PM    0:01.04 /sbin/init

Das ganze als sh Script erstellt und per SSH laufen gelassen:
user@server1:/home/user$ cat testi.sh                                                                                                                     
#!/bin/sh
ps aux | grep i | grep init

Und das gleiche nochmal direkt per remote-ssh von einem anderen host aus:

user@client:/home/jan$ ssh user@192.168.178.666 /home/user/testi.sh 
root         1  0.0  0.0   472   448 ??  I       4:09PM    0:01.04 /sbin/init
user     89846  0.0  0.0   836     8 ??  Rp      4:13PM    0:00.00 grep init (s

[/CODE)
 
ich meine schon, dass BSD-grep und GNU-grep Unterschiede zeigen. Das hatte ich mal bei anderer Gelegenheit erlebt und erfahren, dass zumindest FreeBSD viele Anwendungen selbst geschrieben hat und nicht die GNU-Versionen benutzt.
Ganz unterschiedlich kann sed funktionieren, mit dem man ja auch ein grep ersetzen könnte.
Und unterschiedlich ist ps, vielleicht bekommst du nicht die gleiche Ausgabe auf dem GNU/Linux und dein Script scheitert deshalb?
 
ich meine schon, dass BSD-grep und GNU-grep Unterschiede zeigen. Das hatte ich mal bei anderer Gelegenheit erlebt und erfahren, dass zumindest FreeBSD viele Anwendungen selbst geschrieben hat und nicht die GNU-Versionen benutzt.
Ganz unterschiedlich kann sed funktionieren, mit dem man ja auch ein grep ersetzen könnte.
Und unterschiedlich ist ps, vielleicht bekommst du nicht die gleiche Ausgabe auf dem GNU/Linux und dein Script scheitert deshalb?

Interressante Theorie, aber der OP schreibt doch das er ein Script einmal auf einen OpenBSD Rechner Lokal und einmal auf dem gleichen OpenBSD Rechner, aber dann per SSH aufruft, da sind keine unterschiedlichen greps beteiligt ... ... ...
 
Durch Probieren habe ich rausbekommen, dass es an dem doppelten grep-Befehl liegt - bei einem grep funktioniert alles wunderbar.

Das ergibt keinen Sinn, denn egal wieviele greps es sind, am Anfang steht das stdout von ps und am Ende kommt das stdout von grep. Es ist völlig egal, was dazwischen passiert, die Anzahl an Befehlen wird keinen Unterschied machen.

Was dann natürlich die Vermutung nahelegt, dass halt über SSH einfach nicht dasselbe im stdout von ps steht und das zweite grep einfach nichts findet.
 
@pit234a
Was meinst du mit manuell?

Den Quellcode kann ich erst morgen liefern!
Mit manuell meint @pit234a wahrscheinlich:

ssh halloICKEbins2@192.168.123.123 "ps aux | grep \"begriff1\" | grep \"begriff2\""

Wenn du deinen Quelltext veröffentlichst wissen wir mehr… ich rechne aber ehrlich gesagt damit, dass es ein Fehler wegen Verwendung von Umgebungsvariablen ist und du die unterschiede zwischen dem Programm /bin/sh und einer interaktiven login-Shell nicht in Betracht gezogen hast.
 

Könnte es vielleicht daran liegen?
Bildschirmfoto 2019-11-04 um 11.00.43.png
 
Steht bei mir vor und danach auf 58 232 und lokal kommen ja alle erwarteten Ausgaben!

Aber ich denke der Ansatz ist der Richtige - bloß wie komme ich damit weiter?
 
Zuletzt bearbeitet:
@SierraX

Ist der richtige Ansatz!

Die ps aux Zeile mit dem Treffer hat mehr als 58 Spalten und wenn man nach einem Begriff sucht, welcher über den 58 Spalten (stty line) liegt, kann er es diesen nicht finden. Mit ps -U root | grep syslogd | grep -v grep | grep "priv" findet er den Eintrag.


Kann ich den 58-Wert erhöhen?
 
Steht bei mir vor und danach auf 58 232
und lokal kommen ja alle erwarteten Ausgaben!
ein wrapper kann eine andere STTY size haben als eine login shell.

Ein Test-Weg und deine Beschreibung ist viel zu verworren um da was nachzuvollziehen.
Rein logisch wäre:
Man loggt sich als User auf OpenBSD ein.
Funktioniert der Befehl? [ja][nein]
Funktioniert der Befehl mit einem doas davor? [ja] [nein]
Wenn beides ein ja ist schreibt man das Script
Funktioniert das Script? [ja] [nein]
Funktioniert das Script wenn es in einem Unterverzeichnis von /root/ mit einem doas davor? [ja] [nein]
Wenn alles 4 ein ja ist
Geht man auf den host, von dem aus man das Script ausführen möchte.
dann gibt man ein ssh Kommando ein ohne das man sich interaktiv einloggt. Funktioniert das? [ja] [nein]
dann gibt man ein ssh Kommando ein ohne das man sich interaktiv einloggt mit einem doas Befehl davor ein. Funktioniert das? [ja] [nein]

Und erst zum schluss schreibt man den Wrapper

es kann auf dem Weg so viel schief gehen, vor allem wenn man sich an die Grundregeln des Shell scriptings nicht hält
 
Code:
     -w      Use 132 columns to display information, instead of the default,
             which is the window size.  If the -w option is specified more
             than once, ps will use as many columns as necessary without
             regard for window size.

Fairerweise muss man sagen, dass Programme, die erkennen, dass stdout kein Terminal ist, gar keine Dimensionen annehmen sollten. ps ist hier nicht ganz unschuldig.

Edit: pgrep wäre hier auch der bessere Ansatz.
 
Zuletzt bearbeitet:
Zurück
Oben