Detected More Than One Insance

[Matt Wilson]

This is a weird one that I can't figure out yet.
I recently upgraded from Java 8 to Java 11.

This is on a Red Hat box that is running a single Jenkins instance behind 
apache

I am getting this error

Jenkins detected that you appear to be running more than one instance of 
Jenkins that share the same home directory 'X/jenkins’. This greatly 
confuses Jenkins and you will likely experience strange behaviors, so 
please correct the situation.

This Jenkins:
1462917624 contextPath="" at 123035@XX
Other Jenkins:
1462917624 contextPath="" at 123035@XX


Its telling me the same process.
If I check my running processes, there is only one Jenkins instance 
running, and yes it does have that PID listed above.

Anyone else bump into this one?

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/0abb4808-391a-4210-bb66-3d87185f352fn%40googlegroups.com.

Re: Multiple Instances on one server with Java 11

[Matt Wilson]

ooo... you may have nailed it there.  I was definitely over  the 75%.  I 
bumped up my overall system RAM, and then locked in the one site that isn't 
used too much to a lower value.  Its early, but so far no crashes.  
Interesting that Java 8 never had an issue with this, but 11 clearly is.
Hopefully this holds as a solution.  Thanks for the tip!

On Monday, July 11, 2022 at 12:40:29 PM UTC-4 kuisat...@gmail.com wrote:

> If there are three different Apache Tomcat instances running three 
> different services on Java 11, the only explanation to make one crash that 
> comes to my mind is the resources of the machine, memory in particular.
> The recommendation is to not use more than 75% of the memory of the host 
> to the JVM, in your case you have 3 JVM running so each should not use more 
> than 25% of the memory of the host, if you use more than that the JVM will 
> fight for the host resources and one will lose crashing. Check the values 
> on your `xms` and `xmx` Apache Tomcat parameters.
>
> El lunes, 11 de julio de 2022 a las 16:40:08 UTC+2, slide escribió:
>
>> Is there any crash log in either the apache or jenkins logs? I would look 
>> for exception dumps in the logs, it might help narrow down where the issue 
>> is occurring.
>>
>> On Mon, Jul 11, 2022 at 5:35 AM Matt Wilson  wrote:
>>
>>> For a few years I've been running multiple (independent) Jenkins 
>>> instances on one server.  Each server runs under its own apache instance.
>>> SiteA
>>> SiteB
>>> SiteC
>>> This has worked perfectly fine for a few years with no problems.
>>> Last week I upgraded all three servers to 2.346.1.  two of the three 
>>> servers had been updated regularly so this wasn't a huge jump, that third 
>>> server has a year and a bit behind so it was a bigger jump (siteB).
>>> All three sites upgraded fine.  
>>> All three sites got upgraded to Java 11.  That went fine.
>>> All three sites run independently with no problems.
>>> When I start all three sites, I have one site that crashes.  The crash 
>>> seems to be triggered in particular when you access the management page on 
>>> one particular server.
>>> so like this
>>> Site A is fine no matter what
>>> Site B crashes when site C accesses its manage Jenkins page
>>>
>>> I've double checked my settings, I can't find any port conflicts or 
>>> Jenkins home conflicts.
>>> I've tried running all three sites on separate Java installs.  Still 
>>> crashes
>>> The only thing that seems to stop the crash so far is if I run site C 
>>> back on Java 8.
>>>
>>> Any thoughts on what I could be missing here config wise?
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Jenkins Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to jenkinsci-use...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-users/de1049d2-cbe0-462e-9bce-1f9656ba6018n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-users/de1049d2-cbe0-462e-9bce-1f9656ba6018n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> -- 
>> Website: http://earl-of-code.com
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/ff1e0be4-a93c-48fd-aacd-3df27b92cb97n%40googlegroups.com.

Re: Multiple Instances on one server with Java 11

[Matt Wilson]

Sorry, should have mentioned that.
This is running on RHEL 7, and there are no indications of anything in the 
logs.  Just an abrupt stop.  I could probably turn on some more verbose 
logging though.

On Monday, July 11, 2022 at 10:40:08 AM UTC-4 slide wrote:

> Is there any crash log in either the apache or jenkins logs? I would look 
> for exception dumps in the logs, it might help narrow down where the issue 
> is occurring.
>
> On Mon, Jul 11, 2022 at 5:35 AM Matt Wilson  wrote:
>
>> For a few years I've been running multiple (independent) Jenkins 
>> instances on one server.  Each server runs under its own apache instance.
>> SiteA
>> SiteB
>> SiteC
>> This has worked perfectly fine for a few years with no problems.
>> Last week I upgraded all three servers to 2.346.1.  two of the three 
>> servers had been updated regularly so this wasn't a huge jump, that third 
>> server has a year and a bit behind so it was a bigger jump (siteB).
>> All three sites upgraded fine.  
>> All three sites got upgraded to Java 11.  That went fine.
>> All three sites run independently with no problems.
>> When I start all three sites, I have one site that crashes.  The crash 
>> seems to be triggered in particular when you access the management page on 
>> one particular server.
>> so like this
>> Site A is fine no matter what
>> Site B crashes when site C accesses its manage Jenkins page
>>
>> I've double checked my settings, I can't find any port conflicts or 
>> Jenkins home conflicts.
>> I've tried running all three sites on separate Java installs.  Still 
>> crashes
>> The only thing that seems to stop the crash so far is if I run site C 
>> back on Java 8.
>>
>> Any thoughts on what I could be missing here config wise?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-use...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/de1049d2-cbe0-462e-9bce-1f9656ba6018n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-users/de1049d2-cbe0-462e-9bce-1f9656ba6018n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> -- 
> Website: http://earl-of-code.com
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/b93c3ca5-2cef-4bb5-8684-b2d1695fe6ffn%40googlegroups.com.

Multiple Instances on one server with Java 11

[Matt Wilson]

For a few years I've been running multiple (independent) Jenkins instances 
on one server.  Each server runs under its own apache instance.
SiteA
SiteB
SiteC
This has worked perfectly fine for a few years with no problems.
Last week I upgraded all three servers to 2.346.1.  two of the three 
servers had been updated regularly so this wasn't a huge jump, that third 
server has a year and a bit behind so it was a bigger jump (siteB).
All three sites upgraded fine.  
All three sites got upgraded to Java 11.  That went fine.
All three sites run independently with no problems.
When I start all three sites, I have one site that crashes.  The crash 
seems to be triggered in particular when you access the management page on 
one particular server.
so like this
Site A is fine no matter what
Site B crashes when site C accesses its manage Jenkins page

I've double checked my settings, I can't find any port conflicts or Jenkins 
home conflicts.
I've tried running all three sites on separate Java installs.  Still crashes
The only thing that seems to stop the crash so far is if I run site C back 
on Java 8.

Any thoughts on what I could be missing here config wise?

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/de1049d2-cbe0-462e-9bce-1f9656ba6018n%40googlegroups.com.

Re: Resource Root Problem Post Upgrade

[Matt Wilson]

And here I am pretty much in the exact same time frame as the original case 
(2-3 days in) and I'm seeing the same issue again.  I can't download 
artifacts unless I remove my resource root url setting.

this the type of error I see in my logs.  the first is my actual first 
rejection...

Nov 05, 2021 8:49:15 AM FINE jenkins.security.ResourceDomainFilter doFilter 
Rejecting 
request to https:///login from xxx.xxx..xxx on 
resource domain
Nov 05, 2021 9:03:58 AM FINE jenkins.security.ResourceDomainFilter doFilter 
Rejecting 
request to https://   /login from xxx.xxx..xxx   on 
resource domain  
Nov 05, 2021 09:04:17 AM FINE jenkins.security.ResourceDomainFilter 
doFilter Rejecting request to https:///instance-identity/ 
from xxx.xxx..xxx on resource domain

I've combed through my logs around 8:49am time to see if there is any 
record of another event at that time.  Nothing really jumps out as being a 
problem.
I'm at a total loss right now.  No clue what is causing this issue.

On Wednesday, November 3, 2021 at 11:03:35 AM UTC-4 Matt Wilson wrote:

