ps call missing processes in Yocto - process

I'm trying to report on running processes in Yocto (Poky). ps aux doesn't work here, but standard ps call return much of what aux would in Debian. But it won't report my .sh script processes. Is there an argument that works here, or another call I can try? Thanks in advance.

You are probably using busybox. Busybox contains its own version of ps and might not have support for the flags you're using. A simple ls -l /bin/ps should give you indications whether or not it's symlinked to busybox or not.
My suggestion would be to include the package procps in your recipe (which contains the ps you're more familiar with).

Busybox ps should show you all your processes.
I've created this test script, pstest.sh:
#!/bin/sh
while true; do
sleep 10;
done
Which I've been running, both on a Debian box, aon a qemux86 based core-image-minimal, and on a custom embedded device built with OpenEmbedded / Yocto. (I.e. the last one is not running the Yocto kernel). On all of these devices, the following holds true:
# ./pstest.sh &
# ps
PID USER VSZ STAT COMMAND
1 root 4196 S {systemd} /sbin/init
2 root 0 SW [kthreadd]
3 root 0 SW [ksoftirqd/0]
5 root 0 SW< [kworker/0:0H]
.....
633 root 2452 S {pstest.sh} /bin/sh ./pstest.sh
634 root 2732 S sleep 10
638 root 3044 R ps
As you can see, I'm seeing the script process, as well as the sleep command. (Note: on Debian ps above has been replaced with busybox ps).
If you still can only see the sleep, could you try the following:
# cat /proc/`pidof sleep`/status | grep PPid
PPid: 633
By running that line, you should be able to see the parent PID of the sleep command; check which process that corresponds to.

Related

monitor bash script execution using monit

We have just started using monit for process monitor and pretty much new in monit. I have a bash script at /home/ubuntu/launch_example.sh. This is continuously running. is it possible to monitor this using monit? monit should start the script if it bash scripts terminates. What should be syntax.I tried below syntax but all the commands are not being executed as ubuntu user, like shell script calls some python scripts.
check process launch_example
matching "launch_example"
start program = "/bin/bash -c '/home/ubuntu/launch_example.sh'"
as uid ubuntu and gid ubuntu
stop program = "/bin/bash -c '/home/ubuntu/launch_example.sh'"
as uid ubuntu and gid ubuntu
The simple answer is "no". Monit is just for monitoring and is not some kind of supervisor/process manager. So if you want to monitor your long running executable, you have to wrap it.
check process launch_example with pidfile /run/launch.pid
start program = "/bin/bash -c 'nohup /home/ubuntu/launch_example.sh &'"
as uid ubuntu and gid ubuntu
stop program = "/bin/bash -c 'kill $(cat /run/launch.pid)'"
as uid ubuntu and gid ubuntu
This quick'n'dirty way also needs an additional line for your launch_example.sh to write the pidfile (pidfile matching should always be preferred over string matching) - it could be just the first line after she shebang. It simply writes the current process ID to the pidfile. Nothing fancy here ;)
echo $$ > /run/launch.pid
In fact, it's not even hard to convert your script into a systemd unit. Here is an example on how to. User binding, restarts, pidfile, and "start-on-boot" can then be managed through systemd (eg. start program = "/usr/bin/systemctl start my_unit").

Reindexing Zebra Because there are no results found in opac and intranet search in KOHA Integrated Library System

