All of a sudden, my Git-Bash is not starting up the ssh-agent and it hangs in there. So trouble this further, I have manually executed the below command and it hangs in there.
$ eval ssh-agent -s
And in the Windows Machine, I could see the process is alive
> Get-Process *bash, *ssh-add, *ssh-agent
Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName
------- ------ ----- ----- ------ -- -- -----------
229 20 8484 12980 0.17 2516 1 bash
149 18 2884 8544 0.06 37152 1 git-bash
231 19 6628 9416 133.69 9844 1 ssh-agent
> Get-Service ssh-agent | Select StartType
StartType
---------
Manual
Additional Note:
If I type ssh-agent in command-prompt or in powershell it seems to execute fine. Only in Git Bash it seems to not work and this happened very recently.
Trying to understand, why ssh-agent is not getting started and hangs in ?
Related
I'm trying to get a list of running domains from an application server. It takes a few seconds for the query to respond; so, it would be nice to run it in the background. However, it hangs, apparently waiting on something even though the command takes no input. When I bring it to the foreground, it immediately displays the results and quits. I also tried disconnecting stdin with 0<&-.
java -jar appserver-cli.jar list-domains &
How can I diagnose the issue? Or better yet, what's the problem?
I can see some open pipes and sockets.
ps --forest
PID TTY TIME CMD
16876 pts/1 00:00:00 bash
2478 pts/1 00:00:00 \_ java
2499 pts/1 00:00:00 | \_ stty
ls -l /proc/2478/fd
lrwx------. 1 vagrant vagrant 64 Mar 23 09:08 0 -> /dev/pts/1
lrwx------. 1 vagrant vagrant 64 Mar 23 09:08 1 -> /dev/pts/1
lrwx------. 1 vagrant vagrant 64 Mar 23 09:08 10 -> socket:[148228]
lrwx------. 1 vagrant vagrant 64 Mar 23 09:08 2 -> /dev/pts/1
lrwx------. 1 vagrant vagrant 64 Mar 23 09:08 24 -> socket:[148389]
lr-x------. 1 vagrant vagrant 64 Mar 23 09:08 73 -> pipe:[18170535]
lr-x------. 1 vagrant vagrant 64 Mar 23 09:08 75 -> pipe:[18170536]
I also see the following signal which does not show up when I run the process in the foreground.
futex(0x7fda7e0309d0, FUTEX_WAIT, 9670, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGTTOU {si_signo=SIGTTOU, si_code=SI_KERNEL} ---
--- stopped by SIGTTOU ---
The following resources were helpful in figuring this out.
sigttin-sigttou-deep-dive-linux
cannot-rewrite-trap-command-for-sigtstp-sigttin-and-sigttou
From my post, it's clear the process is receiving SIGTTOU. It may be trying to configure terminal settings. I noticed that when I run from a script instead of interactive, there is no empty handler defined for SIGTTOU. The following resolves the issue.
bash -c "java -jar appserver-cli.jar list-domains &"
I was running a Python script which launches several times a Fortran executable (with os.system('./executable params.ini).
Unfortunately, I did a CTRL+Z to stop the python script but it seems that I have stopped it during the execution of the Fortran executable.
Now, impossible to relaunch the Python script. I tried. :
fg %1
and
bg %1
and
kill -CONT pid_of_executable
But nothing happens ...
So, is there a way to relaunch the python script ? I am frustrated ... if anyone could save my life ... (I am joking)
UPDATE 1: Once Python script stopped by CTRL+Z, pa aux | grep compute
gives :
user1 38258 0.0 0.0 6121988 10324 s003 S 3:26PM 0:00.99 /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python compute_Cl_variable_step_160_between_1e-8_and_1_values_Only_Omega_m_der_to_choose.py
user1 33564 0.0 0.0 6010372 16472 s012 S+ 1:34PM 0:01.44 /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python compute_Cl_variable_step_160_between_1e-8_and_1_values_Only_Omega_m_der_to_choose.py
user1 96299 0.0 0.0 6509060 12668 s004 S+ 6:06PM 0:01.77 /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python compute_Cl_variable_step_160_between_1e-8_and_1_values_Only_Omega_m_der_to_choose.py
With
jobs
you can see the suspended jobs
fg jobnummer
will bring it back.
I have a systemd unit script which looks something like this
cat /usr/lib/systemd/system/hello.service
[Unit]
Description=Simple Hello World service
After=syslog.target network.target
[Service]
Type=forking
EnvironmentFile=/root/hello.env
ExecStart=/bin/gdb /root/hello
StandardInput=tty-force
StandardOutput=inherit
TTYPath=/dev/pts/0
TTYReset=yes
TimeoutStartSec=infinty
[Install]
WantedBy=multi-user.target
The whole point is, i want to start the service with gdb on start up.[Since the process involves lot of environmental variables i cannot use the gdb directly on the process.]
systemctl start hello (which is actually working).
But once i exit out of gdb tty is completely messed up.None of the control key work, ^Z, ^C.
This are the observation till now.
As describer by systemd man pages with "StandardInput=tty-force", will actually force the executing process to take control of tty.
Before i launch the process
# tty
/dev/pts/0
# ps -aef | grep bash
root 2805 2803 0 10:42 pts/0 00:00:00 -bash
root 2860 2805 0 10:45 pts/0 00:00:00 grep --color=auto bash
After i launch
# tty
/dev/pts/0
# ps -aef | grep bash
root 2805 2803 0 10:42 ? 00:00:00 -bash
root 2884 2805 0 10:47 ? 00:00:00 grep --color=auto bash
Tried reset the terminal, still doesn't work.
subsequent systemctl command dsplay the below error
systemctl stop hello
Error creating textual authentication agent: Error opening current controlling terminal for the process (`/dev/tty'): No such device or address (polkit-error-quark, 0)
So the question is is there a way to reset the tty back to bash ?
I have a ruby 2.0 sinatra 'faceless' app that serves up json by calling an external service. It works fine.
The main app is run on port 80 in a ubuntu machine.
I also start an instance using 'foreman start' - so it runs on port 5000 on the same ubuntu virtual machine.
On the port 80 instance, the process 'foreman master' soaks up CPU time, while with the same load, the one on port 5000 uses essentially 0 CPU.
$ ps -a l
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
4 0 1615 1614 20 0 26140 17236 wait Sl+ tty1 0:28 foreman: master
0 1000 1899 1659 20 0 25036 16612 wait Sl+ pts/1 0:00 foreman: master
The apps were started at the same time and both had the same load (very light for 20 mins).
The only difference I can see is that the problem one is started on port 80 using a sudo command, and the other one is just started as a user process.
Is there a difference in how foreman needs to output log entries in a tty terminal vs a pts/1 terminal?
Note that with 40 people banging away on the app, the foreman master process is using 90% cpu while all the other ruby processes that are supposed to be doing the work are at 1% (9 unicorns).
I think its something to do with terminal output handled differently but I'm not sure.
Thanks for any help.
Is there a way to tell foreman or ruby to not write log stuff out at all?
EDIT
I now think that it is related to terminal logging, since i turned 95% of it off for the deployment app, and loads are better, but still higher than the normal non rvmsudo command.
I've written a scrip that works fine to start and stop a server.
#!/bin/bash
PID_FILE='/var/run/rserve.pid'
start() {
touch $PID_FILE
eval "/usr/bin/R CMD Rserve"
PID=$(ps aux | grep Rserve | grep -v grep | awk '{print $2}')
echo "Starting Rserve with PID $PID"
echo $PID > $PID_FILE
}
stop () {
pkill Rserve
rm $PID_FILE
echo "Stopping Rserve"
}
case $1 in
start)
start
;;
stop)
stop
;;
*)
echo "usage: rserve {start|stop}" ;;
esac
exit 0
If I start it by running
rserve start
and then start monit it will correctly capture the PID and the server:
The Monit daemon 5.3.2 uptime: 0m
Remote Host 'localhost'
status Online with all services
monitoring status Monitored
port response time 0.000s to localhost:6311 [DEFAULT via TCP]
data collected Mon, 13 May 2013 20:03:50
System 'system_gauss'
status Running
monitoring status Monitored
load average [0.37] [0.29] [0.25]
cpu 0.0%us 0.2%sy 0.0%wa
memory usage 524044 kB [25.6%]
swap usage 4848 kB [0.1%]
data collected Mon, 13 May 2013 20:03:50
If I stop it, it will properly kill the process and unmonitor it. However if I start it again, it won't start the server again:
ps ax | grep Rserve | grep -vc grep
1
monit stop localhost
ps ax | grep Rserve | grep -vc grep
0
monit start localhost
[UTC May 13 20:07:24] info : 'localhost' start on user request
[UTC May 13 20:07:24] info : monit daemon at 4370 awakened
[UTC May 13 20:07:24] info : Awakened by User defined signal 1
[UTC May 13 20:07:24] info : 'localhost' start: /usr/bin/rserve
[UTC May 13 20:07:24] info : 'localhost' start action done
[UTC May 13 20:07:34] error : 'localhost' failed, cannot open a connection to INET[localhost:6311] via TCP
Here is the monitrc:
check host localhost with address 127.0.0.1
start = "/usr/bin/rserve start"
stop = "/usr/bin/rserve stop"
if failed host localhost port 6311 type tcp with timeout 15 seconds for 5 cycles
then restart
I had problem start or stop process via shell too.
One solution might be add "/bin/bash" in the config like this:
start program = "/bin/bash /urs/bin/rserv start"
stop program = "/bin/bash /urs/bin/rserv stop"
It worked for me.
monit is a silent killer. It does not tell you anything. Here are things I would check which monit won't help you identify
Check permissions of all the files you are reading / writing. If you are redirecting output to a file, make sure that file is writable by uid and gid you are using to execute the program
Again check exec permission on the program you are trying to run
Specify full path to any program you are trying to execute ( not strictly necessary, but you don't have to worry about path not being set if you always specify full path )
Make sure you can run the program outside of monit without any error before trying to investigate why monit is not starting.
If the Monit log is displaying
failed to start (exit status -1) -- no output
Then it may be that you're trying to run a script without any of the Bash infrastructure. You can run such a command by wrapping it in /bin/bash -c, like so:
check process my-process
matching "my-process-name"
start program = "/bin/bash -c '/etc/init.d/my-init-script'"
When monit starts it checks for its own pidfile and checks if the process with
matching PID is running already - if it does, then it just wakes up this
process.
in your case, check if this pid is being used by some other process:
ps -ef |grep 4370
if yes, then you need to remove the below file(usually under /run directory) and start monit again:
monit.pid
For me, the issue was that the stop command was not being run, even though I specifically specified "then restart" on the configuration.
The solution was just to change:
start program = "/etc/init.d/.... restart"