Failed to create a tmux session in a remote machine with SSHLibrary in robot framework.
Code tried -
Execute Command tmux new -s session01
Output-
20211213 12:33:37.257 : INFO : Executing command 'tmux new -s session01'.
20211213 12:33:37.348 : INFO : Command exited with return code 1.
I was able to execute in the following way -
Execute Command tmux new-session -d -s session_name 'Command To Execute'
Related
I'm trying to use nix on repl.it. I'm using static-nix from https://matthewbauer.us/blog/static-nix.html. If I run the following code:
mkdir -p "$HOME/.cache/nix/"
curl https://matthewbauer.us/nix > "$HOME/.cache/nix/nix.exe"
cat "$HOME/.cache/nix/nix.exe" | bash -s run --no-sandbox --store "$HOME/.cache/nix/store" -f channel:nixpkgs-unstable bash graphviz -c sh -c 'dot --help'
I get this error:
error: setting up a private mount namespace: Operation not permitted
I tried --no-sandbox, --option sandbox false and --option build-use-sandbox false, none of these have any effect on the error.
This is executed as non-root on a machine for which it is not possible for me to change kernel settings.
Here's a REPL reproducing the issue (it runs for a short while before displaying the error): https://repl.it/#suzannesoy/AgonizingWittyCoding#main.sh
I am trying to run an .exe that sits on a remote machine with PSEXEC, but it does not run properly.
The exe is a converted python script:
usage: WindowsUpdates3.exe [-h] [-v] [-m] [-i] [-u] [-r] [-s SKIP]
List, download and update Windows clients
optional arguments:
-h, --help show this help message and exit
-v, --version Show program version and exit
-m, --list-missing List missing updates
-i, --list-installed List installed updates
-u, --update List and install missing updates
-r, --reboot Reboot after installing updates if needed
-s SKIP, --skip SKIP Skips these KB numbers
I am able to run the .exe as intended with a PSEXEC console session:
PSEXEC \\<hostname> cmd
Navigate to the exe my.exe -i, run it and it works the same way if I execute it on the machine locally.
When I try to execute the file directly some fucntionality does not work
PSEXEC.exe \\<hostname> -h "C:\WindowsUpdates\WindowsUpdates3.exe" -i
...
C:\WindowsUpdates\WindowsUpdates3.exe exited on <hostname> with error code 0.
I am able to get the help-menu (-h) and the version (-v) of the exe with the above command.
The other arguments don't return anything but code 0 and the --update argument throws a com_error: -2147024891, which translates to access denied...
How can this be as I have the same privileges as if I spawn a cmd terminal?
Does tcsh support launching itself in a remote directory via an argument?
The setup I am dealing with does not allow me to chdir to the remote directory before invoking tcsh, and I'd like to avoid having to create a .sh file for this workflow.
Here are the available arguments I see for v6.19:
> tcsh --help
tcsh 6.19.00 (Astron) 2015-05-21 (x86_64-unknown-Linux) options wide,nls,dl,al,kan,rh,color,filec
-b file batch mode, read and execute commands from 'file'
-c command run 'command' from next argument
-d load directory stack from '~/.cshdirs'
-Dname[=value] define environment variable `name' to `value' (DomainOS only)
-e exit on any error
-f start faster by ignoring the start-up file
-F use fork() instead of vfork() when spawning (ConvexOS only)
-i interactive, even when input is not from a terminal
-l act as a login shell, must be the only option specified
-m load the start-up file, whether or not owned by effective user
-n file no execute mode, just check syntax of the following `file'
-q accept SIGQUIT for running under a debugger
-s read commands from standard input
-t read one line from standard input
-v echo commands after history substitution
-V like -v but including commands read from the start-up file
-x echo commands immediately before execution
-X like -x but including commands read from the start-up file
--help print this message and exit
--version print the version shell variable and exit
This works, but is suboptimal because it launches two instances of tcsh:
tcsh -c 'cd /tmp && tcsh'
I´m a happy user of byobu, but recently I noted that I cannot attach anymore to open sessions.
With ps aux | grep tmux I can clearly see many tmux processes, but unfortunatly, when I try to attach with:
tmux attach
byobu attach
I get no results but a no session error. Moreover, with byobu-select-session I got a failed to connect to server instead.
There is a commant to connect tmux to a given socket, which I found using
lsof -U | grep '^tmux'. But still no session attached. My session files are in /tmp/user/tmux-1000/default, but I can see some sockets being used.
From ps aux I can see that byobu launches tmux with: tmux -2 -f /usr/share/byobu/profiles/tmuxrc new-session -n - /usr/bin/byobu-shell
Unfortunately, either with byobu -S path or byobu -L socketname I am not able to attach to previously open session, and byobu simply start a new session.
I run into a similar situation caused by accidentally removing the tmux socket in /tmp. The method described here solved the problem for me (either killall -SIGUSR1 tmux or kill -USR1 $PID_FOR_RUNNING_TMUX).
i try to open a Unix session through java code and windows using putty.exe as follows:
Runtime.getRuntime().exec("cmd /c start /B C:/scripts/Session.bat ");
the 'Session.bat' file content is:
putty.exe -t -ssh root#aaa -pw abcd -P 22
aaa is the server name.
root is the user name.
abcd is the password
Now, the session opens well, but i want to run couple of simple commands from the above command (ll -s, pwd, etc.).
But when i try to add txt file which contains these commands to the above command, i see that the commands are executing after the user name entered and before the password.
the complete command is:
putty.exe -t -ssh root#aaa -pw abcd -P 22 -m C:\scripts\commands.txt
that's why i get the error (below) since the command "ll" came before the password:
Using username "root".
bash: ll:: command not found
please help me...
Thanks
There is no way the command could execute on the remote computer before the password is processed. Surely an alias is missing in root's bash startup files.
Try adding alias ll='ls -l' to /root/.bash_profile ?