View Issue Details

IDProjectCategoryView StatusLast Update
0001246Anope Stable (1.8.x series)Otherpublic2013-07-09 08:26
ReporterDjSlash Assigned ToViper  
Status feedbackResolutionopen 
Summary0001246: services.chk check is not always accurate
DescriptionOnce in while the services get started twice because the check in services.chk doesnt have the correct outcome. Because it removes the too, it starts over and over. This gets annoying, since you'll see several connection attempts.
Steps To ReproducePut the services.chk in your crontab and wait. It's bound to happen sooner or later.
Additional InformationI changed the check as followed (changed the obsolete usage of backticks too):

< if [ `ps auwx | grep $ANOPROG | grep $ANOPID | grep -v -c grep` = 1 ]
> if [ $(pgrep -u $(id -u) $ANOPROG | grep -c $ANOPID) = 1 ]
TagsNo tags attached.



2013-07-09 08:26

reporter   ~0006491

I've had this patch applied for a couple of weeks now and it failed on me a few days ago.

UnrealIRCd does their check by sending a SIGCHLD and comparing the return value, which might be a good way of doing it since I've never seen it fail on me.

Example from their ircdchk file:
  if `kill -CHLD $ircdpid >/dev/null 2>&1`; then
    # it's still going
    # back out quietly
    exit 0


2013-06-18 16:09

administrator   ~0006479

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


2012-07-24 08:54

developer   ~0006232

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.


2012-06-08 10:32


crontab.patch (436 bytes)   
diff --git a/data/example.chk b/data/example.chk
index 6f2a234..ecc481e 100644
--- a/data/example.chk
+++ b/data/example.chk
@@ -34,7 +34,7 @@ cd $ANOPATH
 if [ -f $ANOPIDF ]
        ANOPID=`cat $ANOPIDF`
-       if [ `ps auwx | grep $ANOPROG | grep $ANOPID | grep -v -c grep` = 1 ]
+       if [ `ps auwx | grep $ANOPROG | grep -v grep | awk '{print $2;}' | grep -c $ANOPID` = 1 ]
crontab.patch (436 bytes)   


2012-06-08 10:31

manager   ~0006155

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..


2012-01-07 08:29

administrator   ~0006058

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


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.


2012-01-07 08:22

administrator   ~0006057

Phantomal suggests to use following script:

#! /bin/bash
while true
PID1=$(pidof services)
if (( PID1 < 1 ))
sleep 20

(used by orion services)

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


2011-06-05 15:40

reporter   ~0005836

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.


2011-04-10 22:42

reporter   ~0005787

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.


2011-03-21 23:05

reporter   ~0005773

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:

< if [ $(pgrep -u $(id -u) -f "$ANOPROG $ANOARGS" | grep -cx $ANOPID) = 1 ]
> 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.


2011-03-14 14:46

reporter   ~0005763

I think it requires further investigation, because couple of days ago the 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
djslash@echoes:~$ grep -c 1234 bla
djslash@echoes:~$ grep -cx 1234 bla

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'
drlnet@miriel:~/services$ cat

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


2011-03-13 09:22

administrator   ~0005762


I'm reviewing this bug.

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



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-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
2013-07-09 08:26 j883376 Note Added: 0006491