Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Init script fails when other processes contain $PGREP_PATTERN #318

Open
adoom42 opened this issue Jul 13, 2020 · 0 comments
Open

Init script fails when other processes contain $PGREP_PATTERN #318

adoom42 opened this issue Jul 13, 2020 · 0 comments

Comments

@adoom42
Copy link

adoom42 commented Jul 13, 2020

How to reproduce (e.g Puppet code you use)

Puppet attempts to start the service on every run. Trying to start/stop/status the service manually fails.

What are you seeing

# service kafka status
ERROR: Process ID list syntax error.
********* simple selection *********  ********* selection by list *********
-A all processes                      -C by command name
-N negate selection                   -G by real group ID (supports names)
-a all w/ tty except session leaders  -U by real user ID (supports names)
-d all except session leaders         -g by session OR by effective group name
-e all processes                      -p by process ID
                                      -q by process ID (unsorted & quick)
T  all processes on this terminal     -s processes in the sessions given
a  all w/ tty, including other users  -t by tty
g  OBSOLETE -- DO NOT USE             -u by effective user ID (supports names)
r  only running processes             U  processes for specified users
x  processes w/o controlling ttys     t  by tty
*********** output format **********  *********** long options ***********
-o,o user-defined  -f full            --Group --User --pid --cols --ppid
-j,j job control   s  signal          --group --user --sid --rows --info
-O,O preloaded -o  v  virtual memory  --cumulative --format --deselect
-l,l long          u  user-oriented   --sort --tty --forest --version
-F   extra full    X  registers       --heading --no-heading --context
                                      --quick-pid
                    ********* misc options *********
-V,V  show version      L  list format codes  f  ASCII art forest
-m,m,-L,-T,H  threads   S  children in sum    -y change -l format
-M,Z  security data     c  true command name  -c scheduling class
-w,w  wide output       n  numeric WCHAN,UID  -H process hierarchy
/etc/init.d/kafka: line 92: [: too many arguments
kafka stopped but pid file exists

Any additional information you'd like to impart

The PID file contains multiple lines, which is why the init script can't handle it as expected.

# cat /var/run/kafka.pid
10883
74772
77607
83267
83638
89484

Looking at commit e1845eb, the init script was modified to detect the PID in a different way.

Old way:

PID=`pgrep -f "$PGREP_PATTERN"`

New way:

PID=`ps ax | grep -i "$PGREP_PATTERN" | grep -v grep | awk '{print $1}'`

At the beginning of the init script, PGREP_PATTERN is set to kafka.Kafka. With the old pgrep method, it works fine and returns only one result. However, with the new method, it returns multiple results because I happen to have some Java processes running that contain argument strings such as org.apache.kafka.kafka-clients-1.0.0.jar. The new init script thinks those are processes of the kafka daemon itself.

Possible fixes:

  • Revert to the old single-command pgrep method.
  • Continue using the new multi-command method, but remove the -i grep param so it is case sensitive. (That would cover my particular scenario, but it wouldn't cover similar scenarios where there are other processes containing the kafka.Kafka string.)
  • Find some other way to capture the PID when the process is started. This would be the most effective. Example: https://serverfault.com/questions/376086/how-to-get-the-pid-of-a-process-started-by-bin-su-c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant