Re: [go-cd] logback to a logstash server

2018-03-07 Thread Aravind SV
Just to close the loop on this one: We worked with Barry and it turns out
that the problem was an extra logstash-logback-encoder-4.11.jar in
$JAVA_HOME/lib/jre/ext/. Since it was in lib/jre/ext, it loaded with a
different classloader and was failing to find logback-core in that
classloader.

The documentation remains correct. The libs dir is still:
/var/lib/go-server/libs

Cheers,
Aravind


On Tue, Jan 16, 2018 at 3:51 AM, 'Barry Greenwood' via go-cd <
go-cd@googlegroups.com> wrote:

> We have previously enabled web logging with support however
>
>
>
> has become
>
> 
>
> when the file was returned to defaults, this server has been upgraded for
> quite some time.
>
> Kind regards
>
> Barry
>
>
> On Tuesday, 16 January 2018 01:30:02 UTC, Aravind SV wrote:
>>
>> Hello Barry,
>>
>> I'll take a look at this tomorrow and try to reproduce it. Have you
>> changed jetty.xml? It's not supposed to be changed. The only reason the
>> file existed was because we needed it to turn on web request logging. GoCD
>> is not a standard jetty application. So, if you have changed it
>> (significantly), then all bets are off.
>>
>> As a general rule, anything not documented (mostly in
>> https://docs.gocd.org/current/) is not supposed to be changed.
>> Especially around configs. We have some property files with flags, etc.
>> which help in debugging - and you'd be asked for help turning them on only
>> in special cases. Unfortunately, some of them are visible to users by
>> default, and that's something we should fix.
>>
>> Any changes to documented configuration, which can cause problems, are
>> usually mentioned in the "Breaking Changes" section of the release notes
>> . Of course, it goes without saying
>> that, if something isn't documented, then there's not going to be any
>> breaking changes mentioned around it.
>>
>> Given all of that, here's what I'm going to try tomorrow:
>>
>> 1. Start with a vanilla installation of 17.9 or 17.10.
>> 2. Make sure it works.
>> 3. Upgrade to 17.12.
>> 4. Make sure it works.
>> 5. Make the logback changes mentioned in the documentation
>>  (remembering
>> the bug I mentioned earlier).
>> 6. Try the logstash configuration mentioned in the advanced logging
>> section
>> 
>> .
>>
>> I'll reply on this thread when I'm done.
>>
>> Hope that helps,
>> Aravind
>>
>>
>>
>> On Mon, Jan 15, 2018 at 2:26 AM, 'Barry Greenwood' via go-cd <
>> go...@googlegroups.com> wrote:
>>
>>> Hi Aravind
>>>
>>> Here is the information you asked for
>>>
>>> #newserver
>>> /usr/share/go-server# md5sum  go.jar
>>> 6ea48cac7c7642d95756d2027893ee2f  go.jar
>>> #oldserver
>>> /usr/share/go-server# md5sum  go.jar
>>> 6ea48cac7c7642d95756d2027893ee2f  go.jar
>>>
>>> #new server
>>>  pgrep -lf go.jar
>>> 1079 java
>>>  ls -ld /proc/1079/cwd
>>> lrwxrwxrwx 1 go go 0 Jan 15 09:42 /proc/1079/cwd -> /var/lib/go-server
>>> #oldserver
>>> pgrep -lf go.jar
>>> 840 java
>>> /var/lib/go-server# ls -ld /proc/840/cwd
>>> lrwxrwxrwx 1 root root 0 Jan 15 09:40 /proc/840/cwd -> /var/lib/go-server
>>>
>>> I believe the issue is that only the go.jar has been changed in the
>>> upgrade, while one that i know of and possibly many of the other files, the
>>> defaults or schema has changed, that a full install would have changed. I
>>> know the default jetty.xml has changed between 17.10 and 17.12, upgrades
>>> need to address these types of changes as well or at least warn during the
>>> upgrade.
>>>
>>> Kind regards
>>>
>>> Barry
>>>
>>> On Friday, 12 January 2018 20:51:11 UTC, Aravind SV wrote:

 Hmm. That's unlikely. Upgrades are just a copy of the JAR file over to
 that location. Can you check what the md5sum or shasum of the go.jar file?
 It's usually in /usr/share/go-server.

 Or you can find it using: *pgrep -lf go.jar*

 If they're the same, then the same code should be executing. Then, I'd
 be interested in finding out the current working directory of the two.
 Something like: ls -ld /proc/*PID*/cwd, where the PID is replaced with
 the process ID of the GoCD server process.


 On Fri, Jan 12, 2018 at 7:37 AM, 'Barry Greenwood' via go-cd <
 go...@googlegroups.com> wrote:

> I have tested with "lsof -n -t /var/lib/go-server/libs/" on a new
> server that is working and with our existing server that has been 
> upgraded,
> the java (go) process is acceing the files on the new server and and no
> process is accessing the libs on the upgraded server.
>
> I believe this is an issue with upgrading/
>
> Regards
>
> Barry
>
>
> On Wednesday, 10 January 2018 16:14:08 UTC, Ketan Padegaonkar wrote:
>>
>> This script
>> 
>> worked

Re: [go-cd] logback to a logstash server

2018-01-16 Thread 'Barry Greenwood' via go-cd
We have previously enabled web logging with support however 

   

has become



when the file was returned to defaults, this server has been upgraded for 
quite some time.

Kind regards

Barry


On Tuesday, 16 January 2018 01:30:02 UTC, Aravind SV wrote:
>
> Hello Barry,
>
> I'll take a look at this tomorrow and try to reproduce it. Have you 
> changed jetty.xml? It's not supposed to be changed. The only reason the 
> file existed was because we needed it to turn on web request logging. GoCD 
> is not a standard jetty application. So, if you have changed it 
> (significantly), then all bets are off.
>
> As a general rule, anything not documented (mostly in 
> https://docs.gocd.org/current/) is not supposed to be changed. Especially 
> around configs. We have some property files with flags, etc. which help in 
> debugging - and you'd be asked for help turning them on only in special 
> cases. Unfortunately, some of them are visible to users by default, and 
> that's something we should fix.
>
> Any changes to documented configuration, which can cause problems, are 
> usually mentioned in the "Breaking Changes" section of the release notes 
> . Of course, it goes without saying that, 
> if something isn't documented, then there's not going to be any breaking 
> changes mentioned around it.
>
> Given all of that, here's what I'm going to try tomorrow:
>
> 1. Start with a vanilla installation of 17.9 or 17.10.
> 2. Make sure it works.
> 3. Upgrade to 17.12.
> 4. Make sure it works.
> 5. Make the logback changes mentioned in the documentation 
>  (remembering 
> the bug I mentioned earlier).
> 6. Try the logstash configuration mentioned in the advanced logging 
> section 
> 
> .
>
> I'll reply on this thread when I'm done.
>
> Hope that helps,
> Aravind
>
>
>
> On Mon, Jan 15, 2018 at 2:26 AM, 'Barry Greenwood' via go-cd <
> go...@googlegroups.com > wrote:
>
>> Hi Aravind 
>>
>> Here is the information you asked for 
>>
>> #newserver
>> /usr/share/go-server# md5sum  go.jar
>> 6ea48cac7c7642d95756d2027893ee2f  go.jar
>> #oldserver
>> /usr/share/go-server# md5sum  go.jar
>> 6ea48cac7c7642d95756d2027893ee2f  go.jar
>>
>> #new server 
>>  pgrep -lf go.jar
>> 1079 java
>>  ls -ld /proc/1079/cwd
>> lrwxrwxrwx 1 go go 0 Jan 15 09:42 /proc/1079/cwd -> /var/lib/go-server
>> #oldserver
>> pgrep -lf go.jar
>> 840 java
>> /var/lib/go-server# ls -ld /proc/840/cwd
>> lrwxrwxrwx 1 root root 0 Jan 15 09:40 /proc/840/cwd -> /var/lib/go-server
>>
>> I believe the issue is that only the go.jar has been changed in the 
>> upgrade, while one that i know of and possibly many of the other files, the 
>> defaults or schema has changed, that a full install would have changed. I 
>> know the default jetty.xml has changed between 17.10 and 17.12, upgrades 
>> need to address these types of changes as well or at least warn during the 
>> upgrade.
>>
>> Kind regards
>>
>> Barry
>>
>> On Friday, 12 January 2018 20:51:11 UTC, Aravind SV wrote:
>>>
>>> Hmm. That's unlikely. Upgrades are just a copy of the JAR file over to 
>>> that location. Can you check what the md5sum or shasum of the go.jar file? 
>>> It's usually in /usr/share/go-server.
>>>
>>> Or you can find it using: *pgrep -lf go.jar*
>>>
>>> If they're the same, then the same code should be executing. Then, I'd 
>>> be interested in finding out the current working directory of the two. 
>>> Something like: ls -ld /proc/*PID*/cwd, where the PID is replaced with 
>>> the process ID of the GoCD server process.
>>>
>>>
>>> On Fri, Jan 12, 2018 at 7:37 AM, 'Barry Greenwood' via go-cd <
>>> go...@googlegroups.com> wrote:
>>>
 I have tested with "lsof -n -t /var/lib/go-server/libs/" on a new 
 server that is working and with our existing server that has been 
 upgraded, 
 the java (go) process is acceing the files on the new server and and no 
 process is accessing the libs on the upgraded server.

 I believe this is an issue with upgrading/

 Regards

 Barry 


 On Wednesday, 10 January 2018 16:14:08 UTC, Ketan Padegaonkar wrote:
>
> This script 
>  
> worked for me, I was able to confirm that logs were sent to logback.
>
> On Wed, Jan 10, 2018 at 8:51 PM 'Barry Greenwood' via go-cd <
> go...@googlegroups.com> wrote:
>
>> Thanks for the update
>>
>> That folder didnt exist on our server, I have added with go 
>> permissions, I've added the files but it still isnt working.
>>
>> as this isnt the first issue i've had regarding this recently 
>> implemented feature can you please confirm that it works and should the 
>> logs show it being loaded ?
>>
>> Many thanks
>>
>> Barry

Re: [go-cd] logback to a logstash server

2018-01-15 Thread Aravind SV
Forgot to mention: If we missed updating the "Breaking Changes" section and
we find something new, we should update it.

On Mon, Jan 15, 2018 at 5:29 PM, Aravind SV  wrote:

> Hello Barry,
>
> I'll take a look at this tomorrow and try to reproduce it. Have you
> changed jetty.xml? It's not supposed to be changed. The only reason the
> file existed was because we needed it to turn on web request logging. GoCD
> is not a standard jetty application. So, if you have changed it
> (significantly), then all bets are off.
>
> As a general rule, anything not documented (mostly in
> https://docs.gocd.org/current/) is not supposed to be changed. Especially
> around configs. We have some property files with flags, etc. which help in
> debugging - and you'd be asked for help turning them on only in special
> cases. Unfortunately, some of them are visible to users by default, and
> that's something we should fix.
>
> Any changes to documented configuration, which can cause problems, are
> usually mentioned in the "Breaking Changes" section of the release notes
> . Of course, it goes without saying that,
> if something isn't documented, then there's not going to be any breaking
> changes mentioned around it.
>
> Given all of that, here's what I'm going to try tomorrow:
>
> 1. Start with a vanilla installation of 17.9 or 17.10.
> 2. Make sure it works.
> 3. Upgrade to 17.12.
> 4. Make sure it works.
> 5. Make the logback changes mentioned in the documentation
>  (remembering
> the bug I mentioned earlier).
> 6. Try the logstash configuration mentioned in the advanced logging
> section
> 
> .
>
> I'll reply on this thread when I'm done.
>
> Hope that helps,
> Aravind
>
>
>
> On Mon, Jan 15, 2018 at 2:26 AM, 'Barry Greenwood' via go-cd <
> go-cd@googlegroups.com> wrote:
>
>> Hi Aravind
>>
>> Here is the information you asked for
>>
>> #newserver
>> /usr/share/go-server# md5sum  go.jar
>> 6ea48cac7c7642d95756d2027893ee2f  go.jar
>> #oldserver
>> /usr/share/go-server# md5sum  go.jar
>> 6ea48cac7c7642d95756d2027893ee2f  go.jar
>>
>> #new server
>>  pgrep -lf go.jar
>> 1079 java
>>  ls -ld /proc/1079/cwd
>> lrwxrwxrwx 1 go go 0 Jan 15 09:42 /proc/1079/cwd -> /var/lib/go-server
>> #oldserver
>> pgrep -lf go.jar
>> 840 java
>> /var/lib/go-server# ls -ld /proc/840/cwd
>> lrwxrwxrwx 1 root root 0 Jan 15 09:40 /proc/840/cwd -> /var/lib/go-server
>>
>> I believe the issue is that only the go.jar has been changed in the
>> upgrade, while one that i know of and possibly many of the other files, the
>> defaults or schema has changed, that a full install would have changed. I
>> know the default jetty.xml has changed between 17.10 and 17.12, upgrades
>> need to address these types of changes as well or at least warn during the
>> upgrade.
>>
>> Kind regards
>>
>> Barry
>>
>> On Friday, 12 January 2018 20:51:11 UTC, Aravind SV wrote:
>>>
>>> Hmm. That's unlikely. Upgrades are just a copy of the JAR file over to
>>> that location. Can you check what the md5sum or shasum of the go.jar file?
>>> It's usually in /usr/share/go-server.
>>>
>>> Or you can find it using: *pgrep -lf go.jar*
>>>
>>> If they're the same, then the same code should be executing. Then, I'd
>>> be interested in finding out the current working directory of the two.
>>> Something like: ls -ld /proc/*PID*/cwd, where the PID is replaced with
>>> the process ID of the GoCD server process.
>>>
>>>
>>> On Fri, Jan 12, 2018 at 7:37 AM, 'Barry Greenwood' via go-cd <
>>> go...@googlegroups.com> wrote:
>>>
 I have tested with "lsof -n -t /var/lib/go-server/libs/" on a new
 server that is working and with our existing server that has been upgraded,
 the java (go) process is acceing the files on the new server and and no
 process is accessing the libs on the upgraded server.

 I believe this is an issue with upgrading/

 Regards

 Barry


 On Wednesday, 10 January 2018 16:14:08 UTC, Ketan Padegaonkar wrote:
>
> This script
> 
> worked for me, I was able to confirm that logs were sent to logback.
>
> On Wed, Jan 10, 2018 at 8:51 PM 'Barry Greenwood' via go-cd <
> go...@googlegroups.com> wrote:
>
>> Thanks for the update
>>
>> That folder didnt exist on our server, I have added with go
>> permissions, I've added the files but it still isnt working.
>>
>> as this isnt the first issue i've had regarding this recently
>> implemented feature can you please confirm that it works and should the
>> logs show it being loaded ?
>>
>> Many thanks
>>
>> Barry
>>
>>
>> On Wednesday, 10 January 2018 13:56:09 UTC, Ketan Padegaonkar wrote:
>>
>>> The `libs` dir is relative to the working directory of the
>>> se

Re: [go-cd] logback to a logstash server

2018-01-15 Thread Aravind SV
Hello Barry,

I'll take a look at this tomorrow and try to reproduce it. Have you changed
jetty.xml? It's not supposed to be changed. The only reason the file
existed was because we needed it to turn on web request logging. GoCD is
not a standard jetty application. So, if you have changed it
(significantly), then all bets are off.

As a general rule, anything not documented (mostly in
https://docs.gocd.org/current/) is not supposed to be changed. Especially
around configs. We have some property files with flags, etc. which help in
debugging - and you'd be asked for help turning them on only in special
cases. Unfortunately, some of them are visible to users by default, and
that's something we should fix.

Any changes to documented configuration, which can cause problems, are
usually mentioned in the "Breaking Changes" section of the release notes
. Of course, it goes without saying that,
if something isn't documented, then there's not going to be any breaking
changes mentioned around it.

Given all of that, here's what I'm going to try tomorrow:

1. Start with a vanilla installation of 17.9 or 17.10.
2. Make sure it works.
3. Upgrade to 17.12.
4. Make sure it works.
5. Make the logback changes mentioned in the documentation
 (remembering
the bug I mentioned earlier).
6. Try the logstash configuration mentioned in the advanced logging section

.

I'll reply on this thread when I'm done.

Hope that helps,
Aravind



On Mon, Jan 15, 2018 at 2:26 AM, 'Barry Greenwood' via go-cd <
go-cd@googlegroups.com> wrote:

> Hi Aravind
>
> Here is the information you asked for
>
> #newserver
> /usr/share/go-server# md5sum  go.jar
> 6ea48cac7c7642d95756d2027893ee2f  go.jar
> #oldserver
> /usr/share/go-server# md5sum  go.jar
> 6ea48cac7c7642d95756d2027893ee2f  go.jar
>
> #new server
>  pgrep -lf go.jar
> 1079 java
>  ls -ld /proc/1079/cwd
> lrwxrwxrwx 1 go go 0 Jan 15 09:42 /proc/1079/cwd -> /var/lib/go-server
> #oldserver
> pgrep -lf go.jar
> 840 java
> /var/lib/go-server# ls -ld /proc/840/cwd
> lrwxrwxrwx 1 root root 0 Jan 15 09:40 /proc/840/cwd -> /var/lib/go-server
>
> I believe the issue is that only the go.jar has been changed in the
> upgrade, while one that i know of and possibly many of the other files, the
> defaults or schema has changed, that a full install would have changed. I
> know the default jetty.xml has changed between 17.10 and 17.12, upgrades
> need to address these types of changes as well or at least warn during the
> upgrade.
>
> Kind regards
>
> Barry
>
> On Friday, 12 January 2018 20:51:11 UTC, Aravind SV wrote:
>>
>> Hmm. That's unlikely. Upgrades are just a copy of the JAR file over to
>> that location. Can you check what the md5sum or shasum of the go.jar file?
>> It's usually in /usr/share/go-server.
>>
>> Or you can find it using: *pgrep -lf go.jar*
>>
>> If they're the same, then the same code should be executing. Then, I'd be
>> interested in finding out the current working directory of the two.
>> Something like: ls -ld /proc/*PID*/cwd, where the PID is replaced with
>> the process ID of the GoCD server process.
>>
>>
>> On Fri, Jan 12, 2018 at 7:37 AM, 'Barry Greenwood' via go-cd <
>> go...@googlegroups.com> wrote:
>>
>>> I have tested with "lsof -n -t /var/lib/go-server/libs/" on a new server
>>> that is working and with our existing server that has been upgraded, the
>>> java (go) process is acceing the files on the new server and and no process
>>> is accessing the libs on the upgraded server.
>>>
>>> I believe this is an issue with upgrading/
>>>
>>> Regards
>>>
>>> Barry
>>>
>>>
>>> On Wednesday, 10 January 2018 16:14:08 UTC, Ketan Padegaonkar wrote:

 This script
 
 worked for me, I was able to confirm that logs were sent to logback.

 On Wed, Jan 10, 2018 at 8:51 PM 'Barry Greenwood' via go-cd <
 go...@googlegroups.com> wrote:

> Thanks for the update
>
> That folder didnt exist on our server, I have added with go
> permissions, I've added the files but it still isnt working.
>
> as this isnt the first issue i've had regarding this recently
> implemented feature can you please confirm that it works and should the
> logs show it being loaded ?
>
> Many thanks
>
> Barry
>
>
> On Wednesday, 10 January 2018 13:56:09 UTC, Ketan Padegaonkar wrote:
>
>> The `libs` dir is relative to the working directory of the
>> server/agent. This should typically be `/var/lib/go-server/libs` or
>> `/var/lib/go-agent/libs`. I'll update the documentation to clarify this.
>>
>>
>> On Wed, Jan 10, 2018 at 6:29 PM 'Barry Greenwood' via go-cd <
>> go...@googlegroups.com> wrote:
>>
> Hi all
>>>
>>> I've now got logback able to log to loc

Re: [go-cd] logback to a logstash server

2018-01-15 Thread 'Barry Greenwood' via go-cd
Hi Aravind 

Here is the information you asked for 

#newserver
/usr/share/go-server# md5sum  go.jar
6ea48cac7c7642d95756d2027893ee2f  go.jar
#oldserver
/usr/share/go-server# md5sum  go.jar
6ea48cac7c7642d95756d2027893ee2f  go.jar

#new server 
 pgrep -lf go.jar
1079 java
 ls -ld /proc/1079/cwd
lrwxrwxrwx 1 go go 0 Jan 15 09:42 /proc/1079/cwd -> /var/lib/go-server
#oldserver
pgrep -lf go.jar
840 java
/var/lib/go-server# ls -ld /proc/840/cwd
lrwxrwxrwx 1 root root 0 Jan 15 09:40 /proc/840/cwd -> /var/lib/go-server

I believe the issue is that only the go.jar has been changed in the 
upgrade, while one that i know of and possibly many of the other files, the 
defaults or schema has changed, that a full install would have changed. I 
know the default jetty.xml has changed between 17.10 and 17.12, upgrades 
need to address these types of changes as well or at least warn during the 
upgrade.

Kind regards

Barry

On Friday, 12 January 2018 20:51:11 UTC, Aravind SV wrote:
>
> Hmm. That's unlikely. Upgrades are just a copy of the JAR file over to 
> that location. Can you check what the md5sum or shasum of the go.jar file? 
> It's usually in /usr/share/go-server.
>
> Or you can find it using: *pgrep -lf go.jar*
>
> If they're the same, then the same code should be executing. Then, I'd be 
> interested in finding out the current working directory of the two. 
> Something like: ls -ld /proc/*PID*/cwd, where the PID is replaced with 
> the process ID of the GoCD server process.
>
>
> On Fri, Jan 12, 2018 at 7:37 AM, 'Barry Greenwood' via go-cd <
> go...@googlegroups.com > wrote:
>
>> I have tested with "lsof -n -t /var/lib/go-server/libs/" on a new server 
>> that is working and with our existing server that has been upgraded, the 
>> java (go) process is acceing the files on the new server and and no process 
>> is accessing the libs on the upgraded server.
>>
>> I believe this is an issue with upgrading/
>>
>> Regards
>>
>> Barry 
>>
>>
>> On Wednesday, 10 January 2018 16:14:08 UTC, Ketan Padegaonkar wrote:
>>>
>>> This script 
>>>  worked 
>>> for me, I was able to confirm that logs were sent to logback.
>>>
>>> On Wed, Jan 10, 2018 at 8:51 PM 'Barry Greenwood' via go-cd <
>>> go...@googlegroups.com> wrote:
>>>
 Thanks for the update

 That folder didnt exist on our server, I have added with go 
 permissions, I've added the files but it still isnt working.

 as this isnt the first issue i've had regarding this recently 
 implemented feature can you please confirm that it works and should the 
 logs show it being loaded ?

 Many thanks

 Barry


 On Wednesday, 10 January 2018 13:56:09 UTC, Ketan Padegaonkar wrote:

> The `libs` dir is relative to the working directory of the 
> server/agent. This should typically be `/var/lib/go-server/libs` or 
> `/var/lib/go-agent/libs`. I'll update the documentation to clarify this.
>
>
> On Wed, Jan 10, 2018 at 6:29 PM 'Barry Greenwood' via go-cd <
> go...@googlegroups.com> wrote:
>
 Hi all
>>
>> I've now got logback able to log to local files with access requests 
>> and other logs, I am now hoping to ship these to an external logstash 
>> server
>>
>> reading 
>> https://docs.gocd.org/current/advanced_usage/logging.html#advanced-logging-features
>>  
>> this should be possible, however its a little abiguous with "download 
>> all logstash-logback-encoder jars and dependencies into libs dir:"
>>
>> I presume its a java library folder as these are jar files but 
>> testing with these in several places that are in the java.library.path, 
>> it 
>> isn't working.
>>
>> Has anyone else tried to get this working and had success ?
>>
>> Regards
>>
>> Barry
>>
>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "go-cd" group.
>>
> To unsubscribe from this group and stop receiving emails from it, send 
>> an email to go-cd+un...@googlegroups.com.
>
>
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
 You received this message because you are subscribed to the Google 
 Groups "go-cd" group.
 To unsubscribe from this group and stop receiving emails from it, send 
 an email to go-cd+un...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

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

-- 
You received this message because you are subscribed to the Google Groups 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, s

Re: [go-cd] logback to a logstash server

2018-01-12 Thread Aravind SV
Hmm. That's unlikely. Upgrades are just a copy of the JAR file over to that
location. Can you check what the md5sum or shasum of the go.jar file? It's
usually in /usr/share/go-server.

Or you can find it using: *pgrep -lf go.jar*

If they're the same, then the same code should be executing. Then, I'd be
interested in finding out the current working directory of the two.
Something like: ls -ld /proc/*PID*/cwd, where the PID is replaced with the
process ID of the GoCD server process.


On Fri, Jan 12, 2018 at 7:37 AM, 'Barry Greenwood' via go-cd <
go-cd@googlegroups.com> wrote:

> I have tested with "lsof -n -t /var/lib/go-server/libs/" on a new server
> that is working and with our existing server that has been upgraded, the
> java (go) process is acceing the files on the new server and and no process
> is accessing the libs on the upgraded server.
>
> I believe this is an issue with upgrading/
>
> Regards
>
> Barry
>
>
> On Wednesday, 10 January 2018 16:14:08 UTC, Ketan Padegaonkar wrote:
>>
>> This script
>>  worked
>> for me, I was able to confirm that logs were sent to logback.
>>
>> On Wed, Jan 10, 2018 at 8:51 PM 'Barry Greenwood' via go-cd <
>> go...@googlegroups.com> wrote:
>>
>>> Thanks for the update
>>>
>>> That folder didnt exist on our server, I have added with go permissions,
>>> I've added the files but it still isnt working.
>>>
>>> as this isnt the first issue i've had regarding this recently
>>> implemented feature can you please confirm that it works and should the
>>> logs show it being loaded ?
>>>
>>> Many thanks
>>>
>>> Barry
>>>
>>>
>>> On Wednesday, 10 January 2018 13:56:09 UTC, Ketan Padegaonkar wrote:
>>>
 The `libs` dir is relative to the working directory of the
 server/agent. This should typically be `/var/lib/go-server/libs` or
 `/var/lib/go-agent/libs`. I'll update the documentation to clarify this.


 On Wed, Jan 10, 2018 at 6:29 PM 'Barry Greenwood' via go-cd <
 go...@googlegroups.com> wrote:

>>> Hi all
>
> I've now got logback able to log to local files with access requests
> and other logs, I am now hoping to ship these to an external logstash 
> server
>
> reading https://docs.gocd.org/current/advanced_usage/logging
> .html#advanced-logging-features this should be possible, however its
> a little abiguous with "download all logstash-logback-encoder jars
> and dependencies into libs dir:"
>
> I presume its a java library folder as these are jar files but testing
> with these in several places that are in the java.library.path, it isn't
> working.
>
> Has anyone else tried to get this working and had success ?
>
> Regards
>
> Barry
>
> --
> You received this message because you are subscribed to the Google
> Groups "go-cd" group.
>
 To unsubscribe from this group and stop receiving emails from it, send
> an email to go-cd+un...@googlegroups.com.


> For more options, visit https://groups.google.com/d/optout.
>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "go-cd" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to go-cd+un...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "go-cd" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to go-cd+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 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-cd] logback to a logstash server

2018-01-12 Thread 'Barry Greenwood' via go-cd
I have tested with "lsof -n -t /var/lib/go-server/libs/" on a new server 
that is working and with our existing server that has been upgraded, the 
java (go) process is acceing the files on the new server and and no process 
is accessing the libs on the upgraded server.

I believe this is an issue with upgrading/

Regards

Barry 


On Wednesday, 10 January 2018 16:14:08 UTC, Ketan Padegaonkar wrote:
>
> This script 
>  worked 
> for me, I was able to confirm that logs were sent to logback.
>
> On Wed, Jan 10, 2018 at 8:51 PM 'Barry Greenwood' via go-cd <
> go...@googlegroups.com > wrote:
>
>> Thanks for the update
>>
>> That folder didnt exist on our server, I have added with go permissions, 
>> I've added the files but it still isnt working.
>>
>> as this isnt the first issue i've had regarding this recently implemented 
>> feature can you please confirm that it works and should the logs show it 
>> being loaded ?
>>
>> Many thanks
>>
>> Barry
>>
>>
>> On Wednesday, 10 January 2018 13:56:09 UTC, Ketan Padegaonkar wrote:
>>
>>> The `libs` dir is relative to the working directory of the server/agent. 
>>> This should typically be `/var/lib/go-server/libs` or 
>>> `/var/lib/go-agent/libs`. I'll update the documentation to clarify this.
>>>
>>>
>>> On Wed, Jan 10, 2018 at 6:29 PM 'Barry Greenwood' via go-cd <
>>> go...@googlegroups.com> wrote:
>>>
>> Hi all

 I've now got logback able to log to local files with access requests 
 and other logs, I am now hoping to ship these to an external logstash 
 server

 reading 
 https://docs.gocd.org/current/advanced_usage/logging.html#advanced-logging-features
  
 this should be possible, however its a little abiguous with "download 
 all logstash-logback-encoder jars and dependencies into libs dir:"

 I presume its a java library folder as these are jar files but testing 
 with these in several places that are in the java.library.path, it isn't 
 working.

 Has anyone else tried to get this working and had success ?

 Regards

 Barry

 -- 
 You received this message because you are subscribed to the Google 
 Groups "go-cd" group.

>>> To unsubscribe from this group and stop receiving emails from it, send 
 an email to go-cd+un...@googlegroups.com.
>>>
>>>
 For more options, visit https://groups.google.com/d/optout.

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

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


Re: [go-cd] logback to a logstash server

2018-01-12 Thread 'Barry Greenwood' via go-cd
Thanks Ketan 

Now I am more confused, the libs folder doesn't appear to be being read, 
should it be in a path somewhere ?

looking at the api/support page there are no references to that even though 
we are on 17.12 i can only imagine its related to this not being a fresh 
install onto 17.12. I wouldn't however expect that upgrades in the past 
would break this type of process, I have already defaulted the jetty.xml 
and removed other logging config files, as being a potential problem but it 
hasn't helped.

Socket appender does work (see below), but its output isn't ideal and isnt 
an encoder for it or a way to deserialize the output at the logstash end.

  
MY-LOGSTASH
3319
1
true
  

this also confirms its not a comms issue its a problem with either the libs 
not being picked up or another issue with logging.

I am convinced this is an issue with the server being upgraded rather than 
fresh installed.

Any more help would be appreciated,

Kind regards

Barry

On Wednesday, 10 January 2018 16:14:08 UTC, Ketan Padegaonkar wrote:
>
> This script 
>  worked 
> for me, I was able to confirm that logs were sent to logback.
>
> On Wed, Jan 10, 2018 at 8:51 PM 'Barry Greenwood' via go-cd <
> go...@googlegroups.com > wrote:
>
>> Thanks for the update
>>
>> That folder didnt exist on our server, I have added with go permissions, 
>> I've added the files but it still isnt working.
>>
>> as this isnt the first issue i've had regarding this recently implemented 
>> feature can you please confirm that it works and should the logs show it 
>> being loaded ?
>>
>> Many thanks
>>
>> Barry
>>
>>
>> On Wednesday, 10 January 2018 13:56:09 UTC, Ketan Padegaonkar wrote:
>>
>>> The `libs` dir is relative to the working directory of the server/agent. 
>>> This should typically be `/var/lib/go-server/libs` or 
>>> `/var/lib/go-agent/libs`. I'll update the documentation to clarify this.
>>>
>>>
>>> On Wed, Jan 10, 2018 at 6:29 PM 'Barry Greenwood' via go-cd <
>>> go...@googlegroups.com> wrote:
>>>
>> Hi all

 I've now got logback able to log to local files with access requests 
 and other logs, I am now hoping to ship these to an external logstash 
 server

 reading 
 https://docs.gocd.org/current/advanced_usage/logging.html#advanced-logging-features
  
 this should be possible, however its a little abiguous with "download 
 all logstash-logback-encoder jars and dependencies into libs dir:"

 I presume its a java library folder as these are jar files but testing 
 with these in several places that are in the java.library.path, it isn't 
 working.

 Has anyone else tried to get this working and had success ?

 Regards

 Barry

 -- 
 You received this message because you are subscribed to the Google 
 Groups "go-cd" group.

>>> To unsubscribe from this group and stop receiving emails from it, send 
 an email to go-cd+un...@googlegroups.com.
>>>
>>>
 For more options, visit https://groups.google.com/d/optout.

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

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


Re: [go-cd] logback to a logstash server

2018-01-10 Thread Ketan Padegaonkar
This script 
worked for me, I was able to confirm that logs were sent to logback.

On Wed, Jan 10, 2018 at 8:51 PM 'Barry Greenwood' via go-cd <
go-cd@googlegroups.com> wrote:

> Thanks for the update
>
> That folder didnt exist on our server, I have added with go permissions,
> I've added the files but it still isnt working.
>
> as this isnt the first issue i've had regarding this recently implemented
> feature can you please confirm that it works and should the logs show it
> being loaded ?
>
> Many thanks
>
> Barry
>
>
> On Wednesday, 10 January 2018 13:56:09 UTC, Ketan Padegaonkar wrote:
>
>> The `libs` dir is relative to the working directory of the server/agent.
>> This should typically be `/var/lib/go-server/libs` or
>> `/var/lib/go-agent/libs`. I'll update the documentation to clarify this.
>>
>>
>> On Wed, Jan 10, 2018 at 6:29 PM 'Barry Greenwood' via go-cd <
>> go...@googlegroups.com> wrote:
>>
> Hi all
>>>
>>> I've now got logback able to log to local files with access requests and
>>> other logs, I am now hoping to ship these to an external logstash server
>>>
>>> reading
>>> https://docs.gocd.org/current/advanced_usage/logging.html#advanced-logging-features
>>> this should be possible, however its a little abiguous with "download
>>> all logstash-logback-encoder jars and dependencies into libs dir:"
>>>
>>> I presume its a java library folder as these are jar files but testing
>>> with these in several places that are in the java.library.path, it isn't
>>> working.
>>>
>>> Has anyone else tried to get this working and had success ?
>>>
>>> Regards
>>>
>>> Barry
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "go-cd" group.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to go-cd+un...@googlegroups.com.
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "go-cd" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to go-cd+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 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [go-cd] logback to a logstash server

2018-01-10 Thread 'Barry Greenwood' via go-cd
Thanks for the update

That folder didnt exist on our server, I have added with go permissions, 
I've added the files but it still isnt working.

as this isnt the first issue i've had regarding this recently implemented 
feature can you please confirm that it works and should the logs show it 
being loaded ?

Many thanks

Barry

On Wednesday, 10 January 2018 13:56:09 UTC, Ketan Padegaonkar wrote:
>
> The `libs` dir is relative to the working directory of the server/agent. 
> This should typically be `/var/lib/go-server/libs` or 
> `/var/lib/go-agent/libs`. I'll update the documentation to clarify this.
>
>
> On Wed, Jan 10, 2018 at 6:29 PM 'Barry Greenwood' via go-cd <
> go...@googlegroups.com > wrote:
>
>> Hi all
>>
>> I've now got logback able to log to local files with access requests and 
>> other logs, I am now hoping to ship these to an external logstash server
>>
>> reading 
>> https://docs.gocd.org/current/advanced_usage/logging.html#advanced-logging-features
>>  
>> this should be possible, however its a little abiguous with "download 
>> all logstash-logback-encoder jars and dependencies into libs dir:"
>>
>> I presume its a java library folder as these are jar files but testing 
>> with these in several places that are in the java.library.path, it isn't 
>> working.
>>
>> Has anyone else tried to get this working and had success ?
>>
>> Regards
>>
>> Barry
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "go-cd" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to go-cd+un...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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


Re: [go-cd] logback to a logstash server

2018-01-10 Thread Ketan Padegaonkar
The `libs` dir is relative to the working directory of the server/agent.
This should typically be `/var/lib/go-server/libs` or
`/var/lib/go-agent/libs`. I'll update the documentation to clarify this.


On Wed, Jan 10, 2018 at 6:29 PM 'Barry Greenwood' via go-cd <
go-cd@googlegroups.com> wrote:

> Hi all
>
> I've now got logback able to log to local files with access requests and
> other logs, I am now hoping to ship these to an external logstash server
>
> reading
> https://docs.gocd.org/current/advanced_usage/logging.html#advanced-logging-features
> this should be possible, however its a little abiguous with "download all
> logstash-logback-encoder jars and dependencies into libs dir:"
>
> I presume its a java library folder as these are jar files but testing
> with these in several places that are in the java.library.path, it isn't
> working.
>
> Has anyone else tried to get this working and had success ?
>
> Regards
>
> Barry
>
> --
> You received this message because you are subscribed to the Google Groups
> "go-cd" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to go-cd+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 
"go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to go-cd+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[go-cd] logback to a logstash server

2018-01-10 Thread 'Barry Greenwood' via go-cd
Hi all

I've now got logback able to log to local files with access requests and 
other logs, I am now hoping to ship these to an external logstash server

reading 
https://docs.gocd.org/current/advanced_usage/logging.html#advanced-logging-features
 
this should be possible, however its a little abiguous with "download all 
logstash-logback-encoder jars and dependencies into libs dir:"

I presume its a java library folder as these are jar files but testing with 
these in several places that are in the java.library.path, it isn't working.

Has anyone else tried to get this working and had success ?

Regards

Barry

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