I'm trying to run GoCD on MacOS (10.12) for testing purposes. When I run both the server and the client apps, they do not provide any GUI output (they should show progress bars or a host configuration) and they quit a couple of seconds after starting.
When I try to run the apps from Terminal as:
/Applications/Go\ Server.app/Contents/MacOS/go-server
I get the following output:
Got directory: /Users/taatyyu1/Library/Application Support/Go Server [It exists]
and then the app quits.
How can I discover what is the issue of the apps not starting properly?
The logs of the apps are available in
~/Library/Application\ Support/Go\ Server/osx-app.log
and
~/Library/Application\ Support/Go\ Agent/osx-app.log
They contain the information from apps starting up and you can use them to figure out what goes wrong
Related
Main issue is docker desktop is not starting in mac &
The status bar is showing docker desktop is starting but this process is not ending
I tried system reboot multiple times, Reinstallation of different docker desktop versions but didn't help.
I found answers which mentioned to change the Preferences -> Settings and allocation of different memory and core to docker desktop here but settings page is also in endless loading state
Internet speed ~10MBps| mac OS 10.14 Mojave | 16GB RAM|. Please help fixing it
When Docker preference setting page is not working
Click on Docker desktop icon >> Preferences ( This page is not loading) >> Click on the Troubleshoot icon ( top right corner with a bug image placeholder) >> Reset to factory defaults
I've been trying so many things to make it work and the only thing that worked for me in Windows was running this in cmd
"C:\Program Files\Docker\Docker\DockerCli.exe" -SwitchDaemon
I took this on Docker cannot start on Windows
Try this: Github Link it works for me!
I found a magical solution, first open the docker preferences settings, and then click the docker icon in the status bar to select restart. At this time, you will be surprised to find that the settings UI is no longer in the loading state, then select Kubernetes in this short time, cancel the enable Kubernetes option, finally click the application below and restart. docker returned to normal. All this should be caused by Kubernetes not starting normally.
Docker version 2.2.0.5
macOS High Sieera 10.13.6
On my side I had a similar issue on my Windows machine.
It was probably caused by a forced shutdown after sleep mode (perhaps no more battery).
I tried many things like restarting the Services but it was not working when I started to watch the folder .docker in my home directory.
I did this:
I first stopped my Docker Desktop process
then I deleted the file named .token_seed.lock in ${USER_HOME}/.docker/
Start the Docker Desktop from the shortcut
and after that my Docker was running without any issue and my stored images were correctly displayed (and starting / stopping properly).
Docker demon isn’t responding all your need is
Quit docker desktop.
force quit all docker processes in activity monitor (this should force stop the demon).
start docker desktop again.
I was having the same issue and what it solved it was to force Docker using Linux language. You can use this command for that:
'C:\Program Files\Docker\Docker\DockerCLI.exe' -SwitchLinuxEngine
1 - If you haven't already, follow Microsoft's Steps 4-6
https://learn.microsoft.com/en-us/windows/wsl/install-manual#step-4---download-the-linux-kernel-update-package
After setting up your distro
2 - Inside Docker Click on the Bug Icon (next to the settings top)
3 - Do Factory reset for Docker
4 - Stop Docker from Task Manager
5 - Run this command
'C:\Program Files\Docker\Docker\DockerCLI.exe' -SwitchLinuxEngine
6 - Now Launch Docker and it will work! hopefully.
If it doesn't (in step 3 I also deleted Containers, WSL settings, Hyper V) from Docker Settings (Be careful deleting your own Containers is dangerous)
I've just solved this problem.
I'm using docker on Ubuntu vmware.
I think, the cause is just docker engine is not started.
The solution is below:
This function is for virtual machine in the virtual machine.
Oh yes, so now we can run the docker engine successfully.
Of course, the "forever loading" problem has been solved.
I have encountered the exact same problem right after I added a key-value pair into the Docker daemon configuration file through the Docker Desktop -> Preferences -> Docker Engine tab. The change broke my Docker engine and I couldn't undo my changes through UI since the UI was broken and showing the loading animation.
I solved the problem by manually removing the changes I made. The daemon configuration file is located in ~/.docker/daemon.json.
I'm trying to run a Quarkus application that was running just fine in dev mode. I had a basic hello-world app. I added a few other resources just to see how that worked. At some point, my app would no longer stay running. It does build successfully (no errors/failures) but won't stay running. (It should be listening on port 3000). I tried running it with
mvn compile quarkus:dev -X
And while that does produce quite a bit more output, there are no errors. The app just exits. I'm not sure how to go about troubleshooting this.
I set up a CI server for Xamarin.Forms using TeamCity on a mini Mac. When I run the build command from the terminal as root it builds successfully, but when I try to fire up a build from the Web UI it fails with the following error:
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(0,0):
Tool exited with code: 1. Output: mdimport will not import on behalf
of root user. Exiting.
Amr, I cannot speak to Mac, but in Windows TC installs by default with the system account which would prevent any program/tools installed under a specific user account to run from TC Web UI. In Windows, I had to change the account for the service under which the teamcity server runs. I'm guessing you would have to do the same for Mac.
Stop the TC server service. Change the service user from system to your user. Start the TC server service.
this happens when you do:
sudo mdimport
but not:
mdimport
So, make sure that you currently own the current folder and you have read, write and execute permissions as well.
The solution is to install TeamCity in the recommended directory which is the /Library/TeamCity folder.
I've successfully run IOS UI Automation Instruments from command line on my local Mac. When it starts to test, the simulator will automatically pop up and then do the stuff.
However, when I SSH to a build server (with OSX and xcode, will use Jenkins eventually) and try to do the same thing, it doesn't work well.
Building process is fine, but as long as I run instruments, the terminal will then hang there without doing anything. I figure it has something to do with iphone simulator GUI but since it's CLI, I don't know what's going on...
Do you guys have any idea? Thanks!!
.
After executing the command from Jenkins through SSH; in most cases you would see a pop up window as in the screen shot. You will have to get past this screen to execute your tests. This post addresses how to get past that issue Stop "developer tools access needs to take control of another process for debugging to continue" alert
I've had the same issue. instruments -w "$DEVICE" were ignoring parameters.
Same with
DEVICE_TARGET='iPhone 6 (8.1 Simulator)' cucumber --format json -o test-reports/cucumber-8.1-iphone.json
It were ignoring DEVICE_TARGET parameter.
Solved via running Jenkins slave NOT as a SSH slave but as the Slave agent via java web start
http://i.stack.imgur.com/lNlPA.png
As i understand this issue is caused by OS X launchagent that managing sshd and performs scope of restrictions for remote users.
IMPORTANT! Slave agent should be started from OS X desktop, not via ssh! I've connected via VNC and launched slave java web agent on the OS X UI terminal.
Does anyone know a good method to debug server side code?
I tried enable Node.js debug then use node-inspector but it does not show any of my code.
I end up using console.log but this is very inefficient.
Update: I found the following procedure works on my Linux machine:
When you run Meteor, it will spawn two processes
process1: /usr/lib/meteor/bin/node /usr/lib/meteor/app/meteor/meteor.js
process2: /usr/lib/meteor/bin/node /home/paul/codes/bbtest_code/bbtest02/.meteor/local/build/main.js --keepalive
You need to send kill -s USR1 on process2
Run node-inspector and you can see your server code
On my first try, I modify the last line on meteor startup script in /usr/lib/meteor/bin/meteor to
exec "$DEV_BUNDLE/bin/node" $NODE_DEBUG "$METEOR" "$#"
and run NODE_DEBUG=--debug meteor on command prompt. This only put --debug flag on process1 so I only see meteor files on node-inspector and could not find my code.
Can someone check this on Windows and Mac machine?
In Meteor 0.5.4 this has become a lot easier:
First run the following commands from the terminal:
npm install -g node-inspector
node-inspector &
export NODE_OPTIONS='--debug-brk'
meteor
And then open http://localhost:8080 in your browser to view the node-inspector console.
Update
Since Meteor 1.0 you can just type
meteor debug
which is essentially a shortcut for the above commands, and then launch node inspector in your browser as mentioned.
Update
In Meteor 1.0.2 a console or shell has been added. It may come in handy to output variables and run commands on the server:
meteor shell
Meteor apps are Node.js apps. When running a Meteor app with the meteor [run] command, you can configure the NODE_OPTIONS environment variable to start node in debug mode.
Examples of NODE_OPTIONS environment variable values:
--debug
--debug=47977 - specify a port
--debug-brk - break on the first statement
--debug-brk=5858 - specify a port and break on the first statement
If you export NODE_OPTIONS=--debug, all meteor command run from the same shell will inherit the environment variable. Alternatively, you can enable debugging just for one run, with NODE_OPTIONS="--debug=47977" meteor.
To debug, run node-inspector in a different shell, then go to http://localhost:8080/debug?port=<the port you specified in NODE_OPTIONS>, regardless of what node-inspector tells you to run.
To start node.js in debug mode, I did it this way:
open /usr/lib/meteor/app/meteor/run.js
before
nodeOptions.push(path.join(options.bundlePath, 'main.js'));
add
nodeOptions.push('--debug');
Here are additional practical steps for your to attach debugger eclipse:
use '--debug-brk' instead of '--debug' here, because it's easier for me to attach node.js using eclipse as debugger.
add 'debugger;' in the code where you want to debug.(I prefer this way personally)
run meteor in console
attach to node.js in eclipse(V8 tools, attach to localhost:5858)
run, wait for debugger to be hit
when you start meteor in your meteor app folder, you'll see that "debugger listening on port 5858" in console.
On Meteor 1.0.3.1 (update to Sergey.Simonchik answer)
Start your server with meteor run --debug-port=<port-number>
Point browser to http://localhost:6222/debug?port=<port-number>
Where <port-number> is a port you specify.
In your code add a debugger; where you want to set your break point.
Depending on where debugger; is invoked, it will either break on your client or server browser window with inspector opened.
I like to set breakpoints via a GUI. This way I don't have to remember to remove any debugging code from my app.
This is how I managed to do it server side for my local meteor app:
meteor debug
start your app this way.
Open Chrome to the address it gives you. You MAY need to install https://github.com/node-inspector/node-inspector (it might come bundled with Meteor now? not sure)
You'll see some weird internal meteor code (not the app code you wrote). Press play to run the code. This code simply starts up your server to listen for connections.
Only after you press play you'll see a new directory in your debugger folder structure called "app". In there are your meteor project files. Set a breakpoint in there one the line you want.
Open the local address of your app. This will run your server side code and you you should be able to hit your breakpoint!
Note: you have to reopen the inspector and go through this process again each time your app restarts!
As of Meteor 1.0.2 probably the best way for server-side debugging is directly via the new built-in shell: with running server run meteor shell. More info here: https://www.meteor.com/blog/2014/12/19/meteor-102-meteor-shell
I am not sure why it was not working for you.
I am able to use it by following steps on console (Mac).
$ ps
$ kill -s USR1 *meteor_node_process_id*
$ node-inspector &
Above steps are mentioned on https://github.com/dannycoates/node-inspector. It is for attaching node-inspector to running node process.
I wrote a small meteor package called meteor-inspector which simplifies the use of node-inspector to debug meteor apps. It internally manages the lifecycle of node-inspector and hence, the user does not need to restart the debugger manually after some files have changed.
For more details and concrete usage instructions take a look at https://github.com/broth-eu/meteor-inspector.
for meteor 1.3.5.2, run
meteor debug --debug-port 5858+n
n is a non-zero number, this will cause node-inspector use 8080+n as web port.
WebStorm, the powerful IDE free for open source developers, makes it much easier to debug server-side.
I've tested it on Windows, and the configuration was painless - see my answer.
A inspector that solve my issues is meteor server console. Here is the process I followed to install it:
In your project folder, add the smart package server-eval:
mrt add server-eval
For Meteor 1.0:
meteor add gandev:server-eval
Restart meteor.
Download crx Chrome extension file from here.
Open extensions page in Chrome and drag crx file to extensions page.
Restart Chrome.
Check the web inspector out to eval server side code:
In comparison with node-inspector, I have a clearer output.
If you prefer to use nodeJS' official debugger you can call NODE_OPTIONS='--debug' meteor and then (on a different shell) node debug localhost:5858.