> I managed to get a service restart last night.  I just reapplied my 
> resource root url setting.
> mystery continues at this point.  After reapplying my settings, I can 
> download artifacts with no problem.  The logs are clean with respect to 
> these downloads, nothing out of the ordinary.
>
> when I reload my config page though I see an error below my resource url 
> just as before (see attached).  The stack trace is the same as before.
> I'm going to wait it out right now, but I'm expecting this will stop 
> working at somepoint over the next day or so.  I have no idea if this 
> "error" message was present before the upgrade to this version.
>
> On Tuesday, November 2, 2021 at 11:03:32 AM UTC-4 Matt Wilson wrote:
>
>> thanks.  Whats odd is that based on job log output this seemed to have 
>> been working for a few days, then "broke".  Right now I'm playing on 
>> scheduling a service restart.  Maybe I'll get lucky and its just a one 
>> off... I guy can dream.
>> On Tuesday, November 2, 2021 at 3:43:53 AM UTC-4 db...@cloudbees.com 
>> wrote:
>>
>>> On Tue, Nov 2, 2021 at 2:27 AM Matt Wilson  wrote:
>>>
>>>>
>>>> Caused by: java.lang.NullPointerException
>>>> at 
>>>> jenkins.security.ResourceDomainConfiguration.checkUrl(ResourceDomainConfiguration.java:174)
>>>> at 
>>>> jenkins.security.ResourceDomainConfiguration.doCheckUrl(ResourceDomainConfiguration.java:88)
>>>>
>>>
>>> The URL responds with a 404 error message and has no response message 
>>> (of course error handling should be better). Would look at reverse proxy or 
>>> a nondefault web container as the likely culprit (I just checked 
>>> ci.jenkins.io to be sure it's not a general problem, and its resource 
>>> root URL works as expected).
>>>
>>> Another option might be problems with the instance-identity module I use 
>>> to determine URL correctness, but then the actual URLs should work, and 
>>> only form validation be broken.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/996eb23e-3993-40b7-9c26-bf24ee6b45cen%40googlegroups.com.

Re: Java 11 is the recommended version to run Jenkins on

[Matt Wilson]

I haven't tried switching yet.  Any concerns about switching to 11 and then 
rolling back to 8 if there is a problem?  Guessing no, but thought I'd 
ask...

On Wednesday, November 3, 2021 at 3:18:44 PM UTC-4 s.p...@gmail.com wrote:

> Thank you Mark!
>
> On Wednesday, November 3, 2021 at 10:38:28 AM UTC-4 Mark Waite wrote:
>
>> Jenkins continues to support Java 8.  We recommend Java 11.
>>
>> See 
>> https://www.jenkins.io/blog/2021/08/17/docker-images-use-jdk-11-by-default/ 
>> for more details on the rationale for that transition.
>>
>> On Wednesday, November 3, 2021 at 8:24:47 AM UTC-6 s.p...@gmail.com 
>> wrote:
>>
>>> After I upgraded Jenkins to 2.303.2, I'm seeing an alert as below. J. I 
>>> think Java 11 is OpenJDK and we are using java 1.8.0_301. Is Java 1.8 no 
>>> longer supported ? Any inputs are really appreciated. TIA
>>>
>>> "Java11 is the recommended version to run Jenkins on; please consider 
>>> upgrading."
>>>
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/c507eb8e-813e-482d-9d51-92a4dff07b7en%40googlegroups.com.

Re: Resource Root Problem Post Upgrade

[Matt Wilson]

I managed to get a service restart last night.  I just reapplied my 
resource root url setting.
mystery continues at this point.  After reapplying my settings, I can 
download artifacts with no problem.  The logs are clean with respect to 
these downloads, nothing out of the ordinary.

when I reload my config page though I see an error below my resource url 
just as before (see attached).  The stack trace is the same as before.
I'm going to wait it out right now, but I'm expecting this will stop 
working at somepoint over the next day or so.  I have no idea if this 
"error" message was present before the upgrade to this version.

On Tuesday, November 2, 2021 at 11:03:32 AM UTC-4 Matt Wilson wrote:

> thanks.  Whats odd is that based on job log output this seemed to have 
> been working for a few days, then "broke".  Right now I'm playing on 
> scheduling a service restart.  Maybe I'll get lucky and its just a one 
> off... I guy can dream.
> On Tuesday, November 2, 2021 at 3:43:53 AM UTC-4 db...@cloudbees.com 
> wrote:
>
>> On Tue, Nov 2, 2021 at 2:27 AM Matt Wilson  wrote:
>>
>>>
>>> Caused by: java.lang.NullPointerException
>>> at 
>>> jenkins.security.ResourceDomainConfiguration.checkUrl(ResourceDomainConfiguration.java:174)
>>> at 
>>> jenkins.security.ResourceDomainConfiguration.doCheckUrl(ResourceDomainConfiguration.java:88)
>>>
>>
>> The URL responds with a 404 error message and has no response message (of 
>> course error handling should be better). Would look at reverse proxy or a 
>> nondefault web container as the likely culprit (I just checked 
>> ci.jenkins.io to be sure it's not a general problem, and its resource 
>> root URL works as expected).
>>
>> Another option might be problems with the instance-identity module I use 
>> to determine URL correctness, but then the actual URLs should work, and 
>> only form validation be broken.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/5cb596af-8f8a-4819-9d78-bf1f73249fadn%40googlegroups.com.

Re: Resource Root Problem Post Upgrade

[Matt Wilson]

thanks.  Whats odd is that based on job log output this seemed to have been 
working for a few days, then "broke".  Right now I'm playing on scheduling 
a service restart.  Maybe I'll get lucky and its just a one off... I guy 
can dream.
On Tuesday, November 2, 2021 at 3:43:53 AM UTC-4 db...@cloudbees.com wrote:

> On Tue, Nov 2, 2021 at 2:27 AM Matt Wilson  wrote:
>
>>
>> Caused by: java.lang.NullPointerException
>> at 
>> jenkins.security.ResourceDomainConfiguration.checkUrl(ResourceDomainConfiguration.java:174)
>> at 
>> jenkins.security.ResourceDomainConfiguration.doCheckUrl(ResourceDomainConfiguration.java:88)
>>
>
> The URL responds with a 404 error message and has no response message (of 
> course error handling should be better). Would look at reverse proxy or a 
> nondefault web container as the likely culprit (I just checked 
> ci.jenkins.io to be sure it's not a general problem, and its resource 
> root URL works as expected).
>
> Another option might be problems with the instance-identity module I use 
> to determine URL correctness, but then the actual URLs should work, and 
> only form validation be broken.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/d0985a70-c8a3-410e-923f-b85d49aeed32n%40googlegroups.com.

Re: Resource Root Problem Post Upgrade

[Matt Wilson]

)
at 
org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:141)
at org.kohsuke.stapler.MetaClass$11.doDispatch(MetaClass.java:536)
at 
org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58)
at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:766)
... 87 more

nothing really jumps out at me...

On Monday, November 1, 2021 at 8:44:23 PM UTC-4 db...@cloudbees.com wrote:

>
>
> On Mon, Nov 1, 2021 at 8:11 PM Matt Wilson  wrote:
>
>> Logging ID=5d0d5334--4ac8-a484-7deef5d062fa
>>
>
> Check the Jenkins system log for the corresponding error message. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/52e005cd-ca67-4473-b213-73ae30388250n%40googlegroups.com.

Re: Resource Root URL certificate

[Matt Wilson]

Sorry, I know this doesn't really answer your question, but though I'd 
share since it might help someone else.  We use a Mutli Domain EV cert for 
this purpose.  Its worked well and is probably less maintenance...

On Tuesday, February 11, 2020 at 12:33:19 PM UTC-5 Stefan Spieker wrote:

> I would like to use the Resource root URL feature and have an alternative 
> name for the server.
> Since it is currently accessible by https, I would also like to keep it 
> https also for the resources.
>
> How do I specify the second certificate to the jenkins startup command?
> I'm using the embedded winstone.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/8ef28ef9-1ae3-4acf-b351-bf5f87300b1cn%40googlegroups.com.

Resource Root Problem Post Upgrade

[Matt Wilson]

I just upgraded to LTS 2.303.2 from 2.289.3.
Post upgrade I'm having problems with my system.  I can no longer download 
artifacts from my server.  When I try, I get a 404 error "*Message* Jenkins 
serves only static files on this domain.".  Interestingly enough, using the 
download zip feature works fine.

I've been using a Resource Root URL for some time now with no issues.
I noticed on my main configuration screen I'm seeing an error under my URL 
entry
A problem occurred while processing the request.

Logging ID=5d0d5334--4ac8-a484-7deef5d062fa

I tried removing my Resource root url, and my download issues went away.  
this of course causes a lot of issues with other features that rely on the 
resource root url to be displayed properly.