I have a freshly installed Koha 3.16 in a Debian Server. I already imported the MARC records into the catalog, but when I search it on Opac , there is no results found.
I read this link: My Zebra Indexing won’t work! How do I fix it? (AKA: I search for stuff and nothing comes up! Help!)
I have tried to follow what has been said in this link. But unfortunately Im stuck with the third step.
export PERL5LIB=/usr/share/koha/lib
export KOHA_CONF=/usr/share/koha/koha-conf.xml
/usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x
I run this commands, but still, no luck. I tried to rebuild zebra using the command:
sudo koha-rebuild-zebra -f -v mylibrary
The result shows:
Zebra configuration information
================================
Zebra biblio directory = /var/lib/koha/mylibrary/biblios
Zebra authorities directory = /var/lib/koha/mylibrary/authorities
Koha directory = /usr/share/koha/intranet/cgi-bin
Lockfile = /var/lock/koha/mylibrary/rebuild/rebuild..LCK
BIBLIONUMBER in : 999$c
BIBLIOITEMNUMBER in : 999$d
================================
skipping authorities
====================
exporting biblio
====================
Records exported: 7922
====================
REINDEXING zebra
====================
18:04:12-13/11 zebraidx(8862) [warn] zebra_lock_create fail fname=/var/lock/koha/mylibrary/biblios/norm..LCK [No such file or directory]
18:04:12-13/11 zebraidx(8862) [warn] zebra_lock_create fail fname=/var/lock/koha/mylibrary/biblios/shadow..LCK [No such file or directory]
18:04:12-13/11 zebraidx(8862) [fatal] Could not select database biblios errCode=109
18:04:12-13/11 zebraidx(8863) [warn] zebra_lock_create fail fname=/var/lock/koha/mylibrary/biblios/norm..LCK [No such file or directory]
18:04:12-13/11 zebraidx(8863) [warn] zebra_lock_create fail fname=/var/lock/koha/mylibrary/biblios/shadow..LCK [No such file or directory]
18:04:12-13/11 zebraidx(8863) [fatal] Could not select database biblios errCode=109
====================
CLEANING
====================
Zebra configuration information
================================
Zebra biblio directory = /var/lib/koha/mylibrary/biblios
Zebra authorities directory = /var/lib/koha/mylibrary/authorities
Koha directory = /usr/share/koha/intranet/cgi-bin
Lockfile = /var/lock/koha/mylibrary/rebuild/rebuild..LCK
BIBLIONUMBER in : 999$c
BIBLIOITEMNUMBER in : 999$d
================================
====================
exporting authority
====================
Records exported: 0
====================
REINDEXING zebra
====================
skipping biblios
====================
CLEANING
====================
Whats wrong with reindexing Zebra? How will I fix it? I found a problem same with me, but honestly I dont get how to apply a Patch.Here's the link:
zebraidx errCode=109
Please fix it. I really have to get this working.
Happened the same when install koha in Centos. Try:
Koha-rebuild-zebra -f -v -b mylibrary
You can use these lines to restart the search tables.
sudo zebraidx -c /etc/koha/sites/library/zebra-biblios.cfg drop biblios
sudo zebraidx -c /etc/koha/sites/library/zebra-biblios.cfg commit
koha-rebuild-zebra -b -r -v mylibrary
Finally: Try to change the parameter SearchEngine in the preferences section. Zebra to Solr.
Other parameters (source):
-f, --full Does a reindex of the whole collection. Will run even if USE_INDEXER_DAEMON=yes.
-a, --authorities Only run the indexing process for authority records.
-b, --biblios Only run the indexing process for biblio records.
-q, --quiet Sometimes be a bit quieter for scripts/cronjobs.
-v, --verbose Be verbose. Useful for debugging indexing problems.
Hi your all previous step looks great
after all the above steps as followed by user till /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -r -v -x looks fine
after that you give the following command
zebrasrv -f /path/to/the.KOHA_CONF file i.e xml file which should run in background process else if you get logout indexing also go off
I have a similar problem, zebraserv seems to exit randomly. The log is not much help, as it does not capture what caused the crash. The symptom is that searches don't work. I found that restarting koha fixes the issue. However restarting all the time is not ideal. Some investigation on my system ( Debian 8.3 with Koha 16.05.05.000 ) reveal that the zebraserv process dying is a symptom of the issue. I wrote this script to be run as a cron job ( for root ) that runs every 60 seconds. This appears to make it recover. It seems to happen once every few days.
This has been happening in the last few releases of koha-common via Debian apt-get
I called it /root/check_zebra.sh ..... it is
:
# Add this to cron i.e ( remove the leading "#" ) for root
# * * * * * /root/check_zebra.sh >> /root/check_zebra.log
#
ps ax | grep zebrasrv | grep koha-conf.xml > /dev/null
status=$?
if [ $status = "0" ]
then
:
else
# Restart
echo "============================================="
date
echo "zebrasrv has stopped. Restarting Koka..."
echo "/etc/init.d/koha-common restart"
/etc/init.d/koha-common restart
fi

Why doesn't setting the SUID bit in OpenBSD set effective and saved UIDs to executable file owner?

