[JIRA] [core] (JENKINS-33776) Cannot start from preview rpm

Hi, I think this might still be an issue. My chef tests started failing recently - they spin up a Centos 7 VM, install Jenkins (currently jenkins-2.7.1-1.1.noarch) from the http://pkg.jenkins-ci.org/redhat-stable repo, and then tries to start it. The /etc/sysconfig/jenkins config file included in the rpm has a line that tries to run AJP on port 8009:

1. Type: integer(0:65535)
2. Default: 8009
3. ServiceRestart: jenkins
  #
Ajp13 Port Jenkins is listening on.
Set to -1 to disable
#
JENKINS_AJP_PORT="8009"

This causes jenkins to fail at startup as described by https://issues.jenkins-ci.org/browse/JENKINS-33776?focusedCommentId=255250&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-255250

It would be better if the /etc/sysconfig/jenkins file included in the rpm didn't try to configure AJP so jenkins would run right out of the box without requiring the users to modify it.

This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)

toby@caboteria.org (JIRA)

unread,

Jul 13, 2016, 5:51:01 PM7/13/16

to jenkinsc...@googlegroups.com

toby cabot edited a comment on

Hi, I think this might still be an issue. My chef tests started failing recently - they spin up a Centos 7 VM, install Jenkins (currently jenkins-2.7.1-1.1.noarch) from the http://pkg.jenkins-ci.org/redhat-stable repo, and then tries to start it. The /etc/sysconfig/jenkins config file included in the rpm has a line that tries to run AJP on port 8009:

{noformat}
## Type: integer(0:65535)
## Default: 8009
## ServiceRestart: jenkins
#

# Ajp13 Port Jenkins is listening on.

# Set to -1 to disable
#
JENKINS_AJP_PORT="8009"
{noformat}

This causes jenkins to fail at startup as described by https://issues.jenkins-ci.org/browse/JENKINS-33776?focusedCommentId=255250&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-255250

It would be better if the /etc/sysconfig/jenkins file included in the rpm didn't try to configure AJP so jenkins would run right out of the box without requiring the users to modify it.

signusx7@gmail.com (JIRA)

unread,

Jul 13, 2016, 7:45:01 PM7/13/16

to jenkinsc...@googlegroups.com

Matthew Sexton commented on

toby cabot - I agree that this needs to be remedied from a base install. Have you tried installing with the latest version (2.13) to test? There's nothing that points to that being removed or changed for the RPM, but it never hurts to try. Since there is a workaround in place (and since it's marked as resolved) it's not a high priority for the devs.

dbeck@cloudbees.com (JIRA)

unread,

Jul 13, 2016, 8:58:02 PM7/13/16

to jenkinsc...@googlegroups.com

Daniel Beck commented on

This was marked resolved because we fixed it. I'm currently trying to get information on the release process, maybe something went wrong there (specifically, master branch of https://github.com/jenkinsci/packaging used rather than the jenkins-2.0 branch).

toby@caboteria.org (JIRA)

unread,

Jul 14, 2016, 7:17:02 AM7/14/16

to jenkinsc...@googlegroups.com

toby cabot commented on

Thanks for your attention on this.

Based on the source I think it's likely that 2.13 behaves the same as 2.7.1. According to the PR linked from this report, the fix was merged to the jenkins-2.0 branch but there's a comment that might indicate that was a mistake: https://github.com/jenkinsci/packaging/pull/51#issue-144292301 says "A separate jenkins-2.0 packaging branch has been created, because pre-Jenkins 2 users may rely on AJP." which to me indicates that the fix should have been applied to master but not jenkins-2.0 (since the fix disables AJP). The fix was applied to jenkins-2.0, though.

It also looks as if the 2.7.1 RPM's are built with the master branch of jenkinsci/packaging instead of the jenkins-2.0 branch, as Daniel indicates. I supposed if both of these things were fixed then the result would be no change to the current behavior. Unfortunately, seomone's going to feel some pain, I guess, either the set of those using AJP, or the set of all new and upgrading users.

Would it make sense to re-open this report to track the effort to get the fix to end-users, or is there a different report to track that?

dbeck@cloudbees.com (JIRA)

unread,

Jul 14, 2016, 8:19:01 AM7/14/16

to jenkinsc...@googlegroups.com

Daniel Beck commented on

All other 2.x releases do not have this problem, as it's caused by different build/release processes for weeklies/LTS, and 2.7.1 being the first 2.x based LTS – and still using the master branch of packaging.

KK is on it, we'll probably just re-release 2.7.1 packages with the correct scripts. I will keep updating this issue in lack of a better issue. No need to reopen.

paul.scott1@baesystems.com (JIRA)

unread,

Jul 14, 2016, 10:45:02 AM7/14/16

to jenkinsc...@googlegroups.com

Paul Scott commented on