Anyone run into anything like this recently?


-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/b1f4cdf2-034b-4a26-8190-f017782172d7n%40googlegroups.com.

Docker Plugin Not Spinning Up New Agents

[Matt Wilson]

Jenkins LTS 2.249.3
Docker plugin 1.2.1

We've been using the docker plugin for some time now to spin up build agent 
containers.  Its worked great up until last week.
For some reason Jenkins will just stop spinning up new containers when jobs 
are in the queue.  I'm not sure what the root cause is that this point.

The only way to get the system to start spinnin up containers is to restart 
the jenkins service.  At this point the failure seems somewhat random.  It 
might work for 48, it might work 10.

The only thing I can find in my logs is this reference below.
If anyone has any suggestion I'd appreciate hearing it.

09-Nov-2020 11:51:56.879 SEVERE [dockerjava-netty-3426-1] 
com.github.dockerjava.core.async.ResultCallbackTemplate.onError Error 
during callback
 com.github.dockerjava.api.exception.NotFoundException: {"message":"No such 
container: 
a96167b9016d2624870640933da629f429ad736a473d690ee70fac3cd97bf211"}

at 
com.github.dockerjava.netty.handler.HttpResponseHandler.channelRead0(HttpResponseHandler.java:103)
at 
com.github.dockerjava.netty.handler.HttpResponseHandler.channelRead0(HttpResponseHandler.java:33)
at 
io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at 
io.netty.handler.logging.LoggingHandler.channelRead(LoggingHandler.java:241)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at 
io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at 
io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:438)
at 
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:323)
at 
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:297)
at 
io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:253)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at 
io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1432)
at 
io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1199)
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1243)
at 
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:502)
at 
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:441)
at 
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:278)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
at 
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1434)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
at 

Docker Cloud Node Based Security

[Matt Wilson]

Hello All,

Is there a way to implement the Node Based Security that regular agents use 
on a docker cloud instance like 
this https://plugins.jenkins.io/docker-plugin/

I can't see anyplace to enable it.  

cheers
Matt

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/c48e0288-5cfe-47fe-b3d8-31d2a4f737e5n%40googlegroups.com.

Artifactory Plugin 3.2.2

[Matt Wilson]

Not sure if anyone else has had this issue, but since upgrading to the new 
3.2.2 release I can no longer override the default artifactory stored 
credentials (i.e. the credentials plugin).  I can select credentials, but 
when the job gets saved it wipes out the selection and reverts to "None".  
Saving any job that has existing credentials set also wipes the field.

This is for a generic job configuration.  I have tested if this is an issue

Rolling back to the previous 3.2.1 plugin resolves the issue for now.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/d1c299a3-0cf9-4a11-b311-b0a03ee2dd57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins restrict what nodes a Job can run on

[Matt Wilson]

Thanks guys,
I'll take a look at the ownership/Job restrictions plugins.  That might be 
something that could work.

I'll have to shy away from the Authorize plugin for now as it doesn't play 
nice with some other plugins and breaks some major credential pugins 
functionality (or at least it did, maybe its been fixed)

Cheers
Matt

On Tuesday, August 15, 2017 at 12:07:35 PM UTC-4, Oleg Nenashev wrote:
>
> There are few more simple ways if you just need this feature:
>
>- Use Authorize Project plugin 
> to 
>assign authentication to your builds. Then Just set Computer/Build 
>permissions for you nodes (Can be done in Role Strategy plugin for example)
>- Use Job Restrictions Plugin 
> to 
>restrict access to node via Node properties
>
> You can find some pointers to plugins and sample configurations in this 
> slidedeck: 
> https://speakerdeck.com/onenashev/belarus-jenkins-meetup-managing-security-in-jenkins-with-config-as-code-and-roles
>
>
> BR, Oleg
>
>
>
> вторник, 15 августа 2017 г., 15:35:22 UTC+2 пользователь Victor Martinez 
> написал:
>>
>> https://wiki.jenkins.io/display/JENKINS/Ownership+Plugin might help you 
>> to define who owns those nodes/jobs and so on. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/a1de6de8-8dff-4e75-8ac2-c3ed96e020ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins restrict what nodes a Job can run on

[Matt Wilson]

Is there a way to restrict or lockout the "restrict where this project can 
be run" selection box for users with config access?

