How can I see the Xcode console history? I accidentally cleared it by running the application again and am wondering if I can get back what was cleared.
Xcode console output is logged in the system log. You can search the system log from the console with grep:
# view last 2000 lines of the system log
sudo tail -n2000 /private/var/log/system.log
# search system log for YourApp
sudo grep YourApp /private/var/log/system.log
# watch the system log as it's being written and filter for YourApp
sudo tail -f /private/var/log/system.log | grep YourApp
Xcode 11:
In the Navigator, press the "Report navigator" button (the speech bubble), then click on your previous run sessions. You can see all your previous console logs.
Related
I am using a watch command(in a shell script) in my docker image.
Command:
watch -d -t -g ls -la ${DIR_TO_WATCH} && sleep 5 && ${COMMAND} | tee
This command is watching a directory and if there is any change in the directory structure, we perform certain actions.
I am using this docker image in my helm chart.
Now, when I deploy the chart and check the logs of that pod, my terminal breaks and it will not be user friendly anymore.
Command:
kubectl logs -f pod-name -n name-space
After this, we need to reset terminal settings to get the terminal behave normal.
Is there anything that can be done to prevent this?
Best Regards,
Akshat
Solved this by sending output of watch to /dev/null.
watch -d -t -g ls -la ${DIR_TO_WATCH} > /dev/null && sleep 5 && ${COMMAND} | tee
The reason, according to my understanding, behind broken terminal was:
Two different command's logs(logs from watch and ${COMMAND}) were showing up on the same terminal at the same time, which resulted in creating a new terminal over the default one(which I am not sure how), causing the default terminal to break.
While ${COMMAND} logs were crucial for me, I did not need to view or monitor logs from watch. Hence, I sent the log outputs of watch to /dev/null and it solved my problem.
Please correct me if my understanding or approach is wrong.
Thank you.
I am trying to figure out how many launch agents are loaded right now using following command the it
find /System/Library/Launch* /Library/Launch* ~/Library/Launch* -name '*.plist' -exec sh -c '/usr/libexec/PlistBuddy -c "Print Label" {} && echo {}' ';' | grep -wf <(launchctl list | grep -o "\S\+\..*$") -A1
grep -B 1 -A 1 "active count = 1$" <<< "$(launchctl dumpstate)"
but its not listed the one I am looking for.
is it correct?
Using launchctl you can list all the running agents and daemons like such:
launchctl list
and
sudo launchctl list
please note that the two are different commands.
Oddly enough, running sudo launchutil list prints out the root daemons, and only the root deamons.
If you are running the commands in the terminal you will want to run the non-sudo version first, because if you don't, the sudo version will create a root session which will force version #1 to have root privileges anyways!
If you would like to find the file path to such an agent or daemon, this
may help.
Edit:
Okay, I don't know how I missed the word "unloaded" in the giant title in your question but... here are the directories that daemons/agents like to hide in (copied from the man page of launchctl):
FILES
~/Library/LaunchAgents Per-user agents provided by the user.
/Library/LaunchAgents Per-user agents provided by the administrator.
/Library/LaunchDaemons System wide daemons provided by the administrator.
/System/Library/LaunchAgents OS X Per-user agents.
/System/Library/LaunchDaemons OS X System wide daemons.
I had your same question and this article was super helpful. I suggest reading through it, but here's a relevant snippet:
While it’s not a simple matter for users to enumerate all the Login Items, admins can do so with a little extra work by parsing the following file, if it exists: ~/Library/ApplicationSupport/com.apple.backgroundtaskmanagementagent/backgrounditems.btm
Parsing that file is more complicated than opening it with your favorite editor. The article links to a paste bin, but this github repo is a one-stop shop. Still, the article will help a lot.
docker-compose on Windows is not able to be run in interactive mode.
ERROR: Interactive mode is not yet supported on Windows.
Please pass the -d flag when using `docker-compose run`.
When running docker-compose in detached mode, little is displayed to the console, and the only logs displayed under docker-compose logs appear to be:
Attaching to
which obviously isn't very useful.
Is there a way of accessing these logs for transient containers?
I've seen that it's possible to change the docker-daemons logging to use a file (without the ability to select the log location). Following this as a solution I could log to the predefined log location, then execute a copy script to move the files to a mounted volume to be persisted before the container is torn down. This doesn't sound ideal.
The solution I've currently gone with (also not ideal) is to wrap the shell script parameter in a dynamically created proxy script which logs all output to the mounted volume.
tempFile=myproxy.sh
echo '#!/bin/bash' > $tempFile
echo 'do.the.thing.sh 2> /data/log.txt'>>$tempFile
echo 'echo finished >> /data/logs/log.txt' >> $tempFile
Which then I'd call
docker-compose run -d doTheThing $tempFile
instead of
docker-compose run -d doTheThing do.the.thing.sh
docker-compose logs doTheThing
Did anyone succeed in setting up automated UIAutomation tests in Xcode?
I'm trying to set up a target in my Xcode project that should run all the UIAutomation scripts I prepared. Currently, the only Build Phase of this target is this Run Script block:
TEMPLATE="/Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/PlugIns/AutomationInstrument.bundle/Contents/Resources/Automation.tracetemplate"
MY_APP="/Users/Me/Library/Application Support/iPhone Simulator/6.0/Applications/564ED15A-A435-422B-82C4-5AE7DBBC27DD/MyApp.app"
RESULTS="/Users/Me/Projects/MyApp/Tests/UI/Traces/Automation.trace"
SCRIPT="/Users/Me/Projects/MyApp/Tests/UI/SomeTest.js"
instruments -t $TEMPLATE $MY_APP -e UIASCRIPT $SCRIPT -e UIARESULTSPATH $RESULTS
When I build this target it succeeds after a few seconds, but the script didn't actually run. In the build log I get these errors:
instruments[7222:707] Failed to load Mobile Device Locator plugin
instruments[7222:707] Failed to load Simulator Local Device Locator plugin
instruments[7222:707] Automation Instrument ran into an exception while trying to run the script. UIATargetHasGoneAWOLException
+0000 Fail: An error occurred while trying to run the script.
Instruments Trace Complete (Duration : 1.077379s; Output : /Users/Me/Projects/MyApp/Tests/UI/Traces/Automation.trace)
I am pretty sure, that my javascript and my run script are both correct, because if I run the exact same instruments command in bash it works as expected.
Could this be a bug in Xcode?
I finally found a solution for this problem. It seems like Xcode is running the Run Scripts with limited rights. I'm not entirely sure, what causes the instruments command to fail, but using su to change to your user will fix it.
su $USER -l -c <instruments command>
Obviously, this will ask you for your password, but you can't enter it when running as a script. I didn't find a way to specify the password for su, however if you run it as root, you don't have to specify one. Luckily sudo can accept a password via the pipe:
echo <password> | sudo -S su $USER -l -c <instruments command>
If you don't want to hardcode your password (always a bad idea), you could use some AppleScript to ask for the password.
I posted the resulting script below. Copy that to a *.sh file in your project and run that script from a Run Script.
#!/bin/bash
# This script should run all (currently only one) tests, independently from
# where it is called from (terminal, or Xcode Run Script).
# REQUIREMENTS: This script has to be located in the same folder as all the
# UIAutomation tests. Additionally, a *.tracetemplate file has to be present
# in the same folder. This can be created with Instruments (Save as template...)
# The following variables have to be configured:
EXECUTABLE="TestApp.app"
# Optional. If not set, you will be prompted for the password.
#PASSWORD="password"
# Find the test folder (this script has to be located in the same folder).
ROOT="$( cd -P "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
# Prepare all the required args for instruments.
TEMPLATE=`find $ROOT -name '*.tracetemplate'`
EXECUTABLE=`find ~/Library/Application\ Support/iPhone\ Simulator | grep "${EXECUTABLE}$"`
SCRIPTS=`find $ROOT -name '*.js'`
# Prepare traces folder
TRACES="${ROOT}/Traces/`date +%Y-%m-%d_%H-%M-%S`"
mkdir -p "$TRACES"
# Get the name of the user we should use to run Instruments.
# Currently this is done, by getting the owner of the folder containing this script.
USERNAME=`ls -l "${ROOT}/.." | grep \`basename "$ROOT"\` | awk '{print $3}'`
# Bring simulator window to front. Depending on the localization, the name is different.
osascript -e 'try
tell application "iOS Simulator" to activate
on error
tell application "iOS-Simulator" to activate
end try'
# Prepare an Apple Script that promts for the password.
PASS_SCRIPT="tell application \"System Events\"
activate
display dialog \"Password for user $USER:\" default answer \"\" with hidden answer
text returned of the result
end tell"
# If the password is not set directly in this script, show the password prompt window.
if [ -z "$PASSWORD" ]; then
PASSWORD=`osascript -e "$PASS_SCRIPT"`
fi
# Run all the tests.
for SCRIPT in $SCRIPTS; do
echo -e "\nRunning test script $SCRIPT"
COMMAND="instruments -t \"$TEMPLATE\" \"$EXECUTABLE\" -e UIASCRIPT \"$SCRIPT\""
COMMAND="echo '$PASSWORD' | sudo -S su $USER -l -c '$COMMAND'"
echo "$COMMAND"
eval $COMMAND > results.log
SCRIPTNAME=`basename "$SCRIPT"`
TRACENAME=`echo "$SCRIPTNAME" | sed 's_\.js$_.trace_g'`
mv *.trace "${TRACES}/${TRACENAME}"
if [ `grep " Fail: " results.log | wc -l` -gt 0 ]; then
echo "Test ${SCRIPTNAME} failed. See trace for details."
open "${TRACES}/${TRACENAME}"
exit 1
break
fi
done
rm results.log
It seems as though this really might be an Xcode problem; at any rate, at least one person has filed a Radar report on it. Someone in this other thread claims you can work around this exception by disconnecting any iDevices that are currently connected to the computer, but I suspect that does not apply when you're trying to run the script as an Xcode target.
I would suggest filing a Radar report as well; you may get further details on the issue from Apple, or at least convince them that many people are having the problem and they ought to figure out what's going on.
Sorry for a not-terribly-helpful answer (should have been a comment, but comments and links/formatting do not mix very well). Please update this question with anything you find out on the issue.
Note: this is not a direct answer to the question, but it is an alternative solution to the underlying problem.
While searching for in-depth information about UIAutomation, I stumbled across a framework by Square called KIF (Keep it functional). It is a integration testing framework that allows for many of the same features as UIAutomation, but the great thing about is is that you can just write your integration tests in Objective-C.
It is very easy to setup (via CocoaPods), they have good examples too, and the best thing is that it's a breeze to set up with your CI system like Jenkins.
Have a look at: http://github.com/square/KIF
Late to the game but I have a solution that works for Xcode 5.1. Don't know if that's what broke the above solution or not. With the old solution I was still getting:
Failed to load Mobile Device Locator plugin, etc.
However, this works for the release version of Xcode 5.1.
echo <password> | sudo -S -u username xcrun instruments
Notice I removed the unneeded su command and added the xcrun command. The xcrun was the magic that was needed.
Here is my complete command:
echo <password> | sudo -S -u username xcrun instruments\
-w "iPhone Retina (3.5-inch) - Simulator - iOS 7.1"\
-D "${PROJECT_DIR}/TestResults/Traces/Traces.trace"\
-t "${DEVELOPER_DIR}/Instruments.app/Contents/PlugIns/AutomationInstrument.bundle/Contents/Resources/Automation.tracetemplate"\
"${BUILT_PRODUCTS_DIR}/MyApp.app"\
-e UIARESULTSPATH "${PROJECT_DIR}/TestResults"\
-e UIASCRIPT "${PROJECT_DIR}/UITests/main.js"
By the way if you type:
instruments -s devices
you will get a list of all the supported devices you can use for the -w option.
Edit: To make this work for different people checking out the project replace the following:
echo <password> | sudo -S -u username xcrun instruments
with
sudo -u ${USER} xcrun instruments
Since you are just doing an sudo to the same user no password is required.
Take a look at this tutorial that explains how to have Automated UI testing with Jenkins. It also uses Jasmine in the tutorial though. http://shaune.com.au/automated-ui-testing-for-ios-apps-uiautomation-jasmine-jenkins/ hope this helps. It has an example project file so you can download that as a template. Hope this helps.
In XCode - if you load up organizer (XCode->Window->Organizer)
Then select your machine under devices -> 'Enable Developer Mode'
This should remove the need for prompts with instruments.
On Mac OS X, if I send SIGQUIT to my C program, it terminates, but there is no core dump file.
Do you have to manually enable core dumps on Mac OS X (how?), or are they written to somewhere else instead of the working directory?
It seems they are suppressed by default. Running
$ ulimit -c unlimited
Will enable core dumps for the current terminal, and it will be placed in /cores as core.PID. When you open a new session, it will be set to the default value again.
On macOS, your crash dumps are automatically handled by Crash Reporter.
You can find backtrace files by executing Console and going to User Diagnostic Reports section (under 'Diagnostic and Usage Information' group) or you can locate them in ~/Library/Logs/DiagnosticReports.
You can also check where dumps are generated by monitoring system.log file, e.g.
tail -f /var/log/system.log | grep crash
The actual core dump files you can find in /cores.
See also:
How to generate core dumps in Mac OS X?
Technical Note TN2118: Kernel Core Dumps.
Additionally, the /cores directory must exist and the user running the program must have write permissions on it.
The answer above,
ulimit -c unlimited
works -- but be sure to run that in the same terminal from which you will run the program that dumps core. You need to run the ulimit command first.
by default, specific directories in mac osx are hidden. you might want to enable this feature in the terminal and then the core dump should be visible within the directory /cores.
defaults write com.apple.finder AppleShowAllFiles TRUE
There is a great explanation by Quinn “The Eskimo!” on Apple's forums
https://developer.apple.com/forums/thread/694233
I roughly followed that guide. Here are the steps that I did.
Grant write all access to the /cores dir
PROMPT> ls -la / | grep cores
drwxr-xr-x 2 root wheel 64 Dec 8 2021 cores
PROMPT> sudo chmod 1777 /cores
PROMPT> ls -la / | grep cores
drwxrwxrwt 2 root wheel 64 Dec 21 23:29 cores
Set size of core file
PROMPT> ulimit -c unlimited
Compile and sign the program
PROMPT> cargo build --release -p my-crashing-program
PROMPT> /usr/libexec/PlistBuddy -c "Add :com.apple.security.get-task-allow bool true" tmp.entitlements
PROMPT> codesign -s - -f --entitlements tmp.entitlements my-crashing-program
Run the program
PROMPT> my-crashing-program
thread 'main' panicked at 'boom', my-crashing-program/src/main.rs:74:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
dumping core for pid 80995
zsh: quit my-crashing-program
Now there is a core file
PROMPT> ls /cores
core.80995
Also Apple's Console app has a list with Crash Reports.