screen, ssh en control-C in remote sessies

[thunder7]

Ik beheer een server, waarop altijd een screen-sessie loopt.
Deze kent een aantal sessies met een shell, een aantal monitoring-sessies en een aantal vaste verbindingen naar andere servers.

Alle servers draaien linux.

Nu zou ik die screen-sessie bij het starten van de serveri het liefst automatisch willen laten opzetten, zodat elk commando altijd met de goede naam in de goede sessie komt te staan.

Dat lukt, maar als ik in een remote sessie een commando (zoals multitail) wil onderbreken met control-C, wordt de control-C verwerkt door het ssh-commando dat die sessie opzet en wordt de gehele sessie gelijk afgebroken, in plaats van alleen het commando in de sessie.

dus invoeren op server1:

ssh -l user server2 "tail -f somefile.log"
en dan control-C

geeft de prompt van server1, en niet de prompt van server2

Zoeken op internet leert dat uitvoeren in een shell op server2 van het taill -f commando niet helpt. Verder zie ik opmerkingen over dat met het -t commando ssh een tty reserveert op server2, maar netto geeft dat geen verschil.Ook een '; exec /bin/bash -l' achter het commando lijkt niet veel te doen.

Iemand een goed idee hoe dit wel te regelen?

[ Voor 5% gewijzigd door thunder7 op 18-08-2017 13:15 ]

[Hero of Time]

Eerst de SSH sessie starten, daarna pas je commando. Wat je nu doet, is direct remote een commando uitvoeren. Als dat klaar is, is je verbinding klaar. Je start dus geen interactieve sessie. Kijk maar eens wat een simpele 'ls' doet.

[thunder7]

ssh -l user server2 "bash -l tail -f ..." doet het niet.

ook een poging om met screen -p 1 -X eval "ls\015" een commando naar een bash-shell op een remote server in screen sessie 1 te sturen doet niet wat ik wil; er komt in de screen status balk onderaan 'Unknown command ls' te staan.

[Mijzelf]

Wat heeft die screen sessie hiermee te maken?

[thunder7]

OK, hoe start jij zonder screen een interactieve sessie waar je later karakters heen stuurt zonder die handmatig in te kloppen?

[Thralas]

thunder7 schreef op vrijdag 18 augustus 2017 @ 13:13:
ssh -l user server2 "tail -f somefile.log"
en dan control-C

geeft de prompt van server1, en niet de prompt van server2

As expected. Je hebt twee problemen:

1. Er wordt geen pty gealloceerd als je een commando aan ssh meegeeft.
2. Als je een commando meegeeft dan wordt deze met `$SHELL -c` uitgevoerd. Na het uitvoeren van het commando sluit de shell en is er geen interactie meer mogelijk.

thunder7 schreef op vrijdag 18 augustus 2017 @ 13:37:
ssh -l user server2 "bash -l tail -f ..." doet het niet.

Dat slaat helemaal nergens op. Dan probeer je bash het bestand 'tail' te laten interpreteren.

ook een poging om met screen -p 1 -X eval "ls\015" een commando naar een bash-shell op een remote server in screen sessie 1 te sturen doet niet wat ik wil; er komt in de screen status balk onderaan 'Unknown command ls' te staan.