I've got certain users where it would be nice to give them some 
configuration control of their job, but I really need to keep them off 
certain slaves.  i.e. I would create the job initially, define a 
slave/label it can use, then allow a user with config access to make 
changes to the job (but obviously not make changes to the to the defined 
node/label).

appreciate any thoughts anyone has on this.
Cheers

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/343124f9-61af-4c2e-81e4-424f9fa516e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins Process Debugging

[Matt Wilson]

Hi All,
I've got an odd situation in that my Jenkins server after a certain mount 
of time seems to start consuming large amounts of CPU.  This seems to start 
to happen every 45 to 60 days.  When the CPU usage spikes the Jenkins 
service doesn't come to a halt, the jobs build times don't seem to be 
overly impacted.  We do see an impact (latency) in things like opening 
config pages, authenticating logins, navigating through the builds. 
 Restarting my Jenkins service at this point gets things back to normal.

What is the best way to approach debugging this?  I've tried using jstack 
and tracking down process IDs (converted to hex) but that didn't seem to 
work at all.  I'm sure I'm doing something wrong there...  I've looked at 
the jenkins tread dump.  Again, I'm having the same issue of not being able 
to track my offending PIDs to the actual thread dump.  Its actually been 
pretty hard to debug this since it occurs so infrequently, I can only let 
the race condition continue for so long before I have to restart the 
service...

My guess here is that I've got a plugin misbehaving or something like that. 
 I'd really like to track it down though.  I'm not against the concept of 
setting up a restart window monthly for Jenkins, but I'd rather avoid that 
if possible.  If you have any tips or tricks, I'd love to hear it.  I'm 
probably not going to see the condition again until sometime in August, but 
I'd like to get a debugging procedure in place for when it happens again.

cheers
Matt

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/a41a8bcf-888e-4202-a837-e51cc18ce660%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Slaves on Old OS's

[Matt Wilson]

haha.  Nothing older than 5.x.
I'll give that a try on AIX.   I know I've tried that on Solaris, but I 
don't think I have on AIX.

cheers

On Friday, August 12, 2016 at 3:06:27 PM UTC-4, Baptiste Mathus wrote:
>
> Which version for AIX? 5.x or even older?
>
> Don't have one handy anymore, but IIRC simply copying the /usr/java7 
> folder (IIRC the path) onto an older version should often work (pretty sure 
> we did it on 6.x to 5.x, maybe 4.x but not sure).
>
> Obviously that would make the support contract unusable, but hey anyway 
> they're always trying to find a way to make your case an exclusion.
>
> Cheers
>
> Le 12 août 2016 8:31 PM, "Matt Wilson" <mwil...@gmail.com > 
> a écrit :
>
> Back ports eh.  I'll have to look in to that.  Thanks
>
> Right now I'm having issues with some old AIX and Solaris boxes
>
>
> On Friday, August 12, 2016 at 10:22:37 AM UTC-4, Baptiste Mathus wrote:
>
>> Hi,
>>
>> Can't you use a backport or something of the JDK 7 on those platforms?
>>
>> BTW, can you tell which ones they are?
>>
>> Thanks
>>
>> Le 12 août 2016 2:55 PM, "Matt Wilson" <mwil...@gmail.com> a écrit :
>>
>>> Hi all,
>>> We're currently running Jenkins 1.651.1.
>>> Is there any work around to get the current slave.jar to run with older 
>>> versions of Java?  I've got a few really old machines that are capped out 
>>> at Java 5 or 6.  Up until now these old machines have continued to run jobs 
>>> via our old pre-jenkins build system.  We've used some other solutions 
>>> (i.e. ssh) with moderate success to bridge this gap, but I thought I'd see 
>>> if anyone in the group had come up with any creative solutions.  I'd really 
>>> like to pull my builds back into one solution...
>>>
>>> Cheers
>>> Matt
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Jenkins Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to jenkinsci-use...@googlegroups.com.
>>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-users/3c042654-c1b0-4bd2-8ba2-e5c5d974d1dc%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-users/3c042654-c1b0-4bd2-8ba2-e5c5d974d1dc%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-use...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/65e92696-c967-4123-a760-34cebbc92e90%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-users/65e92696-c967-4123-a760-34cebbc92e90%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/062d4dfc-57a8-45dc-b6b5-e7bc0493c0c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Slaves on Old OS's

