While developing a Cocoa application on 10.9, I have noticed that if I go to ~/Library/Preferences and delete the plist file for my app (to reset it), on the next build-and-run, the app behaves as if the plist file had never been deleted at all.
It took me a long time to track down why this happens and I did not see a question/answer about it on SO, so I'm writing this question and answering it myself to help others.
On 10.9, the system is doing some more robust "caching" of preferences. After deleting the plist file, I fired up Activity Monitor and force-killed the "cfprefsd" process. Be careful: there are multiple processes with this name running and you only want to kill the one running under your own user; do not kill the one running as root.
Doing this seems to flush the preferences cache and on the next run of my app, I get a pristine start-from-scratch launch.
Edit: As reported below, using defaults delete [your bundle identifier] at the command line also appears to eliminate the caching issue. I've had mixed success with this.
I found out that killing the user process cfprefsd will reflush the cache, so your changes will be kept
killall -u $USER cfprefsd
In terminal:
defaults delete com.somecompany.someapp
BTW, I've just released a GUI app that may be more convenient than working with the defaults command:
http://www.tempel.org/PrefsEditor
It works practically the same as Xcode's plist editor, but affects the user's app preferences directly.
To delete all your prefs, you could open your prefs in my Prefs Editor, Select All, then delete them with the Backspace or Delete key, and they're instantly all gone.
However, for this particular task, using defaults delete might still be quicker, especially if you put the command into a text file ending in ".command", and make it executable (with chmod +x). Then you can double click it from the Finder to execute it.
Related
I have designed a GUI that I want to run as soon as I turn on my Raspberry Pi. It is currently set up to automatically log in as user on startup, but if that makes the process more difficult I can change that. My Raspi runs on Raspbian 10 (buster), which has made things difficult since I can only find tutorials for Raspbian 8 or so.
I have tried modifying autostart folder, but it is not in the same location as it was in previous Raspbian versions and doesn't seem to be working the way it used to. Tutorials have said to create a .desktop file in /home/pi/.config/autostart but I don't have a .config folder, or at least it's hidden. For me, autostart is in /etc/xdg/autostart and when I try to create a new file here using nano in the terminal, I get the message [Directory '/etc/xdg/autostart' is not writable] and it doesn't save my file.
I have also tried calling my script in /etc/rc.local but it did nothing. Some have said it doesn't work for GUIs.
Here's what I type into terminal:
$ nano /etc/xdg/autostart/gui.desktop
and a new file pops up, but at the bottom I get the warning [Directory '/etc/xdg/autostart' is not writable]
How can I get my GUI script to run on startup with Raspbian 10 (buster)?
There are a number of issues here, first when you are looking at tutorials recognize that Linux distros are built in layers, for simplicity let's say your "layer stack" looks like this: kernel, systemd, x11, xdg, lxde. The kernel boots, then starts systemd, which then starts x11 (and a lot of other stuff), x11 starts xdg (and some other stuff, I think), lxde is started by either x11 or xdg I'm not sure which.
You want to add something to this process, you can do it at the kernel level (bad idea), at they systemd level (probably not right unless its a daemon), at the x11 level (still probably bad as you still don't have a user session yet), or at the xdg or lxde level.
xdg is probably the right place as it has all you need ( a gui, a user session) while being common (xdg will still work if you switch window managers, probably)
With that out of the way, why isn't your solution of modifying xdg working? It's because '/etc/xdg/autostart' is a system configuration directory. Any changes made to it will apply to all users. You may want this, but the system is trying to protect other users on your system and only allows root to make changes to everyone. If you want to do that use "sudo" (documented elsewhere on stack exchange and the internet). If you want to do it just for you use ~/.config/autostart, (https://wiki.archlinux.org/index.php/XDG_Autostart) you might need to create that directory with "mkdir ~/.config/" and then "emacs ~/.config/autostart"
Would it be better to have the python program run in a terminal window from startup? That way you would see what it is doing in case of errors.
If so, perhaps check this out https://stackoverflow.com/a/61730679/7575617
By the way, in the file manager, hit CTRL+H to toggle viewing hidden files and folders.
It seems that I've run out of room on my Master node and I need to clear some space in order to reboot my daily tests. Selenium.log is taking up a lot of space and I'm convinced its not currently being used. Would it be safe to delete?
Edit: I deleted the file and upon starting a new build Selenium created a new log file. I didn't experience any issues during this new build either.
You don't say what creates the file, or where it is, but assuming that you can already see the important details from each build in the Jenkins UI (e.g. in the console log, or in test results etc.), then you shouldn't need to keep any files that are sitting in the workspace or elsewhere.
I'm trying to have my app auto launch on login following Tim's tutorial: http://blog.timschroeder.net/2012/07/03/the-launch-at-login-sandbox-project/
I followed the instructions to the letter but I'm getting an error when I re-login to my computer as follows:
Jan 10 12:55:01 pc61 com.apple.xpc.launchd[1] (com.myApp.macgap.helper[25725]): Could not resolve CFBundleIdentifier specified by service: -10814: com.myApp.macgap.helper
Jan 10 12:55:01 pc61 com.apple.xpc.launchd[1] (com.myApp.macgap.helper): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
To outline:
I have my main app called "myApp" (ID: com.myApp.macgap )
In that app I have a helper app with ID: com.myApp.macgap.helper
When you launch the main app and go to preferences, you have an option to enable auto login (to fit to the Apple compliance rules)
I log out of my computer, log back in and look at the console to see what's going on (that's how I get the code above)
Another point worth mentioning, is when I do "Show package content" on the app and double click the helper app, it does launch the main app...
It all comes down to how launchd and launchctl work, as already answered, the regular use case often can be solved by reinstalling the app and ensuring the app is inside the applications folder. But there's another case that #byb is talking about, when this happens on your development machine – this can be caused by invalid launchd configuration.
When you run SMLoginItemSetEnabled it registers your bundle identifier along with other information in launchd service. At some point later, when your app changes, gets cleaned, or something else happens to it, which gets picked up by launchd, launchd may disable that particular login item. Apparently, sometimes this doesn't go smoothly, and consecutive calls with SMLoginItemSetEnabled will not work as expected or the agent / helper app simply won't launch.
The first thing to try is simply changing the bundle identifier for your launcher. If this solves the issue, try figuring out what's wrong with the original. Run launchctl print-disabled "user/$(id -u)" to display disabled services and login item associations. If the output contains your troubling bundle identifier – you are in luck.
I didn't find a way of removing disabled services by name using launchctl and had to do it by manually editing configuration files. Because they system-owned, you won't be able to simply click and edit, instead launch Xcode as root and remove the necessary references.
sudo /Applications/Xcode.app/Contents/MacOS/Xcode "/private/var/db/com.apple.xpc.launchd/loginitems.$(id -u).plist"
sudo /Applications/Xcode.app/Contents/MacOS/Xcode "/private/var/db/com.apple.xpc.launchd/disabled.$(id -u).plist"
Restart, run launchctl print-disabled "user/$(id -u)" to confirm removed items are no longer in the list. Try SMLoginItemSetEnabled again, hopefully now it will work as expected.
I had the exact same problem just now, and while looking for a solution found this (unanswered) question.
At least in my case, this desired functionality of the worked fine when I copied the app (exported from Xcode as a dev-id signed .app) to a fresh OS X install/account without all my development stuff on it. Of course it must also be in /Applications, as stated in the tutorial referred to in the question.
I am not sure why this feature of the app did not work on my development machine. Perhaps the problem could be due to some form of conflict with all the other near-identical copies of my app I have on disk (I have an archive of different versions of the app, plus the copies Xcode stores itself), all with the same bundle id of course.
Hope this helps in one way or another!
I had the same problem, removing other copies of app except one in /Applications solved the problem for me. To remove .app files generated by Xcode you can run Product->Clean.
I was struggling with this for hours. I had many apps with auto login but a new one just did not want to work.
Strangely this worked on the development machine:
Build App as normal
Move it to Application directory
Clean Xcode (CMD+k)!!
Enable auto login in the app.
Logout Login
I accidentally noticed that the system started the app (it tries in every 10 sec) when I clean Xcode :)
I can't find the duplicate copy but did find you can remove the service:
In a terminal window:
launchctl remove com.annoying.service
As it was already stated if there are more then one copies of service bundle on the machine launchd cannot resolve which one must be started by bundle identifier.
What I would recommend to you is find all copies of your service and then remove not desired ones.
For this you need to run following Swift code (It works even in Swift Playground):
import Cocoa
let bundleId = "com.your.bundleId"
let paths = LSCopyApplicationURLsForBundleIdentifier(bundleId as CFString, nil)
print("Available service instances by bundle id: \(paths)")
In my case it produces:
Available service instances by bundle id:
Optional(Swift.Unmanaged<__ObjC.CFArray>(_value: <__NSArrayI 0x6000002234a0>(
file:///Applications/MyApp.app/Contents/Library/LoginItems/MyService.app/,
file:///Users/igor/Library/Developer/Xcode/Archives/2017-12-27/MyApp%2027-12-2017,%2016.06.xcarchive/Products/Applications/MyService.app/
)
))
So I easely identified copy to be removed:
file:///Users/igor/Library/Developer/Xcode/Archives/2017-12-27/MyApp%2027-12-2017,%2016.06.xcarchive/Products/Applications/MyService.app/
Hope it help.
Assuming that you followed Tim Schroeder's recipe at: http://blog.timschroeder.net/2012/07/03/the-launch-at-login-sandbox-project/ :
What actually ended up working for me, was, in Xcode, to change my main project's build number from 1 to 2. I also tried a build number of 1000 and that worked fine as well.
In Xcode, select your main project target. Then, select the 'General' tab. If you see your Build is set to 1, change it to 2 and then rebuild, redeploy and see if that resolves the issue for you.
This was probably one of the screwiest bugs I have run into, in a while.
Sandboxed app was running fine in 10.8 but in 10.9 it seems that user defaults. plist is not saved at all. The location of plist is:
~/Library/Containers/com.example.myapp/Data/Library/Preferences/com.example.myapp.plist
and if I delete it, it will not be created again. In 10.8 this was working.
Has anyone seen this before or can anyone suggest a solution?
Problem solved with a reboot, well short of.
Preferences are saved correctly and it works fine until I delete again the app container folder. Then a reboot is required again to fix this.
My work-around for this problem is to kill the 'cfprefsd' daemon processes after making a change to the .plist file:
ps auwx | grep cfprefsd | grep -v grep | awk '{print $2}' | xargs sudo kill -2
The daemons will be restarted after the next access of the .plist file and will then have the new value for the key that was changed.
It is unfortunate that this work-around is necessary but at least it works reliably.
I had this very issue last night (I am still developing my app). I fixed it by deleting the app container folder (moving the whole ~/Library/Containers/com.domain.appname to trash in Finder) and re-running the app.
I rebooted first as I saw that there was some sort of LSShared file, related to my app, that wouldn't be emptied from the trash before the reboot.
I can only imagine it's an intermittent bug in Mavericks (GM seed).
EDIT The comment about a bug may not be true; it looks like .plist files are "on their way out" according to this Apple Developer Forum thread. However at the end of the day my app (and the OPs) stopped working, so it isn't working reliably.
I have been unable to overcome this error in Application Loader. I've quit, restarted, tried different computers - it's like the server is hung up on an op that I never initiated and it won't time out. Has anyone seen it before and beaten it?
Basically, you need to clear out the transport tokens. This can happen if you were to close out of Xcode while in the middle of submitting an app to iTunes Connect.
The token files now appear in the
Library/Caches/com.apple.amp.itmstransporter/UploadTokens/ subfolder of the given user's home directory. Which, honestly, is a better place for them anyway.
Delete any .token files in this directory.
--
If you are unable to find the .token files, this is because they are hidden in Finder. To hide/show hidden files in Finder, use the following Terminal command (TRUE = UNHIDE, FALSE = HIDE):
defaults write com.apple.finder AppleShowAllFiles TRUE;killall Finder
You need to clear out the transport tokens.
Open Terminal on your Mac, and paste:
rm /Users/<username>/Library/Caches/com.apple.amp.itmstransporter/UploadTokens/*.token
That should clear the stuck token. After this, try uploading the build again.
It might be because Xcode crashed as you were uploading your app. Either, all you need to do is delete the token files:
Open Terminal on your Mac, and paste:
rm ~/.itmstransporter/UploadTokens/*.token
That should clear it. If it still doesn't work (at this point you should try re-uploading your app), run that command on Terminal again, or manually go to...
/Users/<username>/.itmstransporter/UploadTokens/
...and delete all the .token files.
Hope that helps!
token was in here
/Users/(user_name)/Library/Caches/com.apple.amp.itmstransporter/UploadTokens/
Appreciated #WrightsCS 's answer It helps me to overcome Application Loader issue.
I would like to highlight one more thing here.
I proceed as per #WrightsCS answer and it resolved Application loader error:
Can not proceed with delivery: an existing transporter instance is currently uploading this package
But I found one more issue after removing all tokens from
/Users//.itmstransporter/UploadTokens/
I went to iTunesConnect and clicked on "My Apps", what I saw a message that "Can not connect... please contact Apple".
Here I don't know why it suddenly stops working!
I submitted the same build which was there on iTunesConnect for submission but it has shown as processing.
After submission of that build, iTunesConnect works fine! Also, I am able to see last uploaded build in a list for submission.
In my case (I am using OSX Catalina), I was not able to find the folder:
Library/Caches/com.apple.amp.itmstransporter/UploadTokens/
Under my user home directory (even when showing hidden files and folders)
but it seems my problem was a bit different and I just closed xCode completely (every xCode window opened) and reopened it again then I archived my project and uploaded it without any issues
maybe this could help someone else fix this issue
You need to clear out the upload tokens that are "stuck". To do this, open the tokens file found in /users//.itmstransporter/UploadTokens/. You should see one line of text at the top that refers to your current upload token. Simply delete this line and save the file. You should now be able to submit your app again.
Cheers