-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Startup Script reports ok
too fast, and doesn't wait for actual start of Jetty
#10473
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
Comments
I'm going to rip out the pgrep. |
Similar problem here, |
The only failure case is if So, if I revert Damned if you do, Damned if you don't. |
For those of you that are experiencing issues with no PID file ... Enable DEBUG logging for |
Opened PR #10501 to revert the new @ofrias @gskjold @l-cdc PR #10501 will need testing on your environment, as you all apparently have an unusual offshoot of a typical linux/unix/osx environment. (Our testing on our own systems, and the various official docker images do not manifest the issues you are reporting to us) |
It looks like in my case it is a different error. Jetty 10.0.15 starts fine:
But when upgrading my JETTY_HOME to Jetty 10.0.16 the script exits almost immediately and Jetty is not started (even though the script says "ok"):
I have added |
@joakime With the changes in you PR, the pid file is still empty I'm afraid.. |
There's no need to enable those modules manually when using the cd /path/to/my-jetty-base
java -jar /path/to/jetty-home/start.jar --list-config The output should indicate ...
|
Added this to my logback.xml, but cannot see anything in the log about it after:
I am using Amazon Linux 2 |
Strange. I am pretty sure we are using an unmodified - if somewhat old - RHEL7 image. In any case, it makes sense to It is unclear to me why the PID file would be empty for @gskjold. Could it be a permission issue? |
The fact that he sees no logs on |
The jetty instance is running as user "jetty". The file is updated at last start, but is empty: |
@gskjold what is the output of your |
Currently running with PID 3171 |
I was able to replicate the behavior you are seeing on amazon-linux with amazon-corretto using the following docker image ... https://github.com/joakime/jettysh-tests/blob/main/amazoncorretto/Dockerfile It doesn't run Note: the docker images don't use systemd or rc.d / init.d (as that's not really a concept for docker, and is generally discouraged in docker). |
Looks like the combination of amazon-linux + To see the debug of echo "org.eclipse.jetty.util.PidFile.LEVEL=DEBUG" >> /var/www/test/jetty-base/resources/jetty-logging.properties Now to setup a jetty user and attempt to start it from the root user. (like init.d would) |
Correct
Not entirely sure what you mean by that, but jetty.sh is softlinked into init.d:
I have added your change to logging properties:
And when I run
Then after a few seconds I get some WARNINGS which I think are unrelated to your issue, and has something to do with one of my applications:
Still nothing about PidFile in the logs... |
@gskjold based on your output of
This seems to indicate that you are not using a pristene Jetty 10.0.16 for your jetty-home directory. I say this because the output of that status call should show entries for There's some conflicting files in your JETTY_BASE as well.
Remove sfl4j-api, logback-core, logback-classic, and log4j-over-slf4j jars.
Because you are not using the module system ...
This configuration likely came from when you were using Java 8 and Jetty 9. Unpack a fresh copy of jetty-home, in a new directory, and use it (important: do not modify any contents in the jetty-home directory, consider it read-only). You'll need to ensure the following to test this new jetty-home.
If you still do not see a pid file, verify that your And verify that the output of |
@l-cdc I intentionally setup an environment which will trigger permissions issues with It will result in the following output, and will fail to start Jetty.
|
You are absolutely right about that, I have preserved too much of the original configuration from jetty-9.4. Thanks for pointing this out, I should have caught on to that... It is a good while back that I did the upgrade, but no errors have been thrown until the pgrep issue. Everything is working correctly now, together with the updated jetty.sh file from your PR. Thank you for a excellent followup on this issue! |
@gskjold @l-cdc it seems that both of you are happy with the changes in PR #10501, am I right in that assumption? @ofrias have you had a chance to test the updated Here's some links to the |
I can confirm from my side Just updated two servers (Running 9 instances of jetty in total) with the patched jetty.sh, and it they are all functioning as they should |
Hi. I don't think I have the same issue. In my case the How can I enable some kind of logging to see what's happening? By the way, I don't know if this is related to my issue or not, but Jetty 10.0.15 prints an uppercase OK:
whiel Jetty 10.0.16 prints a lowercase ok:
And this is because they are going through different execution paths in this code in jetty.sh:
It seems that |
That is a good point, I'll address this in PR #10501 too. |
@ofrias i've added a bunch of cleanup on jetty.sh to add DEBUG and clear messages on the state check and pid related behaviors. New SNAPSHOT tarball can be found at ... I've tested this SNAPSHOT successfully on the 3 docker images at https://github.com/joakime/jettysh-tests
No issues on ubuntu, fedora, and amazon-corretto. |
This is the output with the last SNAPSHOT:
While jetty.sh was trying to read the state file I did a ps and no java process was running:
So it looks like something fails during the start and the process ends without doing its job, there is no need to wait for more time because the process has already finished. With regard to JETTY_START_TIMEOUT, I have not manually configured it. It looks like 60 seconds is the default:
|
@ofrias there's no evidence of the Jetty side startup even being attempted. I'll need logs. First, remove any logs you have in
Then run your |
@ofrias separately, can you run your jetty.base without jetty.sh once to see if it can startup?
|
* Revert pgrep usage in jetty.sh * Adding test for jetty.conf * Correcting renamed xml file * Improved started check + Improved `started` function code - adding comment explaining steps - adding named parameters + Improved ARGS check for "jetty.state=" option, to know when to check the state file. * Make sure state.mod is before any deploy steps to ensure jetty-state file is created early. * Early cleanup / creation of State file * Improved `started` function + Don't attempt to read from State File if it doesn't exist + Don't attempt to read from PID File if it doesn't exist + DEBUG in state file logic + DEBUG in pid file logic + proper startsWith logic for state detection * Better state debugging and pid kill Signed-off-by: Joakim Erdfelt <[email protected]>
Same output in the console and nothing is written in
Yes, it starts successfully when running this command. This is the console output:
|
That log looks incomplete. BTW, The warning on jakarta.mail is discussed at jakartaee/mail-api#391 Something to think about. |
Sorry, logs continue on
|
Looks like the state file was created and had content put in it. Why can't the Can you try this from the command line, as the user running Jetty. (uid=1003, gid=1004).
It should return "Can Read" Also, try disabling the setuid module temporarily and see if the jetty.sh can start that Jetty instance. |
Yes, it returns "Can Read" and file permissions seem right:
I have disabled setuid module and the problem persists. Nothing is written on
|
You ran the Java command as root. (that's not a valid test) Please delete that |
Ah, you are running the old SNAPSHOT build. |
Building the SNAPSHOT is taking me a while, as I'm juggling too many thing right now. Meanwhile, can you do this on your environment and report back? $ cd /srv/www.myweb.com/jetty/
$ java -jar /usr/local/jetty-home-10.0.17-SNAPSHOT/start.jar jetty.state=/srv/www.myweb.com/jetty/jetty.state jetty.pid=/run/jetty/jetty.pid --module=pid,state --dry-run > dryrun.sh
$ source dryrun.sh I just want to eliminate the dry-run behavior as the possible culprit on your configuration. |
I think that we found the root cause. When running Jetty with this command and using
and that's because /run/jetty is owned by root: So I changed the directory ownership: and after that the Version I think that this exception should be logged somewhere also when running Thanks a lot for your help. |
Those error messages should show up in your logs found in |
…ssues Signed-off-by: Joakim Erdfelt <[email protected]>
Signed-off-by: Joakim Erdfelt <[email protected]>
Signed-off-by: Joakim Erdfelt <[email protected]>
… issues (#10605) * Issue #10473 - Better warnings in jetty.sh on filesystem permission issues Signed-off-by: Joakim Erdfelt <[email protected]>
I have tried |
Jetty version(s)
10.0.16
Jetty Environment
N/A
Java version/vendor
(use: java -version)
openjdk version "17.0.8" 2023-07-18 LTS
OS type/version
Amazon Linux 2
Description
Jetty starts fine, but startup script throws error. PID file is empty, so stopping the service is not working.
Startup:
Stop:
How to reproduce?
Start and stop jetty
The text was updated successfully, but these errors were encountered: