QRecall Community Forum
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Top Downloads] Top Downloads   [Groups] Back to home page 
[Register] Register /  [Login] Login 

Error due to UID change RSS feed
Forum Index » Problems and Bugs
Author Message
Bruce Giles


Joined: Dec 5, 2007
Messages: 95
Offline
I ran into an interesting QRecall problem today.

Background: A couple of weeks ago, I replaced the stock hard drive in my Mac Book Pro with an SSD hard drive. I was prepared to use QRecall to transfer all my files from the hard drive to the SSD drive, but I tried Migration Assistant first, and that worked just fine. And QRecall seemed to be working just fine on the new drive as well. I do notice that it seems to be significantly faster now, even though the backup drive is still a non-SSD hard drive.

So, I thought everything was good until this morning, when I happened to open Console. I found hundreds (thousands?) of entries like this:

Feb 3 12:05:25 BruceMacBookPro com.apple.launchd[1] (com.apple.launchd.peruser.501[223]): getpwuid("501") failed
Feb 3 12:05:35 BruceMacBookPro com.apple.launchd[1] (com.apple.launchd.peruser.501[224]): getpwuid("501") failed
Feb 3 12:05:45 BruceMacBookPro com.apple.launchd[1] (com.apple.launchd.peruser.501[227]): getpwuid("501") failed

As you can see, the same entry was repeating every 10 seconds.

After spending a little time with Google, and the command line interface in Terminal, I figured out the problem. On the old hard drive, my UserID was 501. On the new SSD drive, after Migration Assistant transferred everything over, my new UserID was 504. There is no UID 501 on the SSD drive.

The problem was in /Library/LaunchDaemons/com.qrecall.scheduler.kickstart.plist. I examined the file in BBEdit, and found some lines like this:

<key>Program</key>
<string>/Library/Application Support/QRecall/QRecallKickStart</string>
<key>ProgramArguments</key>
<array>
<string>501</string>
<string>504</string>
</array>

I deleted the "<string>501</string>" line, and saved the changes (making sure the owner was still root/wheel). I rebooted, and the problem had disappeared.

So, if I'm interpreting this correctly, the launch daemon was attempting to QRecallKickStart as both UID 501 and 504. Since UID 504 existed, QRecall was working correctly, but since UID 501 no longer existed, it was also generating tons of error messages.

I don't know how the 504 UID got added to the plist file, but assuming QRecall did it, then it seems like it also needs to look at any other UIDs in the file and delete any that are no longer valid.

-- Bruce


James Bucanek


Joined: Feb 14, 2007
Messages: 1572
Offline
Bruce Giles wrote:I don't know how the 504 UID got added to the plist file

The UID was added to the kicker list as soon as you launched QRecall. It checked its configuration, saw that it was not on the list of UIDs to have its scheduler run as a system daemon, and added itself to the list.

... but assuming QRecall did it, then it seems like it also needs to look at any other UIDs in the file and delete any that are no longer valid.

Excellent suggestion.

Done.

When adding a new UID to the kicker list, all existing UIDs will be qualified. Any that don't appear to belong to valid user accounts are now deleted.

Similarly, the kicker process itself will check the UID before trying to launch the scheduler daemon for that user and exit cleanly if the user doesn't appear to exist. This should keep launchd from repeatedly relaunching the kicker for invalid users.

- QRecall Development -
[Email]
Bruce Giles


Joined: Dec 5, 2007
Messages: 95
Offline
Sounds like the perfect solution. Thanks!
 
Forum Index » Problems and Bugs
Go to:   
Mobile view
Powered by JForum 2.8.2 © 2022 JForum Team • Maintained by Andowson Chang and Ulf Dittmer