error after updating from 0.99a to 0.99c

[wifinerd]

When viewing the ViPullStatistics.pl log, I am getting this error just before it's about to run the "Processing vCenter vcxxxx.xxxxx.com standalone hosts in datacenter yyyyyy" step.

/usr/lib/x86_64-linux-gnu/perl/5.20/IO/Socket.pm line284 - DIE Wide character in send at /usr/lib/x86_64-linux-gnu/perl/5.20/IO/Socket.pm line 284.

I have the original appliance, which was updated to 0.99a and then today directly to 0.99c. The cluster that is failing to run as a result of that error does not show the proper number of VMs in it's inventory list, so my guess is that there is something weird about one of the VMs it's trying to inventory (maybe too many characters?). But we have a few other clusters running the exact same versions with the same long file names throughout and no issues with reporting on those.

Thanks for any assistance!

could you send us the ViPullStatistics.pl log file so we can have a look?

[wifinerd]

Sure, here's a recent snippet:

[2016/08/27 19:50:05] /root/ViPullStatistics.pl line152 - [INFO] Processing vCenter vc01xxx.mgmt.company.com clusters in datacenter xxx
[2016/08/27 19:50:06] /root/ViPullStatistics.pl line387 - [INFO] Processing vCenter vc04yyy.mgmt.company.com standalone hosts in datacenter daas2
[2016/08/27 19:50:06] /root/ViPullStatistics.pl line498 - [INFO] End processing vCenter vc04yyy.mgmt.company.com
[2016/08/27 19:50:11] /root/ViPullStatistics.pl line387 - [INFO] Processing vCenter vc03xxx.mgmt.company.com standalone hosts in datacenter daas1
[2016/08/27 19:50:11] /root/ViPullStatistics.pl line498 - [INFO] End processing vCenter vc03xxx.mgmt.company.com
[2016/08/27 19:50:13] /root/ViPullStatistics.pl line387 - [INFO] Processing vCenter vc03yyy.mgmt.company.com standalone hosts in datacenter yyy
[2016/08/27 19:50:13] /root/ViPullStatistics.pl line498 - [INFO] End processing vCenter vc03yyy.mgmt.company.com
[2016/08/27 19:50:18] /root/ViPullStatistics.pl line387 - [INFO] Processing vCenter vc02yyy.corp.company.com standalone hosts in datacenter yyy-customer
[2016/08/27 19:50:18] /root/ViPullStatistics.pl line498 - [INFO] End processing vCenter vc02yyy.corp.company.com
[2016/08/27 19:50:24] /usr/lib/x86_64-linux-gnu/perl/5.20/IO/Socket.pm line284 - DIE Wide character in send at /usr/lib/x86_64-linux-gnu/perl/5.20/IO/Socket.pm line 284.

The first line (vc01xxx) is the troublesome one where we aren't getting the VM data that we'd like. I think it's getting to that step in the "standalone hosts" section and failing but obviously the log output isn't particularly effusive there.

Thanks!

[wifinerd]

Any thoughts on troubleshooting?

[rschitz]

the error is at the end or at the begining ?

[wifinerd]

The end. I could isolate the issue a bit by disabling polling for the other clusters and just try the troublesome one if that log output would be more valuable?

sure, anything

[wifinerd]

Here's two polling cycles:

[2016/09/01 23:00:01] /root/ViPullStatistics.pl line60 - [INFO] Start processing vCenter vc01xxx.mgmt.company.com
[2016/09/01 23:00:01] /root/ViPullStatistics.pl line82 - [INFO] Login to vCenter vc01xxx.mgmt.company.com
[2016/09/01 23:00:02] /root/ViPullStatistics.pl line96 - [INFO] vCenter vc01xxx.mgmt.company.com session file saved
[2016/09/01 23:00:03] /root/ViPullStatistics.pl line145 - [INFO] Processing vCenter vc01xxx.mgmt.company.com datacenters
[2016/09/01 23:00:04] /root/ViPullStatistics.pl line152 - [INFO] Processing vCenter vc01xxx.mgmt.company.com clusters in datacenter xxx
[2016/09/01 23:00:20] /usr/lib/x86_64-linux-gnu/perl/5.20/IO/Socket.pm line284 - DIE Wide character in send at /usr/lib/x86_64-linux-gnu/perl/5.20/IO/Socket.pm line 284.
[2016/09/01 23:05:02] /root/ViPullStatistics.pl line60 - [INFO] Start processing vCenter vc01xxx.mgmt.company.com
[2016/09/01 23:05:02] /root/ViPullStatistics.pl line82 - [INFO] Login to vCenter vc01xxx.mgmt.company.com
[2016/09/01 23:05:02] /root/ViPullStatistics.pl line96 - [INFO] vCenter vc01xxx.mgmt.company.com session file saved
[2016/09/01 23:05:03] /root/ViPullStatistics.pl line145 - [INFO] Processing vCenter vc01xxx.mgmt.company.com datacenters
[2016/09/01 23:05:04] /root/ViPullStatistics.pl line152 - [INFO] Processing vCenter vc01xxx.mgmt.company.com clusters in datacenter xxx
[2016/09/01 23:05:21] /usr/lib/x86_64-linux-gnu/perl/5.20/IO/Socket.pm line284 - DIE Wide character in send at /usr/lib/x86_64-linux-gnu/perl/5.20/IO/Socket.pm line 284.

[rschitz]

is there any non-alphanumeric characters in one of the the cluster's name?

[wifinerd]

Nope. The only cluster in that vCenter is named 'pod3'

and the datacenter name?

[wifinerd]

It's a 3 letter airport code like 'jfk' or 'lax'. It's named very similarly to the other clusters that aren't having the issue. There are a lot of VMs with parenthesis and dashes and that sort of thing, but that also exists on the other clusters as well so even after searching for something out of the ordinary, I haven't found anything unique yet.

[rschitz]

any vm or datastore name that is "anormaly" long?
someting like 256+ characters wide

[wifinerd]

No datastore names longer than 5 characters.

The VM name is interesting. This is a vCloud environment (as all our others are), so VMs are saved in vApps with very long paths like 'customeridnumber-customernamethatcanbelong-vdc/vappidnumber-customernamethatcanbelong-computerhostname (very long guid that is 36 characters)/vmidnumber-customernamethatcanbelong-computerhostname (very long guid that is 36 characters)'

It's important to note that I just went through and verified that no individual VM name is longer than 90 characters, but if you add the full path together, I could see how it could get above 256 characters. Just not sure if that's what the code is looking at or if it is truly just VM name.

Also, our other datacenters have much the same patterns but I'd have to write a script to find the longest vm or path names to see if this troublesome cluster has longer names. Moreover, the older version of sexigraf didn't have this issue either so I'm still kind of stumped.

[rschitz]

It makes sense because the previous version did not include vm stats so the path length of the vms was not an issue.
If you don’t need vm stats we can figure out something, otherwise I’ll see if it’s possible to find a perl workaround.

From: wifinerd [mailto:notifications@github.com]
Sent: Sunday, September 04, 2016 8:14 PM
To: sexibytes/sexigraf sexigraf@noreply.github.com
Cc: Raphaël SCHITZ raphael@schitz.net; Comment comment@noreply.github.com
Subject: Re: [sexibytes/sexigraf] error after updating from 0.99a to 0.99c (#87)

No datastore names longer than 5 characters.

The VM name is interesting. This is a vCloud environment (as all our others are), so VMs are saved in vApps with very long paths like 'customeridnumber-customernamethatcanbelong-vdc/vappidnumber-customernamethatcanbelong-computerhostname/vmidnumber-customernamethatcanbelong-computerhostname'

It's important to note that I just went through and verified that no individual VM name is longer than 90 characters, but if you add the full path together, I could see how it could get above 256 characters. Just not sure if that's what the code is looking at or if it is truly just VM name.

Also, our other datacenters have much the same patterns but I'd have to write a script to find the longest vm or path names to see if this troublesome cluster has longer names. Moreover, the older version of sexigraf didn't have this issue either so I'm still kind of stumped.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com//issues/87#issuecomment-244619831, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AH_0bqW0BsTB41mVmhFBz8IUSMUExC1gks5qmwplgaJpZM4JunQ1.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/sexibytes/sexigraf","title":"sexibytes/sexigraf","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/sexibytes/sexigraf"}},"updates":{"snippets":[{"icon":"PERSON","message":"@wifinerd in #87: No datastore names longer than 5 characters.\r\n\r\nThe VM name is interesting. This is a vCloud environment (as all our others are), so VMs are saved in vApps with very long paths like 'customeridnumber-customernamethatcanbelong-vdc/vappidnumber-customernamethatcanbelong-computerhostname/vmidnumber-customernamethatcanbelong-computerhostname'\r\n\r\nIt's important to note that I just went through and verified that no individual VM name is longer than 90 characters, but if you add the full path together, I could see how it could get above 256 characters. Just not sure if that's what the code is looking at or if it is truly just VM name.\r\n\r\nAlso, our other datacenters have much the same patterns but I'd have to write a script to find the longest vm or path names to see if this troublesome cluster has longer names. Moreover, the older version of sexigraf didn't have this issue either so I'm still kind of stumped."}],"action":{"name":"View Issue","url":"https://github.com/sexibytes/sexigraf/issues/87#issuecomment-244619831"}}}

[wifinerd]

Ah yes, well that does make sense. I would like VM stats if possible, of course, as that was my primary reason for upgrading. :-)