[Matt Wilson]

Back ports eh.  I'll have to look in to that.  Thanks

Right now I'm having issues with some old AIX and Solaris boxes


On Friday, August 12, 2016 at 10:22:37 AM UTC-4, Baptiste Mathus wrote:
>
> Hi,
>
> Can't you use a backport or something of the JDK 7 on those platforms?
>
> BTW, can you tell which ones they are?
>
> Thanks
>
> Le 12 août 2016 2:55 PM, "Matt Wilson" <mwil...@gmail.com > 
> a écrit :
>
>> Hi all,
>> We're currently running Jenkins 1.651.1.
>> Is there any work around to get the current slave.jar to run with older 
>> versions of Java?  I've got a few really old machines that are capped out 
>> at Java 5 or 6.  Up until now these old machines have continued to run jobs 
>> via our old pre-jenkins build system.  We've used some other solutions 
>> (i.e. ssh) with moderate success to bridge this gap, but I thought I'd see 
>> if anyone in the group had come up with any creative solutions.  I'd really 
>> like to pull my builds back into one solution...
>>
>> Cheers
>> Matt
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/3c042654-c1b0-4bd2-8ba2-e5c5d974d1dc%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-users/3c042654-c1b0-4bd2-8ba2-e5c5d974d1dc%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/65e92696-c967-4123-a760-34cebbc92e90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Slaves on Old OS's

[Matt Wilson]

Trust me, I wish I didn't have to bother with them.  There are lots of 
different reasons.  Old hardware that hasn't been replaced.  Old build 
reproducability.  Customer requirement.

On Friday, August 12, 2016 at 10:50:07 AM UTC-4, Simona Avornicesei wrote:
>
> What is the reason for keeping/using such old machines?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/e668e4cd-f31e-4b79-8fa4-ae5b4639c650%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Slaves on Old OS's

[Matt Wilson]

Hi all,
We're currently running Jenkins 1.651.1.
Is there any work around to get the current slave.jar to run with older 
versions of Java?  I've got a few really old machines that are capped out 
at Java 5 or 6.  Up until now these old machines have continued to run jobs 
via our old pre-jenkins build system.  We've used some other solutions 
(i.e. ssh) with moderate success to bridge this gap, but I thought I'd see 
if anyone in the group had come up with any creative solutions.  I'd really 
like to pull my builds back into one solution...

Cheers
Matt

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/3c042654-c1b0-4bd2-8ba2-e5c5d974d1dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Copy artifact plugin with maven multi module project

[Matt Wilson]

Hey Jeff,
Did you ever figure this out?  I'm running into a very similar issue.  I've 
got a maven build that has a zip file artifacted.  The zip file wasn't part 
of any maven build, it was created post build.  Jenkins artifacts it no 
problem, but my downstream build refuses to find the artifact.  It looks 
for the zips in the module artifact space which isn't working since I don't 
even have module artifacting enabled.  I've been able to get this working 
by enabling module artifacting, but I'd rather not do that as it consumes a 
bunch of extra disk space...

Matt

On Monday, January 12, 2015 at 9:03:36 PM UTC-5, Jeff Storey wrote:
>
> I have a multi-module maven project that is an upstream job, and the 
> downstream job that it triggers uses the Copy Artifact plugin to copy the 
> artifacts produced by the maven project. These are snapshot artifacts being 
> generated. Jenkins automatically archives the maven artifacts, and when it 
> does, at changes the artifact name to have a version and timestamp on it, 
> so it looks like *myproject-1.2.0-.war*, or something like 
> that. This happens even though my project outputs a war named 
> *myproject.war**. *I tried just using the Jenkins post build step to 
> archive the artifacts (which does have the correct names) and disabling the 
> automatic archiving of maven artifacts, but when I do this, the Copy 
> Artifact plugin fails because it looks for the artifacts in the maven 
> module subdirectories.
>
> Is there a way to have the Copy Artifact plugin only copy the artifacts 
> produced by the Jenkins post build archiving step or is there any way to 
> have the maven archived artifacts not have the timestamp added to them?
>
> Thank you.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/31925cae-4e57-4075-b7a9-74345ebfe2b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: disown child process

[Matt Wilson]

I believe its RedHat 5.8.