Uiteraard. Screen verwacht een screen command (en eval heeft enkel als functie dat het meerdere commando's uitvoert). Als je een subproces wilt spawnen zul je iets als 'exec' moeten gebruiken (volgens de man page die ik hier voor je doorlees).

Maar dat subproces spawnt dan op de host waar screen draait, niet daar waar je heen SSH't. Volgens mij doet dat niet wat je wil.

Hoe dan wel? Het antwoord staat op Stackoverflow: Invoke bash, run commands inside new shell, then give control back to user

Deels tenminste, want je zult het moeten combineren met `ssh -t` om een pty te alloceren.

Gezien de ranzigheid van de bash-oplossing zou ik je wel afvragen of dit werkelijk is wat je wil. Waarom wil je zo nodig een commando remote uitvoeren en daarna een shell overhouden na het sluiten ervan?

[thunder7]

Ik noem een voorbeeld: ik zet een tail aan op een logfile, waar de maand in de naam staat. Als de maand wisselt, moet dat tail-commando dus vervangen worden. Eenvoudigste manier is control-C en overnieuw intypen.

[CyBeR]

Is je probleem niet gewoon dat je geen shell hebt waarin tail draait, en dat bij het control-C'en van tail de screen sessie dus exit en je verbinding ook verbroken wordt?

[Mijzelf]

thunder7 schreef op vrijdag 18 augustus 2017 @ 13:56:
OK, hoe start jij zonder screen een interactieve sessie waar je later karakters heen stuurt zonder die handmatig in te kloppen?

Hoe doe je het mèt screen? Ik zie gewoon niet wat je wilt bereiken. Je hebt een sessie in screen draaien op de server, en vervolgens start je via ssh een shell op dezelfde server die een simpel commando uitvoert.

Hoe raakt dat de sessie in screen?

[pistole]

thunder7 schreef op vrijdag 18 augustus 2017 @ 16:23:
Ik noem een voorbeeld: ik zet een tail aan op een logfile, waar de maand in de naam staat. Als de maand wisselt, moet dat tail-commando dus vervangen worden. Eenvoudigste manier is control-C en overnieuw intypen.

Het is dan toch logischer/makkelijker om al je 'screens' opnieuw te starten?

[thunder7]

Niet als er in een andere sessie een langlopend commando loopt bijvoorbeeld, of je net met een probleem bezig bent waar de history en/of de omgevingsvariabelen precies op afgestemd zijn. Vind ik. uiteraard.

[Thralas]

Mijzelf schreef op vrijdag 18 augustus 2017 @ 16:30:
Hoe doe je het mèt screen? Ik zie gewoon niet wat je wilt bereiken. Je hebt een sessie in screen draaien op de server, en vervolgens start je via ssh een shell op dezelfde server die een simpel commando uitvoert.

Hij wil feitelijk gewoon een verzameling SSH-verbindingen naar andere servers in 1 screensessie.

thunder7 schreef op vrijdag 18 augustus 2017 @ 16:23:
Ik noem een voorbeeld: ik zet een tail aan op een logfile, waar de maand in de naam staat. Als de maand wisselt, moet dat tail-commando dus vervangen worden. Eenvoudigste manier is control-C en overnieuw intypen.

Mooi voorbeeld. Die zou ik dan bij voorkeur helemaal automatiseren.

Ik zou de configuratie aanpassen zodat de 'huidige' logfile geen datum bevat, en tail vertellen dat hij niet de file descriptor moet volgen (standaardgedrag) maar de daadwerkelijke naam (zie man page).

Als je geen invloed hebt op de filenames dan kun je dat wel afvangen met een cronjob en een symlink.

Hero of Time schreef op vrijdag 18 augustus 2017 @ 19:00:
Tja, enige wat je kan doen is eerst SSH, dan pas je commando uitvoeren zodat bij ctrl+c je sessie niet gecancelled wordt. Wat je anders met ctrl+c stopt, is het commando wat je op server1 uitvoert, in z'n volledigheid is dat 'ssh user@server2 tail -f /pad/naar/log'.

Het kan dus wel, zie mijn eerste post in dit topic, de crux is dat thunder7 tegen twee problemen tegelijk aanloopt (pty en gedrag van sh -c)..

[ Voor 17% gewijzigd door Thralas op 18-08-2017 19:02 ]

[Hero of Time]

Tja, enige wat je kan doen is eerst SSH, dan pas je commando uitvoeren zodat bij ctrl+c je sessie niet gecancelled wordt. Wat je anders met ctrl+c stopt, is het commando wat je op server1 uitvoert, in z'n volledigheid is dat 'ssh user@server2 tail -f /pad/naar/log'.

Doe je echt voornamelijk logs tailen, kijk dan naar hoe je de bestandsnaam hetzelfde kan houden na een rotate. Stel dat je /var/log/messages wilt bijhouden, dan kan dat want als logrotate de boel hernoemd, wordt het bestand wat je volgt hernoemt en een nieuwe met dezelfde naam als de oude aangemaakt. Met tail -F volg je automatisch het nieuwe.

[Grvy]

offtopic en wellicht stom als Windows beheerder zeggende, maar hier heb je toch Syslog voor? of snap ik het dan niet. voor het bijhouden van log files bedoel ik dan he.

[ Voor 17% gewijzigd door Grvy op 18-08-2017 19:04 ]

[thunder7]

Ik ben er inmiddels achter dat het je met screen -X register en screen -X paste ook zelf tekst kunt injecteren in de stdin van verschillende sessies, dus het lijkt er op dat het met screen opstarten van een reeks sessies en dan het injecteren van het juiste commando wel eens de oplossing zou kunnen zijn. Maandag verder experimenteren!

[Hero of Time]

Thralas schreef op vrijdag 18 augustus 2017 @ 18:59:
[...]

Het kan dus wel, zie mijn eerste post in dit topic, de crux is dat thunder7 tegen twee problemen tegelijk aanloopt (pty en gedrag van sh -c)..

Nee. Zelfs als je een PTY forceert stopt je sessie alsnog zodra je het commando afbreekt. Zoals ik zei is niet 'tail' het commando wat je met ctrl+c stopt, maar 'ssh'.

Grvy schreef op vrijdag 18 augustus 2017 @ 19:04:
offtopic en wellicht stom als Windows beheerder zeggende, maar hier heb je toch Syslog voor? of snap ik het dan niet. voor het bijhouden van log files bedoel ik dan he.

Nee. Als je zaken naar syslog stuurt, zie je het nog steeds niet zelf. Zie het zo, als Windows beheerder. Je wilt nieuwe events van je Event Viewer zien. Maar elke keer als je een event bekijkt en er komt een nieuwe binnen, moet je de weergave verversen. Dat gebeurt niet automatisch. Vervolgens moet je ook nog eens die events aanklikken.

Stel nou dat het wel automatisch zou gaan. Dan krijg je in je view ook alle events van andere applicaties die je niet wilt zien. Het is dus geen perfecte oplossing. Verre van eigenlijk.

thunder7 schreef op vrijdag 18 augustus 2017 @ 19:16:
Ik ben er inmiddels achter dat het je met screen -X register en screen -X paste ook zelf tekst kunt injecteren in de stdin van verschillende sessies, dus het lijkt er op dat het met screen opstarten van een reeks sessies en dan het injecteren van het juiste commando wel eens de oplossing zou kunnen zijn. Maandag verder experimenteren!

Dat gaat je niet helpen. Het sturen van tekens naar een screen scherm of sessie met het idee om commando's uit te voeren gaat uit van een interactieve shell waar je gewoon commando's in kan typen. Tijdens een tail -f heb je geen direct interactieve shell meer, die is bezig met het volgen en weergeven van het bestand dat je opgeeft.

Het enige waar het zinvol voor zou kunnen zijn, is om bepaalde keystrokes te herhalen of 'unattended' zaken weer te starten zoals het stoppen van de tail via een ssh sessie en een nieuwe starten. Dat kan je net zo goed ook zelf doen of met een script automatiseren.

[thunder7]

Als ik eerst een bash sessie start (met bash -l) heb ik een interactieve shell. Als ik daar

$screen -p 9 -X register a "tail -f test.out^M"
$screen -p 9 -X paste a

heen stuur, krijg ik een tail -f command en blijf ik na control-C in die shell zitten.

Als ik

$screen -p 9 -X register a "ssh -l user server2^M"
$screen -p 9 -X paste a
$screen -p 9 -X register a "tail -f test.out^M"
$screen -p 9 -X paste a

doe, krijg ik een tail -f sessie op server2, en blijf ik na control-c in een shell op server 2.

[Hero of Time]

Ja, duh, natuurlijk werkt dat op die manier. Je doet nu in feite handmatig een ssh sessie naar server 2 starten en daarna tail je het bestand. Dat is heel wat anders dan direct tail aanroepen in je ssh commando.

Wat deed je eerst met screen dat nu opeens zo 'revolutionair' anders is? Deed je eerst handmatig screen starten en dan telkens nieuwe 'windows' openen met je ssh commando? Want dat kan je met een .screenrc ook automatiseren.

[thunder7]

Tot nu toe startte ik screen met -c verwijzend naar een template, met daarin iets als

screen -t log1 1 /bin/bash -l -c "tail -55f logfile1.txt"
screen -t log2 2 /bin/bash -l -c "tail -55f logfile2.txt"
screen -t log3 3 /bin/bash -l -c "ssh -l user server2 'tail -55f logfile3.txt'"