I get the following error while attempting to use the "save hook" functionality in Bosun -
failed to call save hook: fork/exec /tools/bosun/bin/save-hook: exec format error. Restoring config: successful
The file is executable and I've removed all logic from it, and the error still occurs.
Should the file return anything? Or is this a bug?
The documentation indicates it should be successful as long as the hook exits ok.
https://bosun.org/system_configuration#commandhookpath
I would guess the OS is not accepting this as a proper executable?
If a binary, did you compile it on the same system, or make sure your cross compiled it for the right architecture?
If a script, does your script have the bang line at the start, for example #!/bin/bash?
Related
From the linux console I run a windows console tool using:
wine console_tool.exe ....
The console tool does not involve any windows. It's output is just textual.
Some output is added repeatedly after a given delay time.
However, besides the output of the console_tool.exe I get repeatedly the following error message also interleaved with the other output:
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
I already tried to export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 but then the only change is that the error message changes:
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
I also attempted to apt install the :i386 version of the libgtk3-nocsd.so.0 but it doesn't seem to exists.
I don't know why a console application may trigger a gtk error message. This is beyond my knowledge.
My preferred goal would be to tell wine that the .exe does not use windows and it does not need to not use gtk for windows emulation at all. However, as this may not be possible, my second preferred goal would be to solve the gtk issue.
Can you help me achieve at least one of those goals?
I do not know what the error messages mean. However, the wineconsole command runs console executable using wine. Example:
wineconsole console_tool.exe
After making some changes in a JSON manifest file, I was trying to update it following the Amazon documentation:
ask smapi update-skill-manifest -g development -s amzn1.ask.skill.xxxx --manifest "skillManifest.json" --debug
I kept getting this error:
The error was not pointing to what the error was but my guess was that it was related to the parameters, but that was strange as I was following the documentation to letter.
I then tried, instead of passing the json file, to cat the content of the file, which would be either:
For Powershell: --manifest "$(type skillmanifest.json)"
For Linux: --manifest "$(cat skillmanifest.json)"
I still kept getting the same error.
Firstly, for debugging and getting a more accurate error, I checked my ASK-CLi version, which was outdated.
After updating ASK to the latest version I was still getting the same error.
At that point it started including an error object, which was saying:
When looking into Parsing error due to invalid body. and INVALID_REQUEST_PARAMETER through the error codes, it just said the body of the request cannot be parsed.
After research and playing around, the problem was the manifest parameter, changing it to "file:FILENAME" solved the issue:
--manifest "file:skillmanifest.json"
The documentation is not stating this but it seems necessary for it to go through.
I hope this helps someone out there avoid spending a full day troubleshooting.
Okay - so here is what I'm trying to do.
I've got this password protected CSV file I'm trying to import into R.
I can import it fine using:
read.csv()
and when I run my code in RStudio everything works perfect.
However, when I try and run my .R file using a batch file (windows .bat) it doesn't work. I want to use the .BAT file so that I can set up a scheduled task to run my code every morning.
Here is my .BAT file:
"E:\R-3.0.2\bin\x64\R.exe" CMD BATCH "E:\Control Files\download_data.R" "E:\Control Files\DailyEmail.txt"
And here is my .R file:
url <- "http://username:password#www.url.csv"
data <- read.csv(url, skip=1)
** note, I've put my username/password and the exact location of the CSV in my code. I've used generic stuff here, as this is work related and posting usernames and passwords is probably frowned upon.
As I've said, this code works fine when I use it in RStudio. But fails when I use the .BAT file.
I get the following error message:
Error in download.file(url, "E:/data/data.csv") :
cannot open URL 'websiteurl'
In addition: Warning message:
In download.file(url, "E:/data/data.csv") :
unable to resolve 'username'
Execution halted
** above websiteurl is the http above (I can't post links)
So obviously, the .BAT is having trouble with the username/password? Any thoughts?
* EDIT *
I've gone so far as trying this on Linux. Thinking maybe windows was playing silly bugger.
Just from the terminal, I run Rscript -e "download_data.r" and get the EXACT same error message as I did in Windows. So I suspect this may be a problem with where I'm getting the data? Could the provider be blocking data from the command line, but not from with Rstudio?
I have had similar problems which had to do with file permissions. The .bat file somehow does not have the same privileges as you running the code directly from Rstudio. Try using rscript (http://stat.ethz.ch/R-manual/R-devel/library/utils/html/Rscript.html) within your .bat file like
Rscript "E:\Control Files\download_data.R"
What is the purpose of the argument "E:\Control Files\DailyEmail.txt"? Is the program suppose to use it in any way?
So, I've found a solution, which is likely not the most practical for most people, but works for me.
What I did was migrated my project over to a Linux system. Running daily scripts, is easier on Linux anyways.
The solution makes use of the "wget" function in linux.
You can either run the wget right in your shell script, or make use of the system() function in R to run the wget.
code looks like:
wget -O /home/user/.../file.csv --user=userid --password='password' http://www.url.com/file.csv
And you can do something like:
syscomand >- "wget -O /home/.../file.csv --user=userid --password='password' http://www.url.com/file.csv"
system (syscommand)
in R to download the CSV to a location on your hard drive, then grab the CSV using read.csv()
Doing it this way gave me some more insight into the potential root cause of the problem. While the system(syscommand) is running, I get the following output:
Connecting to www.website.com (www.website.com)|ip.ad.re.ss|:80... connected.
HTTP request sent, awaiting response... 401 Unauthorized
Reusing existing connection to www.weburl.com:80.
HTTP request sent, awaiting response... 200 OK
Not sure why it has to send the request twice? And why I'm getting a 401 Unauthorized the first try?
I keep getting this error when trying to run riak commands.
The nodetool file does not exist in that directory. When I copy the nodetool file from 5.8.4 I start getting this error:
{"init terminating in do_boot",{'cannot get bootfile','start_clean.boot'}}
EDIT
I followed this great advice here: http://onerlang.blogspot.co.uk/2009/10/fighting-with-riak.html. Now when I run riak start I get:
Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
Crash dump was written to: erl_crash.dump
init terminating in do_boot ()
Error reading /abc/def/otp_src_R14B03/riak-1.1.2/dev/dev1/etc/app.config
{"init terminating in do_boot",{'cannot get bootfile','start_clean.boot'}}
EDIT 2
I seem to be getting this problem http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-November/006436.html.
Whenever I build from source (required for multiple nodes on the same machine) riak tries to user erts-5.8.5 whereas riak requires(?) erts-5.8.4.
Is it possible for me to tell to not use 5.8.5 and use 5.8.4 maybe?
I've often been frustrated by R's cryptic error messages. I'm not talking about during an interactive session, I mean when you're running a script. Error messages don't print out line numbers, and it's often hard to trace the offending line, and the reason for the error (even if you can find the location).
Most recently my R script failed with the the incredibly insightful message: "Execution halted." The way I usually trace such errors is by putting a lot of print statements throughout the script -- but this is a pain. I sometimes have to go through the script line by line in an interactive session to find the error.
Does anyone have a better solution for how to make R error output more informative?
EDIT: Many R-debugging things work for interactive sessions. I'm looking for help on command-line scripts run through Rscript. I'm not in the middle of an R session when the error happens, I'm at the bash shell. I can't run "traceback()"
Try some of the suggestions in this post:
General suggestions for debugging in R
Specifically, findLineNum() and traceback()/setBreakpoint().
#Nathan Well add this line sink(stdout(), type="message") at the beginning of the script and you should get in console message both script content and output along with error message so you can see it as in interactive mode in the console. (you can then also redirect to a log file if you prefer keeping the console "clean")
Have a look at my package tryCatchLog (https://github.com/aryoda/tryCatchLog).
While it is impossible to improve the R error messages directly you can save a lot of time by identifying the exact code line of the error and have actual variables at the moment of the error stored in a dump for "post mortem" analysis!
The main advantages of the tryCatchLog function over tryCatch are
easy logging of errors, warnings and messages into a file or console
warnings do not stop the program execution (tryCatch stops the execution if you pass a warning handler function)
identifies the source of errors and warnings by logging a stack trace with a reference to the source file name and line number (since traceback does not contain the full stack trace)
allows post-mortem analysis after errors by creating a dump file with all variables of the global environment (workspace) and each function called (via dump.frames) - very helpful for batch jobs that you cannot debug on the server directly to reproduce the error!
This will show a more detailed traceback, but not the line number:
options(error = function() {traceback(2, max.lines=100); if(!interactive()) quit(save="no", status=1, runLast=T)})
One way inside a script to get more info on where the error occurred is to redirect R message to the same stream as errors :
sink(stdout(), type="message")
This way you get both messages and errors in the same output so you see which line raised the error...