# Service pid file is removed **URL:** \ **Category:** Elasticsearch\ **Created:** [February 8, 2012, 3:30pm UTC](https://discuss.elastic.co/t/service-pid-file-is-removed/6637 "2012-02-08T15:30:06Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Wes\_Plunk](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/wes_plunk/32/2446_2.png) [@Wes\_Plunk](https://discuss.elastic.co/u/Wes_Plunk)\ **Post date:** [February 8, 2012, 3:30pm UTC](https://discuss.elastic.co/t/service-pid-file-is-removed/6637/1 "2012-02-08T15:30:06Z")
If I have ES started via a service it seems that after a certain amount of time the file will be seen as stale and removed, even if the ES processes are still running. Can anyone explain why? The side affect of this is that after it's removed the ES service doesn't recognize itself as still running and will (when I submit a start request) start another node instance on the same server, creating a mess of extra nodes within the cluster. ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [February 9, 2012, 8:09am UTC](https://discuss.elastic.co/t/service-pid-file-is-removed/6637/2 "2012-02-09T08:09:13Z")
Are you using the Java service wrapper? On Wednesday, February 8, 2012 at 5:30 PM, Wes Plunk wrote: > If I have ES started via a service it seems that after a certain amount of time the file will be seen as stale and removed, even if the ES processes are still running. Can anyone explain why? > > The side affect of this is that after it's removed the ES service doesn't recognize itself as still running and will (when I submit a start request) start another node instance on the same server, creating a mess of extra nodes within the cluster. ---
**Author:** ![Wes\_Plunk](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/wes_plunk/32/2446_2.png) [@Wes\_Plunk](https://discuss.elastic.co/u/Wes_Plunk)\ **Post date:** [February 9, 2012, 3:43pm UTC](https://discuss.elastic.co/t/service-pid-file-is-removed/6637/3 "2012-02-09T15:43:12Z")
I believe I am. I downloaded/installed the service > **[elastic/elasticsearch-servicewrapper](https://github.com/elastic/elasticsearch-servicewrapper)** > > elasticsearch-servicewrapper - A service wrapper on top of elasticsearch and everything seems normal. This problem happened only once so far, so I'm not convinced it's a big issue or anything; however, I'm primarily trying to confirm how it should work in regards to stale pid files so that I can set expectations correctly on how to handle it ---
**Author:** ![Leif\_Maxfield](https://avatars.discourse-cdn.com/v4/letter/l/a4c791/32.png) [@Leif\_Maxfield](https://discuss.elastic.co/u/Leif_Maxfield)\ **Post date:** [March 11, 2014, 3:27pm UTC](https://discuss.elastic.co/t/service-pid-file-is-removed/6637/4 "2014-03-11T15:27:08Z")
I know that this thread is ancient, but I was experiencing this issue w/ the java service wrapper, so I wanted to document what I found in case others are seeing the same thing. In my case, it was deleting its own pid after startup because I am using a symlink for the current version of ES. In the getpid() function of the service wrapper in the 'else' of the 'case "$DIST\_OS' block (because I am using Linux), i asked it to echo the command it was using for pidtest: echo "$PSEXE -p $pid -o args | grep -F '$WRAPPER\_CMD' | tail -1" pidtest=`$PSEXE -p $pid -o args | grep -F "$WRAPPER_CMD" | tail -1` The output of a service start looks like this: $ sudo service elasticsearch start Starting Elasticsearch... Waiting for Elasticsearch...... /bin/ps -p 10468 -o args | grep -F '/es/elasticsearch-1.0.1/bin/service/exec/elasticsearch-linux-x86-64' | tail -1 running: PID:10468 /bin/ps -p 10468 -o args | grep -F '/es/live-version/bin/service/exec/elasticsearch-linux-x86-64' | tail -1 Removed stale pid file: /es/work/elasticsearch.pid I'm not sure why the first call to 'getpid' is using the "true" path while the second call is using the symlink, but this is causing the service wrapper to delete its own PID. One way around this, if you want to point your init script at a symlink, is to comment out all of the "ES\_HOME determination" stuff at the top of the script, and under it just set it manually: # Just set ES\_HOME statically rather than doing anything fancy. ES\_HOME="/es/live-version" Now, the execution of ES looks like this: $ sudo service elasticsearch start Starting Elasticsearch... Waiting for Elasticsearch...... /bin/ps -p 10744 -o args | grep -F '/es/live-version/bin/service/exec/elasticsearch-linux-x86-64' | tail -1 running: PID:10744 /bin/ps -p 10744 -o args | grep -F '/es/live-version/bin/service/exec/elasticsearch-linux-x86-64' | tail -1 And then it doesn't delete its own PID. One downside is you need to edit the script in this way each time you upgrade. On Thursday, February 9, 2012 9:43:12 AM UTC-6, Wes Plunk wrote: > I believe I am. I downloaded/installed the service > > [GitHub - elastic/elasticsearch-servicewrapper: A service wrapper on top of elasticsearch](http://github.com/elasticsearch/elasticsearch-servicewrapper) > > and everything seems normal. This problem happened only once so far, so > I'm not convinced it's a big issue or anything; however, I'm primarily > trying to confirm how it should work in regards to stale pid files so that > I can set expectations correctly on how to handle it -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/f585d1b4-10aa-48ce-b38c-fa77c1824ca2%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/f585d1b4-10aa-48ce-b38c-fa77c1824ca2%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\ **Post date:** [March 12, 2014, 10:14am UTC](https://discuss.elastic.co/t/service-pid-file-is-removed/6637/5 "2014-03-12T10:14:53Z")
Hey, can you create a github issue in the servicewrapper repo including an easy reproduction so this does not get lost in mailinglist traffic? Thanks a lot! --Alex On Tue, Mar 11, 2014 at 4:27 PM, Leif Maxfield [leif.maxfield@gmail.com](mailto:leif.maxfield@gmail.com)wrote: > I know that this thread is ancient, but I was experiencing this issue w/ > the java service wrapper, so I wanted to document what I found in case > others are seeing the same thing. In my case, it was deleting its own pid > after startup because I am using a symlink for the current version of ES. > > In the getpid() function of the service wrapper in the 'else' of the 'case > "$DIST\_OS' block (because I am using Linux), i asked it to echo the > command it was using for pidtest: > > echo "$PSEXE -p $pid -o args | grep -F '$WRAPPER\_CMD' | tail -1" > pidtest=`$PSEXE -p $pid -o args | grep -F "$WRAPPER_CMD" | tail -1` > > The output of a service start looks like this: > > $ sudo service elasticsearch start > Starting Elasticsearch... > Waiting for Elasticsearch...... > /bin/ps -p 10468 -o args | grep -F > '/es/elasticsearch-1.0.1/bin/service/exec/elasticsearch-linux-x86-64' | > tail -1 > running: PID:10468 > /bin/ps -p 10468 -o args | grep -F > '/es/live-version/bin/service/exec/elasticsearch-linux-x86-64' | tail -1 > Removed stale pid file: /es/work/elasticsearch.pid > > I'm not sure why the first call to 'getpid' is using the "true" path while > the second call is using the symlink, but this is causing the service > wrapper to delete its own PID. One way around this, if you want to point > your init script at a symlink, is to comment out all of the "ES\_HOME > determination" stuff at the top of the script, and under it just set it > manually: > > # Just set ES\_HOME statically rather than doing anything fancy. > > ES\_HOME="/es/live-version" > > Now, the execution of ES looks like this: > > $ sudo service elasticsearch start > Starting Elasticsearch... > Waiting for Elasticsearch...... > /bin/ps -p 10744 -o args | grep -F > '/es/live-version/bin/service/exec/elasticsearch-linux-x86-64' | tail -1 > running: PID:10744 > /bin/ps -p 10744 -o args | grep -F > '/es/live-version/bin/service/exec/elasticsearch-linux-x86-64' | tail -1 > > And then it doesn't delete its own PID. One downside is you need to edit > the script in this way each time you upgrade. > > On Thursday, February 9, 2012 9:43:12 AM UTC-6, Wes Plunk wrote: > > > I believe I am. I downloaded/installed the service > > > > [GitHub - elastic/elasticsearch-servicewrapper: A service wrapper on top of elasticsearch](http://github.com/elasticsearch/elasticsearch-servicewrapper) > > > > and everything seems normal. This problem happened only once so far, so > > I'm not convinced it's a big issue or anything; however, I'm primarily > > trying to confirm how it should work in regards to stale pid files so that > > I can set expectations correctly on how to handle it > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/f585d1b4-10aa-48ce-b38c-fa77c1824ca2%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/f585d1b4-10aa-48ce-b38c-fa77c1824ca2%40googlegroups.com)[https://groups.google.com/d/msgid/elasticsearch/f585d1b4-10aa-48ce-b38c-fa77c1824ca2%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/f585d1b4-10aa-48ce-b38c-fa77c1824ca2%40googlegroups.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAGCwEM-hUUzPzDAVTi8xv728Ob89o6ek5RLxPptXZR4mW97fTg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAGCwEM-hUUzPzDAVTi8xv728Ob89o6ek5RLxPptXZR4mW97fTg%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 1:43am UTC](https://discuss.elastic.co/t/service-pid-file-is-removed/6637/6 "2017-07-06T01:43:53Z")
Closed on July 6, 2017, 1:43am UTC