0001246: services.chk check is not always accurate

(0006479)
DukePyrolator (administrator)
2013-06-18 16:09

is the fix working? can we commit it to the stable and the devel branch?

(0006232)
cronus (developer)
2012-07-24 08:54

I've gotten hit by this odd bug randomly on and off for a few years. I'm now trying the patch on *nix Debian Squeeze 64bit to be exact. Will report any issues I find.

(0006155)
Viper (manager)
2012-06-08 10:31

Got hit by this again out of the blue recently..

I'm attaching a patch by Jeremy which I am testing now on BSD. If anyone is up to it testing it on *nix.. :)

I will try this for a bit to make sure it doesn't blow up and if no one has any remarks, it will be committed..

(0006058)
chaz (administrator)
2012-01-07 08:29

I wouldn't do it this way, pidof will return by default all processes by that name owned by any user.

eg.

chaz@scooby:~$ ps aux | grep bash
chaz 27748 0.0 0.0 28248 5688 pts/1 Ss Jan03 0:00 /bin/bash
chaz 7189 0.0 0.0 28220 5656 pts/0 Ss 05:49 0:00 bash
chaz 7244 0.0 0.0 28256 5740 pts/2 Ss 05:49 0:00 bash
chaz 7960 0.5 0.0 28220 5660 pts/3 Ss 06:27 0:00 bash
root 7939 0.0 0.0 25032 2420 pts/2 S 06:27 0:00 bash
root 7949 0.0 0.0 25028 2200 pts/2 S+ 06:27 0:00 bash

chaz@scooby:~$ pidof bash
27748 7960 7949 7939 7244 7189

I think using the full path for the services binary would be better place first of all.

From the manpage

       When pidof is invoked with a full pathname to the program it should find the pid of, it is reasonably safe. Otherwise it is possible that it returns pids of running programs that happen to have
       the same name as the program you're after but are actually other programs. Note that that the executable name of running processes is calculated with readlink(2), so symbolic links to executables
       will also match.

(0006057)
DukePyrolator (administrator)
2012-01-07 08:22

Phantomal suggests to use following script:

#! /bin/bash
while true
do
PID1=$(pidof services)
if (( PID1 < 1 ))
then
./services
fi
sleep 20
done

(used by orion services)

is "pidof" available in all *NIX and *BSD distributions?

(0005836)
DjSlash (reporter)
2011-06-05 15:40

What I meant, it isn't possible with a normal usercase. In the case of root being the one who is running de services or when someone uses the configure script to have special permissions, it would require the user to adjust the script accordingly. In that case the user is responsible, since it is his choice to make a different approach using the services.

The example.chk file should be a good example for usage in a normal case. The current example.chk file has some flaws and I think it should be fixed.

(0005787)
katsklaw (reporter)
2011-04-10 22:42

DJSlash said: "it isn't possible to run the services as a different user, so we don't need to consider it"

This isn't true. UID 0 (root) can run any program set as executable. Additionally during ./Config, octal permissions can be altered to allow other users to execute Anope. I can only imagine this useful on a dedicated box where SRA's have separate logins and exec Anope. Regardless, it's possible and Anope supports it.

(0005773)
DjSlash (reporter)
2011-03-21 23:05

Regarding the uid check: it isn't possible to run the services as a different user, so we don't need to consider it. Checking for the uid gives us a better result when the script is run on a shared shell server.

Here's the diff between my version and the shipped one:

< ANOPID=$(cat $ANOPIDF)
< if [ $(pgrep -u $(id -u) -f "$ANOPROG $ANOARGS" | grep -cx $ANOPID) = 1 ]
---
> ANOPID=`cat $ANOPIDF`
> if [ `ps auwx | grep $ANOPROG | grep $ANOPID | grep -v -c grep` = 1 ]

I also found out that if the services are started directly without arguments, it starts and when it finds out that it can't link, it dies and removes the pidfile. When this occurs and the check script is run by cron, it can't find the pidfile and chaos begins. So I recon it would better to have the services require at least one argument or have a check on the pidfile itself.

(0005763)
DjSlash (reporter)
2011-03-14 14:46

I think it requires further investigation, because couple of days ago the services.pid was suddenly lost and I'm not sure if it was due the services.chk cronjob. Guess I need to make it verbose for a while. I've checked the script again at that time and figured that if you have the crontab running as an other user (not a common way, but still), it can't find the process. So you might want to remove the "-u $(id -u)" part (searches for processes with matching uid).

Adding "-x" to the grep command could be another improvement:

djslash@echoes:~$ cat bla
01234
1234
12345
djslash@echoes:~$ grep -c 1234 bla
3
djslash@echoes:~$ grep -cx 1234 bla
1

With pgrep you could add "-f" to check for the commandline (which in our case is: "./services -logchan"):
drlnet@miriel:~/services$ pgrep -f 'services -logchan'
1436
drlnet@miriel:~/services$ cat services.pid
1436

You can ask me on #anope too, I'm there as slush

(0005762)
chaz (administrator)
2011-03-13 09:22

Hello,

I'm reviewing this bug.

Are you saying with the change you made all is well or does this require further investigation?

Regards,

Charles

Issue History
Date Modified	Username	Field	Change
2011-02-17 12:15	DjSlash	New Issue
2011-03-13 09:21	chaz	Assigned To	=> chaz
2011-03-13 09:21	chaz	Status	new => assigned
2011-03-13 09:22	chaz	Note Added: 0005762
2011-03-14 14:46	DjSlash	Note Added: 0005763
2011-03-21 23:05	DjSlash	Note Added: 0005773
2011-04-10 22:42	katsklaw	Note Added: 0005787
2011-06-05 15:40	DjSlash	Note Added: 0005836
2011-07-13 04:33	katsklaw	Note Added: 0005868
2011-07-13 04:36	katsklaw	Note Deleted: 0005868
2011-12-21 10:49	Viper	Assigned To	chaz =>
2012-01-07 08:22	DukePyrolator	Note Added: 0006057
2012-01-07 08:29	chaz	Note Added: 0006058
2012-06-08 10:31	Viper	Note Added: 0006155
2012-06-08 10:31	Viper	Assigned To	=> Viper
2012-06-08 10:31	Viper	Status	assigned => acknowledged
2012-06-08 10:32	Viper	File Added: crontab.patch
2012-07-24 08:54	cronus	Note Added: 0006232
2013-06-18 16:09	DukePyrolator	Note Added: 0006479
2013-06-18 16:09	DukePyrolator	Status	acknowledged => feedback

Notes
(0006479) DukePyrolator (administrator) 2013-06-18 16:09	is the fix working? can we commit it to the stable and the devel branch?

(0006232) cronus (developer) 2012-07-24 08:54	I've gotten hit by this odd bug randomly on and off for a few years. I'm now trying the patch on *nix Debian Squeeze 64bit to be exact. Will report any issues I find.

(0006155) Viper (manager) 2012-06-08 10:31	Got hit by this again out of the blue recently.. I'm attaching a patch by Jeremy which I am testing now on BSD. If anyone is up to it testing it on *nix.. :) I will try this for a bit to make sure it doesn't blow up and if no one has any remarks, it will be committed..

(0006058) chaz (administrator) 2012-01-07 08:29	I wouldn't do it this way, pidof will return by default all processes by that name owned by any user. eg. chaz@scooby:~$ ps aux \| grep bash chaz 27748 0.0 0.0 28248 5688 pts/1 Ss Jan03 0:00 /bin/bash chaz 7189 0.0 0.0 28220 5656 pts/0 Ss 05:49 0:00 bash chaz 7244 0.0 0.0 28256 5740 pts/2 Ss 05:49 0:00 bash chaz 7960 0.5 0.0 28220 5660 pts/3 Ss 06:27 0:00 bash root 7939 0.0 0.0 25032 2420 pts/2 S 06:27 0:00 bash root 7949 0.0 0.0 25028 2200 pts/2 S+ 06:27 0:00 bash chaz@scooby:~$ pidof bash 27748 7960 7949 7939 7244 7189 I think using the full path for the services binary would be better place first of all. From the manpage When pidof is invoked with a full pathname to the program it should find the pid of, it is reasonably safe. Otherwise it is possible that it returns pids of running programs that happen to have the same name as the program you're after but are actually other programs. Note that that the executable name of running processes is calculated with readlink(2), so symbolic links to executables will also match.

(0006057) DukePyrolator (administrator) 2012-01-07 08:22	Phantomal suggests to use following script: #! /bin/bash while true do PID1=$(pidof services) if (( PID1 < 1 )) then ./services fi sleep 20 done (used by orion services) is "pidof" available in all NIX and BSD distributions?

(0005836) DjSlash (reporter) 2011-06-05 15:40	What I meant, it isn't possible with a normal usercase. In the case of root being the one who is running de services or when someone uses the configure script to have special permissions, it would require the user to adjust the script accordingly. In that case the user is responsible, since it is his choice to make a different approach using the services. The example.chk file should be a good example for usage in a normal case. The current example.chk file has some flaws and I think it should be fixed.

(0005787) katsklaw (reporter) 2011-04-10 22:42	DJSlash said: "it isn't possible to run the services as a different user, so we don't need to consider it" This isn't true. UID 0 (root) can run any program set as executable. Additionally during ./Config, octal permissions can be altered to allow other users to execute Anope. I can only imagine this useful on a dedicated box where SRA's have separate logins and exec Anope. Regardless, it's possible and Anope supports it.

(0005773) DjSlash (reporter) 2011-03-21 23:05	Regarding the uid check: it isn't possible to run the services as a different user, so we don't need to consider it. Checking for the uid gives us a better result when the script is run on a shared shell server. Here's the diff between my version and the shipped one: < ANOPID=$(cat $ANOPIDF) < if [ $(pgrep -u $(id -u) -f "$ANOPROG $ANOARGS" \| grep -cx $ANOPID) = 1 ] --- > ANOPID=`cat $ANOPIDF` > if [ `ps auwx \| grep $ANOPROG \| grep $ANOPID \| grep -v -c grep` = 1 ] I also found out that if the services are started directly without arguments, it starts and when it finds out that it can't link, it dies and removes the pidfile. When this occurs and the check script is run by cron, it can't find the pidfile and chaos begins. So I recon it would better to have the services require at least one argument or have a check on the pidfile itself.

(0005763) DjSlash (reporter) 2011-03-14 14:46	I think it requires further investigation, because couple of days ago the services.pid was suddenly lost and I'm not sure if it was due the services.chk cronjob. Guess I need to make it verbose for a while. I've checked the script again at that time and figured that if you have the crontab running as an other user (not a common way, but still), it can't find the process. So you might want to remove the "-u $(id -u)" part (searches for processes with matching uid). Adding "-x" to the grep command could be another improvement: djslash@echoes:~$ cat bla 01234 1234 12345 djslash@echoes:~$ grep -c 1234 bla 3 djslash@echoes:~$ grep -cx 1234 bla 1 With pgrep you could add "-f" to check for the commandline (which in our case is: "./services -logchan"): drlnet@miriel:~/services$ pgrep -f 'services -logchan' 1436 drlnet@miriel:~/services$ cat services.pid 1436 You can ask me on #anope too, I'm there as slush

(0005762) chaz (administrator) 2011-03-13 09:22	Hello, I'm reviewing this bug. Are you saying with the change you made all is well or does this require further investigation? Regards, Charles

Relationships