forever list says "No forever processes running"

[yeldarby]

I'm starting a forever instance on server boot via root's crontab.

@reboot /usr/local/bin/forever start -w --watchDirectory /home/ubuntu/code/path/to/my/files /home/ubuntu/code/path/to/my/files/index.js

But although the script is running (I can hit the server via port 80) I can't get its logs or restart it or anything because forever doesn't recognize that it's running.

ubuntu@ip-10-168-82:~$ ps aux | grep forever
root       902  4.1  2.3 969836 39824 ?        Ssl  22:49   0:03 /usr/local/bin/node /usr/local/lib/node_modules/forever/bin/monitor /home/ubuntu/code/path/to/my/files/index.js
ubuntu    1165  0.0  0.0   8156   956 pts/0    S+   22:50   0:00 grep --color=auto forever
ubuntu@ip-10-168-82:~$ sudo forever list
info:    No forever processes running
ubuntu@ip-10-168-82:~$ forever list
info:    No forever processes running

It works properly if I run it directly using sudo forever... (I can see the process with sudo forever list) but when it runs from root's crontab on boot it gets lost somewhere.

[yeldarby]

Interestingly I was able to get it working by adding the @reboot... directive to my unprivileged user's crontab with a sudo prefix on the command (rather than adding it to root's crontab directly).

It seems there is a difference in running sudo forever and actually running forever as root. Both work but only one ends up registering on sudo forever list.

[chance-an]

I am having the same problem. I can even see the process id under /root/.forever/pids/ but forever list shows nothing

node -v v0.10.22
npm -v 1.3.14
forever: 0.10.11

[finian]

@chance-an Did you run forever list as root or sudo forever list as an unprivileged user? What does your forever start script look like in root's crontab?

[promiseofcake]

I have the same issue with the root user's own crontab -e, the global crontab in /etc/crontab, and the /etc/cron.daily/ script files. Interestingly enough I do not have this issue on RHEL, but do on my CentOs machines. On RHEL I am calling the same command from the root user's crontab and I can see the process with forever list as the root user

I am calling a bash script which then runs the forever command using full paths: /usr/local/bin/node /usr/local/bin/forever start [...]

[ralyodio]

I ran as sudo forever list and it still shows no processes running even though they are. I started it with sudo forever start

[promiseofcake]

You should probably try to run the forever list from / and see if you get an output. When I was running it from crontab it was placing the .forever folder in /.forever as opposed to ~/.forever or /root/.forever because I had not set the HOME=/root in the crontab file.

If it still does not work try to do a find / -type d -name ".forever" and see where it has created the folder. Navigate to the basename() of that result and run forever list and see if you get the output you are looking for.

[robertgroh]

I can confirm, that you have to be extra curious for your HOME environment variable at the moment (during the script) you start forever.
I had some layers of sudos and chroots and I had to override the HOME variable in the script, which use forever.

[dandv]

I've tried running forever list with sudo, from /, from the homedir of the user that launched the process - nothing. See #544.

[promiseofcake]

I replied in #544, in summary: try to use the -p switch to explicitly specify the path to the .forever folder.

[varas]

Same issue on a vagrant image:

Linux precise64 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

[catamphetamine]

+1

[wizzhard]

Same problem here, I start a daemon from a script generated with initdforever.
When I restart the computer I can see the forever monitored process, i can even use it but forever list fail to report it.
If I kill the process with
sudo pkill node (i can't do it from "sudo service webserver stop" as forever can't see it the process)
then start it again every thing goes fine.

[robertgroh]

As said early:

• Make sure your environment variable HOME is the same for all calls of forever,
• or use the -p switch, from promiseofcakes comment, to explicitly specify the path to the .forever folder.

I would consider this isssue as solved.

[nikitaeverywhere]

The same issue for me.

Server is up, but forever list does not output the process.

crontab -e (even with -p flag):
@reboot /usr/local/bin/forever -p /home/zitro/.forever start /root/web/run.js > /root/bootLog.txt

Contents of bootLog.txt:
^[[33mwarn^[[39m: --minUptime not set. Defaulting to: 1000ms
^[[33mwarn^[[39m: --spinSleepTime not set. Your script will exit if it does not stay up for at least 1000ms
^[[32minfo^[[39m: Forever processing file: ^[[90m/root/web/run.js^[[39m

Hope to hear any suggestions. Thanks.

[robertgroh]

Just a wild guess: You also have to use the -p flag for the list call: forever -p /home/zitro/.forever list
Also: Is there the file config.json in /home/zitro/.forever?

[nikitaeverywhere]

Thank for reply, @weemonger.

But server still run.

There's nothing unusual in config.json. Root is "/home/zitro/.forever" there and pidPath and sockPath have the save path + "/pids"/"sock"

[nikitaeverywhere]

OK, guys, I found a solution.

It is important to call forever list command by the user spawned the process. No -p key needed at all.

In my case, the user was root, so I need to call command from root user, but not from zitro, who also has admin privileges.

And also a funny thing (probably I just don't know what exactly sudo bash do?), take a look for this:

My solution:

1. crontab -e;
2. Add @reboot /usr/local/bin/forever start /root/web/run.js > /root/bootLog.txt;
3. Save & reboot;
4. sudo su;
5. forever list.

I think you should update docs with few words saying that it depends on user who issue the command.

Thank for you help.

[vandernorth]

In my case I had changed my $HOME variable for GIT.
I had changed it to /home/root putting the line export HOME=/home/root in /root/.bashrc. This confused forever.

If this is the issue in your case, try

1. su - (optional, just make sure you are logged in as the user who started the proces)
2. export HOME=/root
3. forever list
4. Normal process output is now generated.

Hope this helps!

[indexzero]

This is probably related to #544.

[bgerd]

In the case this helps anybody, I was having the same problem when starting forever in an init script ... and paying careful attention to $HOME when executing forever was the solution:

For my distro (openwrt), the root's $HOME environment variable hadn't yet been set to its final value (e.g defined in /etc/profile as /root). I also couldn't find a way to set /sbin/init's initial environment variables (e.g. no /etc/default/init) ... not that I felt safe changing any.

My hackish/workaround was to temporarily set $HOME to the root's final value just to execute forever start in the init script. Everything (e.g. forever list and forever stop) now works correclty from the command line.

[chrischalstrom]

This is happening to me as well, even with the -p flag set correctly. I am using Vagrant and Puppet to exec forever start ./myserver.js. I then ssh into the box, forever list and see that it reports nothing running, even though when I curl my socket, I get the expected output.

I have to sudo su - root and then forever list to see the forever process that got started up.

This post about using systemd to daemonize processes was useful for me: http://stackoverflow.com/a/28542093/1162865

[Gerst20051]

👍

[terry-permeance]

If using init.d scripts, pass in HOME:

sudo HOME=/var/cache/my-app -u my-user forever list

[indexzero]

Duplicate of #415.