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

RHEL/AL2 init script no longer works with forever v4.0.3 #105

Closed
mmrwoods opened this issue Jan 31, 2022 · 3 comments
Closed

RHEL/AL2 init script no longer works with forever v4.0.3 #105

mmrwoods opened this issue Jan 31, 2022 · 3 comments

Comments

@mmrwoods
Copy link

Forever version 4.0.3 changes the output from forever --plain list slightly which breaks the init script generated by forever-service because the regex to parse the output and determine the status of running services no longer works.

With forever v4.0.2, forever --plain list generates output like this:

info:    Forever processes running
data:        uid        command       script  forever pid  id logfile                 uptime
data:    [0] contentapi /usr/bin/node bin/www 7873    7927    /var/log/contentapi.log 75:20:4:18.05599999986589

With forever v4.0.3, forever --plain list generates output like this:

info:    Forever processes running
data:undefined    uid        command       script  forever pid  id logfile                 uptime
data:undefined[0] contentapi /usr/bin/node bin/www 8044    8113    /var/log/contentapi.log 0:0:16:20.09299999999996

That undefined after data: breaks the init script created by forever-service as it relies on a regex matching whitespace after data: to identify running services.

I've reported this to the author of the relevant PR which introduced the change at foreversd/forever#1128 (comment) and it has been acknowledged as an issue, but that does not necessarily mean a fix is imminent.

In the meantime, I have pinned forever to version 4.0.2, but maybe the status regex in the init script generated by forever-service should be updated though to look for a sequence of characters not matching [ rather than one or more spaces? (having said that, this is code I'm not really familiar with, it's just an issue I ran into earlier today, so I might be missing some obvious constraints here)

@arvind-agarwal
Copy link
Contributor

Thanks @mmrwoods for reporting the issue here. But it is better to fix forever bug instead of making changes in this repo in this case.

@arvind-agarwal
Copy link
Contributor

If changes are needed after fixing forever bug certainly i will consider it.

@mmrwoods
Copy link
Author

mmrwoods commented Feb 4, 2022

Thanks @arvind-agarwal, looks like it will get fixed on forever soon.

P.S. Sorry about delay following up, just a busy few days.

@mmrwoods mmrwoods closed this as completed Feb 4, 2022
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

2 participants