I would like to be able to start a screen session using a certain config file. I know that I can use -c and then the file path to the config file but if I do that, then the sh script I am using does not work. You can see the sh script below:
#!/bin/bash
cd /media/kiancross/Minecraft_Server/1.6.4
screen -d -m -S MinecraftServer ./start.sh
screen -r MinecraftServer
I would have thought that I can do the following code:
#!/bin/bash
cd /media/kiancross/Minecraft_Server/1.6.4
screen -d -m -S -c MinecraftServer $HOME/config_file/mcserver.config ./start.sh
screen -r MinecraftServer
But then I get a message saying:
There is no screen to be resumed matching MinecraftServer.
After then checking to see if there is a screen session running it says that there are no screen sessions running
No Sockets found in /var/run/screen/S-kiancross.
Does anybody know how I can do this so that I can use a custom config file?
The command should be:
screen -d -m -S MinecraftServer -c $HOME/config_file/mcserver.config ./start.sh
The name of the screen session goes after -S and the path of the config file goes after -c. You inserted -c before the screen name.
Related
Is there anyway I can use the screen command with ansible?
Would be great if we can screen logs while installing applications to keep full logs.
You can use shell module and run screen with "bash -c", and add | tee command to write all output to file. Or use screen with parameter "-Logfile file"
ansible -i ${inventory} -m shell -a "screen -mdSA screenname bash -c 'ls -lah | tee /tmp/screenname-$(date +%Y-%m-%d).log.txt'"
I am new to Docker, Debezium, Bash, and Kafka. I am attempting to run the Debezium tutorial/example for MSSQL Server on Windows 10 here:
https://github.com/debezium/debezium-examples/blob/master/tutorial/README.md#using-sql-server
I am able to start the topology, per step one. However, when I go to step two and execute the following command:
cat debezium-sqlserver-init/inventory.sql | docker exec -i tutorial_sqlserver_1 bash -c '/opt/mssql-tools/bin/sqlcmd -U sa -P $SA_PASSWORD'
I get the following error:
bash: C:/Program: No such file or directory
I do not have the foggiest idea why it would even drag C:/Program in to this. I do not see it in the command nor do I see it in the *.sql file. Does anyone know why this is happening and what the fix is?
Note 1: I am already in the current directory where this command should be runnable and there are no spaces in the folder/file path
Note 2: I am running the commands in Git Bash
When using set -x to log how the command is run, there's still no C:/Program anywhere in it, as can be seen by the following log:
$ cat debezium-sqlserver-init/inventory.sql | docker exec -i tutorial_sqlserver_1 bash -c '/opt/mssql-tools/bin/sqlcmd -U sa -P $SA_PASSWORD'
+ cat debezium-sqlserver-init/inventory.sql
+ docker exec -i tutorial_sqlserver_1 bash -c '/opt/mssql-tools/bin/sqlcmd -U sa -P $SA_PASSWORD'
bash: C:/Program: No such file or directory
I had a similar problem yesterday, the solution was adding a backslash before the absolute path, like :
cat debezium-sqlserver-init/inventory.sql | docker exec -i tutorial_sqlserver_1 bash -c '\/opt/mssql-tools/bin/sqlcmd -U sa -P $SA_PASSWORD'
\/opt/mssql-tools/bin/sqlcmd prevents conversion to Windows path.
I'm making a script to restart an instance and it works without any log file but it gives the following error when I try to log the output of psadmin:
java.lang.NullPointerException
at com.peoplesoft.pt.psadmin.ui.Progress.<init>(Progress.java:135)
at com.peoplesoft.pt.psadmin.ui.Progress.getInstance(Progress.java:123)
at com.peoplesoft.pt.psadmin.pia.DomainBootHandler.BootWlsServer(DomainBootHandler.java:84)
at com.peoplesoft.pt.psadmin.pia.DomainBootHandler.run(DomainBootHandler.java:62)
at com.peoplesoft.pt.psadmin.pia.PIAAdminCmdLine.startDomain(PIAAdminCmdLine.java:270)
at com.peoplesoft.pt.psadmin.pia.PIAAdminCmdLine.run(PIAAdminCmdLine.java:481)
at com.peoplesoft.pt.psadmin.PSAdmin.runSwitched(PSAdmin.java:170)
at com.peoplesoft.pt.psadmin.PSAdmin.main(PSAdmin.java:232)
The following works (with no log):
export ORAENV_ASK=NO
export ORACLE_SID=PSCNV
.oraenv
export TUXDIR=/m001/Oracle/Middleware/tuxedo12.1.1.0
. /m001/pt854/psconfig.sh
. $TUXDIR/tux.env
export PS_CFG_HOME=$PS_HOME
$PS_HOME/appserv/psadmin -w shutdown -d PSCNV
$PS_HOME/appserv/psadmin -w start -d PSCNV
$PS_HOME/appserv/psadmin -w status -d PSCNV
Changing the psadmin invocations like so causes the error:
LOGFILE=/home/psoft/scripts/pscnv_webserv_stopNstart.log
test() {
$PS_HOME/appserv/psadmin -w shutdown -d PSCNV
$PS_HOME/appserv/psadmin -w start -d PSCNV
$PS_HOME/appserv/psadmin -w status -d PSCNV
}
test >> ${LOGFILE}
I also tried redirecting the output of each call individually and saw the same error.
I'm interested in any feedback to this question as well. I tried writing a cross platform java program to bounce multiple app and web servers and it seems that the psadmin.jar program exclusively holds onto stdout during the psadmin program.
I want to evaluate the output of psadmin/psadmin.jar to see if there are trappable errors that require killing of the process at the os level.
Hopefully there is a way to share stdout, but I have not found a way yet...
This solved this for me. nohup script -q -c "psadmin -w start -d peoplesoft"
I have a test that depend on a specific HTTP server, which requires me to start one with a known setup for the tests.
Since the server cannot be started as a daemon my approach was to just have it start in a screen session, run the test and close the session.
test:
screen -S test_http_server -d -m start_my_test_http_server
# run my tests here
screen -S test_http_server -X kill # works from bash but not makefile :/
Everything works fine except for closing or killing the session (which does work if I run it in bash afterwards).
It seems that using the # prefix (which I did, but was not posted in the original example code) that suppresses the normal 'echo' of the command somehow interferes with closing the screen.
Fails because of # prefix usage.
test:
#screen -S test_http_server -d -m start_my_test_http_server
# run my tests here
#screen -S test_http_server -X kill
Fixed make file that works as intended.
test:
screen -S test_http_server -d -m start_my_test_http_server
# run my tests here
screen -S test_http_server -X kill
I'm having some trouble getting a new session to execute a command after creation.
Here's a portion of my .tmux.conf:
set-window-option -g automatic-rename off
set-option -g allow-rename off
new -A -s 'main' -n 'servers' 'ls' # troubled line
splitw -h -p 35 htop
splitw -v
splitw -v -t 1
splitw -v -t 1
neww -n 'irc' weechat-curses
selectw -t 0
This is the line that I'm working on:
new -A -s 'main' -n 'servers' 'ls'
Here's how I open tmux:
alias tux='TERM=screen-256color-bce tmux -f ~/.tmux.conf attach-session -t main'
The 'ls' must be causing an error because when it is present, the initial pane doesn't get created. If I change it to 'top', it works fine and the command is executed.
So why does top work and not ls (or any other command I try)?
top runs until you quit. ls exits after it prints the contents of the current directory. This causes the window in which ls runs to close.
setw -t servers remain-on-exit on
should keep the the window named 'servers' from closing after its command exits, but it is complicated by the fact that the window does not exist before the new-session command is run, and after new-session returns, it may be too late to run the setw command (although you can try).
Instead, create a new session in which the default is for a window to remain after its command exists:
new -A -s 'main' -n 'servers' 'ls' # troubled line
set -t main set-remain-on-exit on
neww -n 'servers' ls
Based on your last comment, ignore the above, and replace your new command with
new -A -s 'main' -n 'servers'
send-keys -t servers.0 ls Enter
This creates a regular window, whose command is a regular shell, but then simulates typing the ls command at the first shell prompt to provide you with the list of files in that directory. After ls completes, you are back in the shell, and the pane will continue to exist until the shell itself completes.