I am using a fresh install of OpenBSD 5.3 as a guest OS on Parallels for Mac:
$ uname -a
OpenBSD openbsd.localdomain 5.3 GENERIC#53 amd64
To my surprise, a binary file owned by root with its SUID bit set runs with UIDs as if the SUID was not set. That is, when UID 1000 runs such a program, the program starts in state:
<real_uid, effective_uid, saved_uid> = <1000, 1000, 1000>
and not in state:
<real_uid, effective_uid, saved_uid> = <1000, 0, 0>
as expected.
Why is this the case?
Here are the details regarding how I found the issue:
I have written an interactive C program (compiled as setuid_min.bin) for evaluating setuid behaviour in different Unix systems. The program lives in a subdirectory of UID 1000's home directory, and the sudo command is used to change ownership and SUID; then the program is run and I enter the uid to report the real, effective, and saved UIDs of the process:
$ sudo chown root:staff setuid_min.bin
$ ls -l | grep 'setuid_min\.bin$'
-rwxr-xr-x 1 root staff [...] setuid_min.bin
$ sudo chmod a+s setuid_min.bin
$ ls -l | grep 'setuid_min\.bin$'
-rwsr-sr-x 1 root staff [...] setuid_min.bin
$ ./setuid_min.bin
uid
1000 1000 1000 some_pid
exit
$
Note that some_pid above is the pid of the setuid_min.bin process. The program reports the real UID, effective UID, and saved UID by reporting the output of the following shell command:
ps -ao ruid,uid,svuid,pid | grep '[ ]my_pid$'
where my_pid is the pid is reported by getpid(). My only guess as to why this might be the case is that OpenBSD has some underlying permissions structure that is using the ownership/permissions of the directory where setuid_min.bin resides, or that is not actually changing ownership/SUID bit when an unprivileged user uses sudo to change file permissions.
Most likely your binary is in one of the default partitions that are mounted "nosuid". The default fstab the install script creates will by mount everything nosuid unless it's known to contain suid binaries.

ROR + A server is already running. Check .../tmp/pids/server.pid. Exiting

In my Rails Project, I am trying to run two different servers at different port. But it fails by giving this error at console.
C:\Rails>rails s
=> Booting Mongrel
=> Rails 3.1.1 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
A server is already running. Check C:/Rails/tmp/pids/server.pid.Exiting
Please check the updated answer.
After googling a lot, I just delete that file and restart the server. Then again system create that file, then again I delete that file. Now Server is running fine. And System generates another copy at the same place. But it is running well.
DELETE THAT FILE ....
If you want to run two servers then it may again create trouble. So
Both commands are checking the default PID file location (tmp/pids/server.pid), so you're seeing this error. Try running multiple servers like so:
Server 1: bundle exec rails s
Server 2: bundle exec rails s -p 3001 -P tmp/pids/server2.pid
Credit: https://stackoverflow.com/a/14446920/1376448
Thanks
UPDATE after Connor Leech comment about Forman Gem
Foreman can help manage multiple processes that your Rails app depends
upon when running in development. It also provides an export command
to move them into production.
You can use netstat to know which process is holding the rails webserver, then you can kill the pid and start it over again, assuming that for some weird reason the server is not responding or running in background and you don't find another way to restart it..
netstat -plntu | grep 3000
tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN 7656/ruby
The last column shows the PID and the process name, then you only need to do:
kill -9 7656
and rails s to get it working again...
Hope it's useful
I find myself coming back to this webpage a lot to find the lsof -wni tcp:3000 command so I've found this method to be easier.
If you get this message:
A server is already running. Check /Users/username/project/tmp/pids/server.pid.
Exiting
And if you're running on a unix system (mac or linux) you can run these commands:
$ cat /Users/username/project/tmp/pids/server.pid
# output
71030
# Kill the process
$ kill -9 71030
Then run your server again!
I deleted the file with cd'ing in to the tmp directory then removing the file
rm server.pid
Then I restarted the server and I got this error
Exiting/Users/josephmellin/.rvm/rubies/ruby-2.1.1/lib/ruby/2.1.0/socket.rb:206:in `bind': Address already in use - bind(2) for 0.0.0.0:3000 (Errno::EADDRINUSE)
Then I could use the following command to see which process is running.
sudo lsof -iTCP -sTCP:LISTEN -P | grep :3000
And after I entered my password, I got this resoponse
ruby 2786 josephmellin 12u IPv4 0xfeadd8ae849eaec9 0t0 TCP *:3000 (LISTEN)
And then killed the process with the following command
KILL -9 2786
And then restarted the server (you will have a different number than 2786 - I left it here for demo purposes)
Step 1: remove .pid
C:/Rails/tmp/pids/server.pid.Exiting
# IN linux/unix shell
$ rm -rf <path to file>
Sometime this doesn't solve the problem, then you have to kill the process running by localhost, for such cases, follow STEP 2
STEP 2: List the process for localhost and kill it
# For Linux/Unix shell
$ lsof -wni tcp:3000
# output
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
ruby 5946 rails 11u IPv4 79073 0t0 TCP *:3000 (LISTEN)
ruby 5946 rails 12u IPv4 103786 0t0 TCP 127.0.0.1:3000->127.0.0.1:53612 (ESTABLISHED)
# Kill the running process
$ kill -9 5946
run your server again
rails server
ps aux | grep rails
or
bundle exec rails s -p 3001 -P tmp/pids/server2.pid
Every instance of a RoR server creates a PID file. By default it is
#{Rails.root}/tmp/pids/server.pid
and if that file already exists it will refuse to start a new server.
To run more than one server of the same project on the same machine you should manually specify the PID file name for each instance of the server (I recommend simply appending a hyphen and the port number) using the -P option:
rails s -p 1234 -P tmp/pids/server-1234.pid
I'm told in some cases you may need to supply a full (rather than relative) path, but I don't know what those cases are.
You can see the PID for each proccess(the first column) :
ps vax | grep rails
// OR: ps auxw | grep rails
5236 pts/1 Sl+ 1:46 2 0.2 /usr/bin/ruby1.9.1 script/rails s -p 3001
5298 pts/2 Sl+ 0:12 2 0.7 /usr/bin/ruby1.9.1 script/rails s -p 3003
7356 pts/5 Sl+ 0:09 2 0.9 /usr/bin/ruby1.9.1 script/rails s -p 3002
7846 pts/3 Sl+ 0:19 2 1.7 /usr/bin/ruby1.9.1 script/rails s
Then kill the server:
kill -9 <pid>
To kill all running apps with "rails" in the name:
killall -9 rails
Use rails default commands, for example:
rake tmp:clear
Works for me, and really simple. ;)
single line command, that will take care of it.
kill -9 $(more C:/Rails/tmp/pids/server.pid)
I just had this problem, just deleted server.pid file and server works fine!
Remove that file: C:/Rails/tmp/pids/server.pid
A simpler way in which I found lesser commands . Go to the path which says a server is running in your folder structure . Search for the file. On the file itself shows a number which is the process id that is currently running. Lets say if the number is 'x', then simply type this command into your terminal
kill -9 x
However, note that this works in Ubuntu. Not sure, if it works in other OS as well.
Try to change the number in the pid file to another and save it.

How to shorten an inittab process entry, a.k.a., where to put environment variables that will be seen by init?

I am setting up a Debian Etch server to host ruby and php applications with nginx. I have successfully configured inittab to start the php-cgi process on boot with the respawn action. After serving 1000 requests, the php-cgi worker processes die and are respawned by init. The inittab record looks like this:
50:23:respawn:/usr/local/bin/spawn-fcgi -n -a 127.0.0.1 -p 8000 -C 3 -u someuser -- /usr/bin/php-cgi
I initially wrote the process entry (everything after the 3rd colon) in a separate script (simply because it was long) and put that script name in the inittab record, but because the script would run its single line and die, the syslog was filled with errors like this:
May 7 20:20:50 sb init: Id "50" respawning too fast: disabled for 5 minutes
Thus, I got rid of the script file and just put the whole line in the inittab. Henceforth, no errors show up in the syslog.
Now I'm attempting the same with thin to serve a rails application. I can successfully start the thin server by running this command:
sudo thin -a 127.0.0.1 -e production -l /var/log/thin/thin.log -P /var/run/thin/thin.pid -c /path/to/rails/app -p 8010 -u someuser -g somegroup -s 2 -d start
It works apparently exactly the same whether I use the -d (daemonize) flag or not. Command line control comes immediately back (the processes have been daemonized) either way. If I put that whole command (minus the sudo and with absolute paths) into inittab, init complains (in syslog) that the process entry is too long, so I put the options into an exported environment variable in /etc/profile. Now I can successfully start the server with:
sudo thin $THIN_OPTIONS start
But when I put this in an inittab record with the respawn action
51:23:respawn:/usr/local/bin/thin $THIN_OPTIONS start
the logs clearly indicate that the environment variable is not visible to init; it's as though the command were simply "thin start."
How can I shorten the inittab process entry? Is there another file than /etc/profile where I could set the THIN_OPTIONS environment variable? My earlier experience with php-cgi tells me I can't just put the whole command in a separate script.
And why don't you call a wrapper who start thin whith your options?
start_thin.sh:
#!/bin/bash
/usr/local/bin/thin -a 127.0.0.1 -e production -l /var/log/thin/thin.log -P /var/run/thin/thin.pid -c /path/to/rails/app -p 8010 -u someuser -g somegroup -s 2 -d start
and then:
51:23:respawn:/usr/local/bin/start_thin
init.d script
Use a script in
/etc/rc.d/init.d
and set the runlevel
Here are some examples with thin, ruby, apache
http://articles.slicehost.com/2009/4/17/centos-apache-rails-and-thin
http://blog.fiveruns.com/2008/9/24/rails-automation-at-slicehost
http://elwoodicious.com/2008/07/15/nginx-haproxy-thin-fastcgi-php5-load-balanced-rails-with-php-support/
Which provide example initscripts to use.
edit:
Asker pointed out this will not allow respawning. I suggested forking in the init script and disowning the process so init doesn't hang (it might fork() the script itself, will check). And then creating an infinite loop that waits on the server process to die and restarts it.
edit2:
It seems init will fork the script. Just a loop should do it.