I've posted this issue
but believe I'm now running into a new one. We have automated tests that run every 15 minutes on a Jenkins server. While I'm still seeing the run_loop error listed in the link above, approximately once per hour I'm now seeing the following error in the console's output
Xcrun timed out after 3.64 seconds executing
xcrun instruments -s templates
with a timeout of 30
(RunLoop::Xcrun::TimeoutError)
When I see this and try to open Instruments, it says "Instruments cannot be opened at this time" and the only solution I've found so far is to reboot the server. This is problematic because there are several jobs running on this server at once and rebooting the machine every hour is not ideal. After rebooting the machine, Instruments is able to be opened and the tests run successfully for about another hour.
I can provide any further information necessary, just not sure where to go from here since I don't see much about this issue online.
Edit: My apologies, the missing information is
Xcode: 7.1.1
MacOS: 10.10.5
Calabash-Cucumber: 0.17.0
I have experienced this as well on our Jenkins CI machine running El Cap and Xcode 7.2. The CoreSimulator and instruments environment becomes unstable rather quickly.
Before running your tests, try:
# From Ruby
RunLoop::CoreSimulator.terminate_core_simulator_processes
# From the command line
$ bundle exec run-loop simctl manage-processes
Related
I have this node.js Discord bot that is currently running in production. I run it locally on my Raspberry Pi (doesn't get used a lot so it's cheaper for me). Previously it worked fine, but now, after some time the script exits without logging anything special. This is the command I run in the Raspbian terminal to start the script:
node KMAR.js > plb_log.log 2> plb_error.log &
I run the same script for another bot, on the same RPi. Whenever I start them at the same time, they seem to crash at the same time aswell. This seems to be 2 weeks (sometimes 3 weeks) after I start. I do make use of node cron, but I only have something scheduled a few times a day. It doesn't seem like this cronjob would have anything to do with it.
With previous versions of the bot this wouldn't happen. However, I couldn't find differences between versions that would cause this behaviour.
If it could help, here's the repo of the project. Older versions are included aswell. https://github.com/jwsteens/plb
To summarize my problem; my code exits not quite randomly, but after a few weeks. I can't figure out why this happens, as I get no error messages and I can't find anything in my code which would lead to this issue.
You can write a script that automatically restarts the bot when it crashes or stops.
#!/bin/bash
while :
do
yournodepath yourbotpath
sleep 1
done
save it as start.sh or something
and then instead of running node . you can do
chmod 777 start.sh
./start.sh
and now it will run forever until you exit the script
I'm working on the sources of an application an have the release version of the application installed on the system.
How can i test the modified (and possibly buggy) application without conflicting with the version installed ?
What I want is basically virtual env but for generic applications.
I tried Docker but this has several issues :
I can't get the X11 redirection working. I tried commands like docker run -ti --net=host -e DISPLAY=:0.0 test-docker-geany or docker run -ti -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix test-docker-geany according to some forum threads.
The docker build involves copying the whole codebase to the image as well as installing all the tools and libraries needed to compile which some are not stored in cache and installed each time. So the script takes several minutes each time you want to compile and run.
So my questions are :
Is docker the best solution for such task ? I'm sure this is a problem a lot open source contributors faces but I couldn't find other cases on the net.
If it is not the best solution what are the alternatives ?
Detailed error :
I ran the commands xhost + and the first one I gave in my first issue and I got :
The program 'geany' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
(Details: serial 173 error_code 2 request_code 130 minor_code 3)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
The Dockerfile : https://pastebin.com/p03vaWbU
The warning was finally the cause : i just had to install gtk2-engines-pixbuf according to this thread
EDIT : I misunderstood the success. I get it to work that time because I ran an other GUI program in the docker before. In fact, I finally discovered that trying geany a second time just works although the first try give the error.
I'm using jhbuild to build and run gnome-music.
I'm having a successful build but when I run the command
jhbuild run gnome-music
I get the following error
One of the errors is
1.GstTag was imported without specifying a version first
The rest are in the link above.
I'm not sure how to proceed further,can someone help me out?(I'm using Ubuntu 17.04).
I'm following the steps given on:
https://github.com/GNOME/gnome-music
Gst just warns you against not mentioning a version number. Hence, that's not the error.
The error you are facing is regarding Tracker. As you are on Ubuntu distribution, you should know that Ubuntu disables Tracker by default. Hence jhbuild run gnome-music refuses to start. Tracker is a file-indexing service based on file's metadata.
However, Ubuntu is deciding to enable Tracker by default as many GNOME's core apps relies on it. Read here.
Enable Tracker and jhbuild will pick it up from the host system.
I have been working with linux's version of XAMPP (named LAMPP) for about 3 months now and up until tonight XAMPP has worked fine, but suddenly when I tried to run the command
sudo xampp stop
it gave me this error message:
XAMPP is currently only availably as 32 bit application. Please use a 32 bit compatibility library for your system.
and since then any time I try to run any of the following commands:
sudo xampp start
sudo xampp stop
sudo xampp restart
I get the same message
I want to know why I got this message because xampp has been working flawlessly up until now and in fact, less than 30 minutes ago, I typed sudo xampp start and xampp started up normally and I was able to access localhost/phpmyadmin/
Here is some other info that may be useful:
-My OS is Arch Linux
-I am using the xfce desktop environment
-In the time between starting xampp successfully and trying to stop xampp when I got the error message above, I was trying to get the php mail() function to work by following the steps on this page http://www.absolutelytech.com/2010/07/18/howto-send-emailsusing-mail-function-from-localhost-in-php-through-msmtp-using-gmail-account-on-linux/ and I had just successfully finished step 1 and successfully sent the test email to myself.
-also, when I first got the aforementioned error message, I was still able to access pages via localhost (for instance I had a php file at /opt/lampp/htdocs/Brown/index.php that I could access successfully by typing localhost/Brown/index.php even after I was getting the error message) but then I tried to restart my computer to see if that might fix the issue and now I can't start xampp to begin with.
Please someone help me with this and feel free to ask any follow-up questions if that will help
I figured out my own issue. For anyone who sees this question, I had made a few changes to my php.ini file in attempts to get php's mail() function to work and I wanted to start fresh, so I moved php.ini to php_old.ini and copied a file named php.ini-pre1.7.2 to php.ini thinking that php.ini-pre1.7.2 was a file containing the default configuration of php.ini in case one might want to roll back to the defaults, but instead it is something entirely different. My issue was completely fixed when I moved php_old.ini back to php.ini
2021 and the same happened to me after trying to match php.ini seetings between a Windows environment and a Ubuntu 20.04 one. Everywhere I saw it told me to comment a section in the /opt/lampp/lampp file but it messed up my installation and I lost track of what was wrong. After re-installing LAMPP I matched the settings one by one restarting with sudo opt/lampp/lampp restart at each modification. The culprit was:
browscap="C:\xampp\php\extras\browscap.ini"
This line has to be stay commented (just put a semicolon at the start of the line), if you need it then this workaround may help you. Cheers!
I am trying to Install Cygwin 64 bit on a Windows 2012R2 (64 bit).
Downloading and initial setup went through but when it reached man-db (/etc/postinstall/man-db) the setup hangs
and remains so forever. I waited more than 1.5 Hours but still no progress.
I checked log file in /var/log/setup.log which has following contents.
Updating index cache for path `/usr/share/man/man1'. Wait...
Processing manual pages under /usr/share/man...
/usr/bin/mandb: warning: /usr/share/man/man1/col.1.gz: whatis parse for col(1) failed
/usr/bin/mandb: warning: /usr/share/man/man1/imv.1 is a dangling symlink
/usr/bin/mandb: iconv_open ("UTF-8//IGNORE", "utf8"): Invalid argument
/usr/bin/mandb: warning: /usr/share/man/man1/mc.1.gz: whatis parse for mc(1) failed
I am not sure if I should cancel and start again. Will this setup come out of this stage with at least some error?
Did anyone install 64 bit Cygwin and got this error ?
Please help
Happens to me often. I was setting up 8 servers this week and it happened to 3 of them. Waited many hours and it is still would not finish. Sometimes the re-installation works, some it does not. So I have resorted to kill the mandb.exe process and that allows the installer to finish normally. So far I have found no side effects of doing so.
After waiting for more than 3 hours, I decided to cancel the setup. Then I tried a reinstall, following the steps exactly as in the first install. I did not add or remove any packages. The already selected packages in the first attempt were recognized as installed. This time, the setup stopped at the above step (man-db) briefly and then completed the installation. No errors. So, re-installation solved my problem.
Late to the party, but —
When mandb.exe hung, I killed its parent bash.exe via Task Manager and the installation completed.
I then killed mandb.exe in Task Manager, since it was still running.
I then opened a Cygwin shell and ran mandb -cds. -c recreates the index, -d prints messages (so you can actually tell it's doing something constructive!) and -s suppresses checking for orphaned formatted manual pages ("stray cats").
As I write this, mandb is still chugging along, three or four hours later, with plenty yet to go.
So I'll remember to file a bug report later :) , I did notice one oddity during the mandb run:
mandb: /usr/share/man/man3/jN.3 is self referencing
mandb: warning: /usr/share/man/man3/jnf.3.gz: bad symlink or ROFF `.so' request
I've been struggling with the same problem today until I realised that moving the main Cygwin setup window revealed a popup complaining about "can't open (null) for reading: no such file"
This happens multiple times in a (re)install