| To: | Ken McDonell <kenj@xxxxxxxxxxxxxxxx>, Alec Ten Harmsel <alec@xxxxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [pcp] qa/1111 failing pretty much every place it is run |
| From: | Nathan Scott <nathans@xxxxxxxxxx> |
| Date: | Tue, 12 Jul 2016 20:19:48 -0400 (EDT) |
| Cc: | PCP <pcp@xxxxxxxxxxx> |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <131083523.5554077.1468368582128.JavaMail.zimbra@xxxxxxxxxx> |
| References: | <57858370.8030700@xxxxxxxxxxxxxxxx> <131083523.5554077.1468368582128.JavaMail.zimbra@xxxxxxxxxx> |
| Reply-to: | Nathan Scott <nathans@xxxxxxxxxx> |
| Thread-index: | uqWpk+WiH6CzLcRzZmjSpsWQ10mvaHUI3EFZ |
| Thread-topic: | qa/1111 failing pretty much every place it is run |
----- Original Message ----- > ----- Original Message ----- > > I'm seeing 2 failure signatures. > > > > .out.bad files attached > > > > Any help would be appreciated as I have no clue what this test is or > > should be doing. > > This test is exercising the new pcp2influxdb(1) command. There should > be a 1111.full associated with these failures, which I think we'll need > I've attached a .full from one of my local runs where it's passing - Alec, I notice there's several stacktraces there - is that due to socat closing the connection (rather than the client)? We might want to have some cleaner error reporting in pcp2influxdb there - I guess it is feasible influxdb could restart and cause the same trace? If so a less alarming end-user diagnostic would be preferable. cheers. -- Nathan
|
| Previous by Date: | Re: [pcp] qa/1111 failing pretty much every place it is run, Nathan Scott |
|---|---|
| Next by Date: | Re: [pcp] qa/1111 failing pretty much every place it is run, Ken McDonell |
| Previous by Thread: | Re: [pcp] qa/1111 failing pretty much every place it is run, Nathan Scott |
| Next by Thread: | Re: [pcp] qa/1111 failing pretty much every place it is run, Alec Ten Harmsel |
| Indexes: | [Date] [Thread] [Top] [All Lists] |