I have a bitnami Jenkins VM, how do I tell what user Jenkins is running as? I suspect it is Tomcat.
If you have access to the gui, you can go to "manage jenkins" > "system information" and look for "user.name".
I would use ps to get the uid of the process, and grep for that in /etc/passwd
You could also create a Jenkins job containing a shell script box with the "whoami" command.
Use this command to see under which process your Jenkins server works on:
ps axufwwww | grep 'jenkins\|java' -
To interpret the results, look for:
jenkins 1087 0.0 0.0 18740 396 ? S 08:00 0:00 /usr/bin/daemon --name=jenkins
jenkins 1088 1.6 20.7 3600900 840116 ? Sl 08:00 2:12 \_ /usr/bin/java
1087 and 1088 are the PIDs. They might differ for you.
ps aux | grep '/usr/bin/daemon' | grep 'jenkins' | awk {'print $1'}
The command will show running processes, then grep for a process running as a daemon that includes the string 'jenkins'. Finally, get the first row of the piped output which is the user that is running Jenkins.
Related
If I'd like to kill all instances of that file manager, I'd do
killall thunar
which gives me
thunar: no process found
But this FM is definitely running!
Similarly ps aux | grep thunar doesn't find anything and yields:
cadoiz 27791 0.0 0.0 9588 2656 pts/0 S+ 11:33 0:00 grep --color=auto thunar
killall seems to be case sensitive and for some reason, Thunar with capital T works:
killall Thunar
You can consider this debian forum discussing the topic.
I have a new regression suite that uses the Wiremock standalone JAR. In order to ensure this is running on the server, I have this script called checkwiremock.sh
#!/bin/bash
cnt=$(ps -eaflc --sort stime | grep wiremock-standalone-2.11.0.jar |grep -v grep | wc -l)
if(test $cnt -eq 1);
then
echo "Service already running..."
else
echo "Starting Service"
nohup java -jar /etc/opt/wiremock/wiremock-standalone-2.11.0.jar --port 1324 --verbose &
fi
The script works as expected when ran manually
./checkwiremock.sh
However when started using Crontab,
* * * * * /bin/bash /etc/opt/wiremock/checkwiremock.sh
Wiremock returns
No response could be served as there are no stub mappings in this WireMock instance.
The only difference I can see between the manually started process and cron process is the TTY
root 31526 9.5 3.2 1309736 62704 pts/0 Sl 11:28 0:01 java -jar /etc/opt/wiremock/wiremock-standalone-2.11.0.jar --port 1324
root 31729 22.0 1.9 1294104 37808 ? Sl 11:31 0:00 java -jar /etc/opt/wiremock/wiremock-standalone-2.11.0.jar --port 1324
Can't figure out what is wrong here.
Server details:
Red Hat Enterprise Linux Server release 6.5 (Santiago)
*Edit: corrected paths to ones actually used
Change the directory in the checkwiremock.sh to:
cd /path/to/shell/script
I am accessing a server running CentOS (linux distribution) with an SSH connection.
Since I can't always stay logged in, I use "nohup [command] &" to run my programs.
I couldn't find how to get a list of all the programs I started using nohup.
"jobs" only works out before I log out. After that, if I log back again, the jobs command shows me nothing, but I can see in my log files that my programs are still running.
Is there a way to get a list of all the programs that I started using "nohup" ?
When I started with $ nohup storm dev-zookeper ,
METHOD1 : using jobs,
prayagupd#prayagupd:/home/vmfest# jobs -l
[1]+ 11129 Running nohup ~/bin/storm/bin/storm dev-zookeeper &
NOTE: jobs shows nohup processes only on the same terminal session where nohup was started. If you close the terminal session or try on new session it won't show the nohup processes. Prefer METHOD2
METHOD2 : using ps command.
$ ps xw
PID TTY STAT TIME COMMAND
1031 tty1 Ss+ 0:00 /sbin/getty -8 38400 tty1
10582 ? S 0:01 [kworker/0:0]
10826 ? Sl 0:18 java -server -Dstorm.options= -Dstorm.home=/root/bin/storm -Djava.library.path=/usr/local/lib:/opt/local/lib:/usr/lib -Dsto
10853 ? Ss 0:00 sshd: vmfest [priv]
TTY column with ? => nohup running programs.
Description
TTY column = the terminal associated with the process
STAT column = state of a process
S = interruptible sleep (waiting for an event to complete)
l = is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
Reference
$ man ps # then search /PROCESS STATE CODES
Instead of nohup, you should use screen. It achieves the same result - your commands are running "detached". However, you can resume screen sessions and get back into their "hidden" terminal and see recent progress inside that terminal.
screen has a lot of options. Most often I use these:
To start first screen session or to take over of most recent detached one:
screen -Rd
To detach from current session: Ctrl+ACtrl+D
You can also start multiple screens - read the docs.
If you have standart output redirect to "nohup.out" just see who use this file
lsof | grep nohup.out
You cannot exactly get a list of commands started with nohup but you can see them along with your other processes by using the command ps x. Commands started with nohup will have a question mark in the TTY column.
You can also just use the top command and your user ID will indicate the jobs running and the their times.
$ top
(this will show all running jobs)
$ top -U [user ID]
(This will show jobs that are specific for the user ID)
sudo lsof | grep nohup.out | awk '{print $2}' | sort -u | while read i; do ps -o args= $i; done
returns all processes that use the nohup.out file
Here is my /root/.bash_profile:
export DISPLAY=:42 && cd /home/df/SimulatedRpu-ex/bin && ./SimulatedRpu-V1 &
When I start my server,I run ps aux | grep SimulatedRpu and here is the output:
root 2758 0.2 1.0 62316 20416 ? Sl 14:35 0:00 ./SimulatedRpu-V1
root 3197 0.5 0.9 61428 19912 pts/0 Sl 14:35 0:00 ./SimulatedRpu-V1
root 3314 0.0 0.0 5112 716 pts/0 S+ 14:35 0:00 grep SimulatedRpu
So,the program print error message about the port is already used.
But why the command in /root/.bash_profile start twice?
Please help me,thank you!By the way,I use Redhat Enterprise 5.5
The profile is read every time you log in. So just by logging in to run the ps aux | grep SimulatedRpu, you run the profile once more and thus start a new process.
You should put the command into an init script instead.
[EDIT] You should also run Xvnc in the same script - that way, you can start and stop the display server together with your app.
Try it like
if ! ps aux | grep '[S]imulateRpu'; then
export DISPLAY=:42 && cd /home/df/SimulatedRpu-ex/bin && ./SimulatedRpu-V1 &
fi;
This way it will first check if if the application is not running yet. The [] around the S are to prevent grep from finding itself ;)
Let's say I have written a Perl script called "foo.pl" that takes in a password argument via the -p switch.
However, while it is running, anyone can do a ps and see the entire command-line string, including the password:
$ ps a |grep 'foo\.pl'
32310 pts/4 S+ 0:00 /usr/bin/perl -w ./foo.pl -p password
32313 pts/5 S+ 0:00 grep foo.pl
What is the easiest/simplest way to hide the password and replace it with something like xxxxxx?
Ask for the password from inside the script, so you don't have to pass it as an argument.
Update
Apparently this work for me, simulating a mysql behaviour:
#!/usr/bin/perl
($0 = "$0 #ARGV") =~ s/--password=\K\S+/x/;
<STDIN>;
$ ./s --user=me --password=secret
^Z
$ ps
PID TTY TIME CMD
1637 ttys000 0:00.12 -bash
2013 ttys000 0:00.00 ./s --user=me --password=x
Under MacOS 10.6
Passing passwords on the command line is not really a good idea, as already mentioned.
But: you can usually (it is OS-dependent) change the name that is shown by ps by assigning to $0.
e.g. (tested on Linux)
$ cat secret.pl
#!/usr/bin/perl
$0 = "my secret perl script";
sleep 15;
$ ./secret.pl -p foobar &
[2] 426
$ ps a | grep perl
426 pts/0 S 0:00 my secret perl script
428 pts/0 S+ 0:00 grep perl
See the section on $0 in the perlvar manpage for details.
There are a couple of ways to go. The most immediate is to (like sidyll says) prompt for the password in the actual script. Don't put in on the command line, and you won't have to hide it.
Another option is a private password file. This file can be read through shell interpolation, but it's still kind of a kludge.
You could add a bit more flexibility to the private password file by wrapping your script in a "launcher" script. Essentially, you write a script whose sole purpose is to "set up" the password file, and then launch your real script.