View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001246Anope Stable (1.8.x series)Otherpublic2011-02-17 12:152013-07-09 08:26
ReporterDjSlash Assigned ToViper  
PrioritylowSeverityminorReproducibilitysometimes
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 services.pid 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):

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

Activities

j883376

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
  fi

DukePyrolator

2013-06-18 16:09

administrator   ~0006479

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

cronus

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.

Viper

2012-06-08 10:32

manager  

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 ]
 then
        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 ]
        then
                exit    
        fi
crontab.patch (436 bytes)   

Viper

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

chaz

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.

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.

DukePyrolator

2012-01-07 08:22

administrator   ~0006057

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?

DjSlash

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.

katsklaw

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.

DjSlash

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:

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

DjSlash

2011-03-14 14:46

reporter   ~0005763

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

chaz

2011-03-13 09:22

administrator   ~0005762

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