I'm new here and this is my first post :)
I will try to explain, sorry ahead about my grammar
We moved to GPDR few months ago, and my job is to fix all the graph which Stopped working, we notice it was due to a change in data-source, in this case it was the volume of the disks
Ex: xvdg - xvdf (AWS)
What I've done:
Duplicated each old data source template. to a new one with a new name and volume
Then i changed the old graph with the new data source template
The weird thing that happened, this worked on only 1 graph, and all the other graphs I've change, stopped, didn't show data,
Checking the Cacti logs
I notice these graph pollers are gone...
5 pollers are not showing anymore in the logs
I've tried:
Deleting the rrd, so it will recreate itself - it did but no poller
Re cached the poller index - didnt do any change
Messing with RDDTOOL
Then i notice that if i create a new graph with the new data sources it will work
But i got 6x20 of these to do, i need a creative better way to do this
Please help
Thanks
Related
https://apps.microsoft.com/store/detail/name/ID
Linking to my app product page gives "Not Available for bots to index"
What is the proper syntax to place a href link to the product so that users online can view it as html?
I don't have a final solution, just a workaround.
We've been seeing the same issue with our own app for the past few days and we've started seeing reports of people encountering this with all kinds of apps, including even Microsoft's own AppInstaller. It seems to be a server-side rate-limiting/caching issue at Microsoft as changing anything in the URL fixes the problem temporarily -- only to get back to the same issue a few hours later. We also found that VPN-ing to some locations (mostly to the US) helped as well, and this throttling seems to be specific to an app & an availability region (when it got blocked, it blocked across all Europe, but not in US for example). It seems to come & go as we have not seen a big drop in new install counts.
As a temporary solution we ended up adding a random string to the end of the URL. We used GCLID as we found it to be the least offensive way -- it could just as well be a legitimate tracking ID we pass over. So now the URL we link to looks like this:
https://apps.microsoft.com/store/detail/[APPNAME]/[APPID]?gclid=f-3579a28842a7bcac7ba630d698829e9b
Where the "f-xxxx" value is generated using the md5() of the timestamp -- but it could be any ever-changing value, even a random number.
We've reached out to our MS contact about this but we haven't heard back yet.
I encountered the same issue half an hour ago, but it seems recovered now.
If you own an app, you can confirm Product identity in Partner Center:
You can share the direct link and Store ID to help customers find your app in the Store:
URL: https://www.microsoft.com/store/apps/*12CharsAppId*
Store ID: 12CharsAppId
Store protocol link: ms-windows-store://pdp/?productid=12CharsAppId
The above address would be recommended but the apps.microsoft.com URL should also work.
I work on apps.microsoft.com. I can confirm that there was an issue on our end that appeared on August 23. This issue has been resolved.
And the proper link, of course, is this:
https://apps.microsoft.com/store/detail/[your product id here]
I have a running server within Docker and when I create a new Death Knight, the second quest to open Runeforging and apply a buff to the provided weapon will not function. Runeforging appears in the spellbook, but does not open an additional window when clicked on so the quest cannot be completing and using the GM command to complete the quest will not complete it.
Just posting here what I said on Discord for reference. Runeforging was an issue in the core. This isn't related to your setup. Here is the related issue, fixed and already merged in last AC version: https://github.com/azerothcore/azerothcore-wotlk/pull/6612
Graphite intermittently displays cached (old) data and current data if I continuously update it.
Here's what I'm doing:
First I setup a graph to show the last 15 minutes, then continuously hit the "Update Graph" button on the Graphite Composer window. When I do this, I notice some odd behavior:
The graph is drawn with data points going up to the current time X. (Good)
After hitting refresh several times, the graph updates to show points going up to X + 1. (Good)
I continue to hit update and graph reverts back to the view from step 1. (Bad)
Eventually the graph updates correctly and steps forward again, showing all the data.
I found that if I set DEFAULT_CACHE_DURATION inside local_settings.py to 1, this fixes the problem. So I know this issue is related to caching.
But I'm still confused: Why does Graphite sometimes show me old cached data, and sometimes show me current data? It seems like Graphite should eithe show me cached data, or current data. It should never show me current data...then old cached data.
Feel like I'm missing something.
I'm hesitant to set the DEFAULT_CACHE_DURATION to 1, since this seems like a kludge. Any idea how to troubleshoot this further?
I’m using the heartbeat module on my site to make an activity-stream and recently I discovered that it doesn’t display all the new comments.
I’ve displayed group messaging ‘cause I only want to display #username commented on #node_title and nothing more. But for some reason, when there is several comments submitted within a short range of time it either only displays one of the comments or nothing or it makes an entry in the activity-stream which is just blank.
Before I was using the built-in comment-template in Heartbeat but now I’ve tried to create my own instead. It works when I post a comment but when testing it and makes two comments within e.g. 30 seconds it still makes the error.
Are there any known problems with this issue or am I missing something?? I haven’t detected the problem with adding new nodes, which also can occur within a short period of time on my time.
Thanks
Sincere
- Mestika
If you are having display failures in Views, there is a patch someone worked out in February 2012 for Views 6.x-3.x - you might want to try that. It fixes the display for a bunch of fields. See http://drupal.org/node/1295570
I am working on a project using Drupal 6 (6.11 at the moment, haven't yet upgraded to 6.12) and part of the core functionality is the ability to vote on nodes. I'm having some rather weird behaviour that has taken me an age to track down and now I have, I still can't fix it.
This is what I've managed to figure out so far:
The template file sites/default/modules/vote_up_down/theme/vote_up_down_points.tpl.php automatically calls the function template_preprocess_vote_up_down_points() from vote_up_down.module.
vote_up_down.module then queries the database using the values stored in the $variables array that is passed to it
On only one of the 3 occasions this is called on a typical node (in this case forum posts) $variables doesn't have a value for $variables['cid'].
That one occasion is when it reads the score so as to display it below the post itself. And, instead of locating the current post's score, it locates the first-ever-voted-on post's score. (This is because instead of returning the score of one post, it returns the score of all posts and then uses the first one from the list).
I am assuming that $variables is a system-wide constant (looking at the content of it using print_r seems to confirm that) and so perhaps this is a core bug as it should always be the same. I checked the contents of $variables and the only 4 parts of around 50 that are different in the one that doesn't work are: cid - blank, tag - blank (although this is discovered by the function and correctly substituted as 'vote'), zebra - even & id - 2. I imagine the last 2 are not really important for this, so the key must be in why $variables['cid'] is not being passed through.
So, my questions are:
Has anyone had this problem before and how did you fix it?
If not, do you have any tips as to how I can figure out why this is not working correctly?
I can't tell you the answer, but you'll probably have better luck posting this in the module's issue queue, since then the maintainer and others using it will see it.
I can't believe I didn't try this before, but I just upgraded to the latest development snapshot of vote_up_down and the problem went away. A 2 minute fix in the end vs about 6 hours of trying to tie the problem down.
Lesson learnt!