I'll mention the service idea.  This is one of those scenarios where I 
don't own the deployment server.  They've set it up to there tastes and 
I'm simply automating a manual task for them.

cheers
Matt

On Saturday, June 7, 2014 12:41:54 AM UTC-4, Richard Bywater wrote:

 You don't mention which flavour of Linux but why not run Tomcat as a 
 system service/daemon and control it via your Jenkins job?

 Richard.

 On Saturday, June 7, 2014, Matt Wilson mwil...@gmail.com javascript: 
 wrote:

 I'm hoping someone has done this before and can offer a possible 
 solution...

 I've got a Linux slave that I'm trying to setup to do a test deployment 
 of a job.  Basically stop tomcat, add/deleting some war files and then 
 restart tomcat.  Pretty straight forward stuff.  The problem I'm having is 
 that when my jenkins slave shuts down at the completion of the job, my 
 tomcat server also then shuts down.  
 I know I could leave my jenkins slave up but I'd really rather not.  
 I've tried nohup, , and disown.  no luck
 I've also tried changing the slave launch parameters i.e. adding sh -c 
   no luck.
 I've also tried changing the tomcat start script to nohup rather than 
 my jenkins job doing the hohup.  still no luck.

 anybody have any ideas?  

 Matt

  -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Users group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.



-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

disown child process

[Matt Wilson]

I'm hoping someone has done this before and can offer a possible solution...

I've got a Linux slave that I'm trying to setup to do a test deployment of 
a job.  Basically stop tomcat, add/deleting some war files and then restart 
tomcat.  Pretty straight forward stuff.  The problem I'm having is that 
when my jenkins slave shuts down at the completion of the job, my tomcat 
server also then shuts down.  
I know I could leave my jenkins slave up but I'd really rather not.  
I've tried nohup, , and disown.  no luck
I've also tried changing the slave launch parameters i.e. adding sh -c 
  no luck.
I've also tried changing the tomcat start script to nohup rather than my 
jenkins job doing the hohup.  still no luck.

anybody have any ideas?  

Matt

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: disown child process

[Matt Wilson]

wow!  thanks a lot!  that actually seems to have done the trick.  :-)

On Friday, June 6, 2014 2:31:27 PM UTC-4, Patricia Wright wrote:

 Perhaps the reaper is killing you.

 At the end of a job, jenkins will kill of any process with the environment 
 variable BUILD_ID that matches that job.

 You can override that environment variable with something else (set 
 BUILD_ID='please do not kill me')  before launching tomcat, etc...
 Or you can turn off the process reaper in the slave.

  java -Dhudson.util.ProcessTree.disable=true -jar jenkins.war



 --
 *From: *Matt Wilson mwil...@gmail.com javascript:
 *To: *jenkins...@googlegroups.com javascript:
 *Sent: *Friday, June 6, 2014 12:37:22 PM
 *Subject: *disown child process

 I'm hoping someone has done this before and can offer a possible 
 solution...

 I've got a Linux slave that I'm trying to setup to do a test deployment of 
 a job.  Basically stop tomcat, add/deleting some war files and then restart 
 tomcat.  Pretty straight forward stuff.  The problem I'm having is that 
 when my jenkins slave shuts down at the completion of the job, my tomcat 
 server also then shuts down.  
 I know I could leave my jenkins slave up but I'd really rather not.  
 I've tried nohup, , and disown.  no luck
 I've also tried changing the slave launch parameters i.e. adding sh -c 
   no luck.
 I've also tried changing the tomcat start script to nohup rather than my 
 jenkins job doing the hohup.  still no luck.

 anybody have any ideas?  

 Matt


 -- 
 You received this message because you are subscribed to the Google Groups 
 Jenkins Users group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to jenkinsci-use...@googlegroups.com javascript:.
 For more options, visit https://groups.google.com/d/optout 
 https://urldefense.proofpoint.com/v1/url?u=https://groups.google.com/d/optoutk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=P%2FDbhm7GMaM%2FtPTZjlK%2F8lebpERVSZcf2B%2BqCod7tGs%3D%0Am=yAjTYcLWxb4oVx4BIV1A1j2fpnqrOqDOrAFO4Dyyd0k%3D%0As=55049699734b8a97bb9dded66423696d15a269e1193e3160cad19418b2d368ab
 .



-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.