On Windows when I execute:
c:\python35\scripts\tensorboard --logdir=C:\Users\Kevin\Documents\dev\Deadpool\Tensorflow-SegNet\logs
and I web browse to http://localhost:6006 the first time I am redirected to http://localhost:6006/[[_traceDataUrl]] and I get the command prompt messages:
W0913 14:32:25.401402 Reloader tf_logging.py:86] Found more than one graph event per run, or there was a metagraph containing a graph_def, as well as one or more graph events. Overwriting the graph with the newest event.
W0913 14:32:25.417002 Reloader tf_logging.py:86] Found more than one metagraph event per run. Overwriting the metagraph with the newest event.
W0913 14:32:36.446222 Thread-2 application.py:241] path /[[_traceDataUrl]] not found, sending 404
When I try http://localhost:6006 again, TensorBoard takes a long time presents the 404 message again but this time displays a blank web page.
Logs directory:
checkpoint
events.out.tfevents.1504911606.LTIIP82
events.out.tfevents.1504912739.LTIIP82
model.ckpt-194000.data-00000-of-00001
model.ckpt-194000.index
model.ckpt-194000.meta
Why am I getting redirected and 404ed?
i'am having the exact same error. Maybe it is because of this issue. So try to Change the env-variable to --logdir=foo:C:\Users\Kevin\Documents\dev\Deadpool\Tensorflow-SegNet\logs.
Hope it helps.
Could it be that you try to access the webpage with IE? Apparently IE is not supported by Tensorboard yet(https://github.com/tensorflow/tensorflow/issues/9372). Maybe use another Browser.
I encountered the same error before, and found that it was due to internet setting problem.
On Internet Explorer, Go to Tools -> Internet Options -> Connections, click LAN settings, and then click Automatic detect settings.
We have TFS 2015 setup with team build alerts. If I create a team alert for Check-ins, all members of the team successfully get an email on code checked-in. If I create a build failure alert and then get the build to fail, no alerts are received by the team. I don't understand why one would work and the other doesn't. SMTP must be setup fine as are team permissions. What could it be? Is there any where i can see logs?
It turns out to be a bug in the version of TFS that we are using (SP1) which is fixed in a later update (SP2 or 3). The issue was build events were not being raised by the TfsJobAgent due to an error:
Exception Message: TF10121: The path '$(SourcePath)' is not found or not supported. Type or select a different path. (type InvalidPathException)
The $(SourcePath) TFS variable is apparently broken but can be bypassed if updated to the SourcePath in the Variables Tab:
I have updated our builds with so they are using this qualified SourcePath. Build Failure notification emails now being received if you break the build. Apparently Slack integration is now also working!
This is apparently an issue in SP1 and is fixed in later service packs
To narrow down this issue, you can try with below ways:
Set alerts just for yourself to see if you can get an e-mail when the
build fail. Detail ways please refer Set alerts, get notified when
changes occur
Double check the query which the alert is based on, there is a default template, you can use it directly such as below picture
Try to use other build alters such as a build completes to see
whether it works
Look for if there are some related errors in Event Log
I have scheduled a C# console application in Task Scheduler of Windows 2012 R2. Application will run when executed it manually or Right click on scheduled task and click on Run, but it is failed when triggered by Task Scheduler with below error.
The operator or administrator has refused the request(0x800710E0)
I have followed below steps also after Google search
Selected "Run whether user logged in or not"
Unchecked "Start the task only if the computer is on AC power"
In my case, the error message "The operator or administrator has refused the request" meant that a previous instance of the task has still been running and the task was configured to not start a new instance if it's already running (the default configuration), so the Task Scheduler refused to start a new instance when the task was triggered.
You can find that option in a select box on the task's Settings tab, under the caption "If the task is already running, then the following rule applies". The default value is "Do not start a new instance".
But that error message is pretty confusing. From the other answers, you may see that it may mean many completely distinct errors. As is usual in Microsoft's products.
Tip
It's helpful to check the History tab of a task. That's where I have found out what's actually going on. There was an event "Launch request ignored, instance already running".
In my case, I had to redo the permissions on the task. Somehow it had lost the domain portion of the username. Instead of `DOMAIN\joeuser' it was just 'joeuser'. After a reset, it worked correctly as it had for the previous year.
In my case as per having a job setup with Task Scheduler as written about in the "Prevent a Task Scheduler Task from Executing on Setting Updates", I had a job setup to run every "X" minutes for a period of indefinitely.
Upon seeing the dreaded "The operator or administrator has refused the request" for the Last Run Result, I looked over the History tab and see detail indicating that is "missed its schedule".
The Solution
From the Settings tab of the job properties, I simply checked the option "Run task as soon as possible after a scheduled start is missed", and problem resolved; although, I did have to type in the credential again as well.
Note: This started occurring once a server was moved from a redundant backup server once hardware repair was completed back to the original hardware. The OS was Server 2012 R2 and the OS was moved to other hardware while repair was done on the production server but I didn't notice this there—maybe an oversight there though—not sure.
I know that #Sushmit-Patil found a solution, but I wanted to add a solution to my similar problem:
It turns out a prior process never exited (it was hanging around in memory because of a defect I had in my code). By default, Windows Task Scheduler won't run the process again if it's already running.
In addition to fixing the defect, in Task Scheduler, under the Settings tab, I set If the task is already running, then the following rule applies: to Run a new instance in parallel
1
Error occurred due to folder permission, I was creating CSV from my application, which was required folder permission to be granted. After giving Full Control to the folder error got resolved.
For me, the solution was to check Run with highest privileges in the properties.
In my case my task launches a PowerShell script--and it produced the "The operator or administrator has refused the request (0x800710E0)" error message as seen in the Task Scheduler's task-entry grid. My user name was correct, but when I dropped to a command prompt and simulated the task by running the PowerShell against my .ps1 file, I saw an Avast prompt that flagged my script as suspicious and wasn't allowing it to run. I created an Avast exception and now the task runs without any issue.
After turning on history I also had the error "Missed task start rejected: Task Scheduler did not launch task as it missed its schedule." but I didn't want the task to start when I woke up the computer, I wanted to figure out why the computer didn't wake up.
This answer helped me out -- by default Windows was waking for "Important Wake Timers Only" (system updates, but not my scheduled task).
In the setting Power Options > Edit Plan Settings > Change advanced power settings > Sleep > Allow wake timer change the option to "Enabled" and then your computer will wake up to run the task.
You can also do this from "settings". Probably earlier instance was already running and launching a new instance failed.
In my case, the error message "The operator or administrator has refused the request" appeared because the computer was in stand-by at the scheduled time (and the options "Wake the computer to run this task" and "Run task as soon as possible after a scheduled start was missed" were unchecked).
I had previously chosen "Enable All Tasks History" and a more useful error message appeared in the History tab: "Missed task start rejected: Task Scheduler did not launch task as it missed its schedule. Consider using the configuration option to start the task when available, if schedule is missed."
I have found what I believe to be a bizarre bug in Windows Server 2016 scheduler and maybe other Windows Server versions that produces the OP's error (and a workaround):
Here are the conditions:
You're using the "Monthly" option trigger in your task (I currently have all months selected and just a couple days chosen, e.g. 1st and 15th)
You have the "Synchronize across time zones" selected.
This was originally an issue I found back in November 2020 when my tasks were running twice all of a sudden after the DST time change (and this was a widely reported bug, but not an obvious solution). I never would have known, except that users started receiving duplicate emails from one of my tasks. In the history you would simply see the task running twice at what appeared to be exactly the same time. It worked fine before the time change. I forget all the troubleshooting I did then, but my end theory was that it was somehow confusing the time after the time change. The work around was to set the option "Synchronize across time zones" and all seemed well...
Fast forward to March when the DST time just changed back again and now I get every time the tasks with the Monthly option runs:
The operator or administrator has refused the request
The History tab on the task is also blank. If you change options and save, the History tab starts logging again and then sometimes stops if the task errors again. Weird.
One work around is to simply turn off the "Synchronize across time zones" option (tested). However, I don't recommend that option as I assume you'll have the duplicate running task issue again when the DST time changes again in November.
The one time I got an error to show in the History tab it stated:
Task Scheduler did not launch task "\EmailCampaign" as it missed its
schedule. Consider using the configuration option to start the task
when available, if schedule is missed.
Therefore, I went and set that option to start the task if the schedule is missed and all seems well. I figured I'd see the original error and then subsequently the task running, but no error any more either. It all just works.
I know this solution was reported above, but that's because most people's computers were asleep or something to that effect. My issue is on a production internet facing server that doesn't go to sleep, hibernate or anything related and only happens with specific conditions related to the Monthly trigger option. All my others tens of scheduled tasks work flawless.
I wrote a Powershell script to do a task. I was getting this error and landed here (as well as other lower ranked search results). The task would run manually and the first time it was triggered, but not on repeat even though I had it set up to end the task if it took longer than a minute.
My problem was caused by not providing an exit code in my powershell script. Task scheduler simply did not know the task had finished and would consider it still running. I could have simply allowed the next instance of the task to be started if the previous was not finished, but using the exit code is the 'right way'.
So I simply added a new line on the end of my PS1 --
exit
This topic is old but I had the same problem on windows server 2016.
My task executes a BAT script that zip a folder and upload on an external backup.
The task never ended because there was a "pause" at the end of my script. And my task was configured with "Dot not start a new instance" settings.
I solved my problem by removing the "pause". I don't know if it will be useful..
I have stop and restart services(Sharepoint Administration & Sharepoint Timer Service)
I cleaned the Configuration Cache by using mentioned steps.
Summary of the steps to clear the timer job:
Stop SharePoint Timer service on all servers in the farm.
Browse to C:\ProgramData\Microsoft\SharePoint\Config{GUID} where the {GUID} folder contains a bunch of XML files and NOT the files with a “.PERSITEDFILE” extension.
Delete all the XML files
Update the contents of the Cache.ini file to just say “1” (without quotes).
Restart the SharePoint Timer service on each server
Reanalyze the issue in Health Analyzer
Does anyone know why this keeps occurring and how I can stop it?
First of all try and check your ULS Logs and see if there is any error that arise.
Secondly try and maybe check the event viewer on your SharePoint server to see if any errors are shown and make sure you have enough disk space available.
and also you might want to check this :Clearing Timer Services
Let me know if you see any error post it here.
hope it helps.
Yotam.
I am at my wits end on this and can't figure this out. In sitecore v6.2 something has changed that is causing an error message as follows
"The operation could not be completed. Your session may have been lost due to a time-out or server failure".
looks like this is coming from Sitecore.Web.UI.Sheer.ClientPage?
The request info:
https://sitecore.test.domain.com/sitecore/shell/sitecore/content/Applications/Content%20Editor.aspx?ic=People%2f16x16%2fcubes_blue.png
the response:
{"commands":[{"command":"Alert","value":"The operation could not be completed.\n\nYour session may have been lost\ndue to a time-out or a server failure.\n\nTry again."}]}
At first, I assumed it was because plugged in some new HttpModules so I moved them into the sitecore pipeline model and the problem kept persisting. I removed them from the entire application and the problem kept persisting.
A google search on the error gets me to some information on the keepalive.aspx stuff, but addressing that has no bearing.
I decompiled the code with reflector, but can't find anywhere this particular error is raised. It must be in sitecore.nexus or something.
According to my superiors we will open a ticket once we get the build resolved, but here's to hoping someone here has some suggestions.
The constant for this error message is THE_OPERATION_COULD_NOT_BE_COMPLETED_YOUR_SESSION_MAY_HAVE_BEEN_LOSTDUE_TO_A_TIMEOUT_OR_A_SERVER_FAILURE_PLEASE_TRY_AGAIN
This might happened if you server restarts while some dialog opened