Is there a means to attach to and debug launchd? Or to attach to a per user launchd process? I get the following when logged in as root and trying to attach to launchd: (gdb) attach launchd.1 Attaching to program: `/sbin/launchd', process 1. Unable to attach to process-id 1: Operation not permitted (1). This request requires that the target process be neither setuid nor setgid and have the same real userid as the debugger, or that the debugger be running with administrator privileges. I'm trying to determine why the call to getpwuid() in job_postfork_become_user() is failing. Here's a snippet from system.log: Nov 15 14:39:35 dc3 com.apple.launchd[1] (com.apple.launchd.peruser.166128603[1036]): getpwuid("166128603") failed Nov 15 14:39:35 dc3 com.apple.launchd[1] (com.apple.launchd.peruser.166128603[1036]): PID 1002 "authorizationhos" has no account to back it! Real/effective/saved UIDs : 0/166128603/0 Nov 15 14:39:35 dc3 com.apple.launchd[1] (com.apple.launchd.peruser.166128603[1036]): PID 112 "authorizationhos" has no account to back it! Real/effective/saved UIDs: 0/166128603/0 Nov 15 14:39:35 dc3 com.apple.launchd[1] (com.apple.launchd.peruser.166128603[1036]): Exited with exit code: 1 Nov 15 14:39:35 dc3 com.apple.launchd[1] (com.apple.launchd.peruser.166128603): Throttling respawn: Will start in 10 seconds Cheers, Matt
Traditionally, the kernel doesn't allow debuggers to attach to PID 1. As the author of launchd, I haven't felt strong enough to get the kernel team to change that policy. I've learned to live with logging. You can enable logging by adding "log level debug" to /etc/ launchd.conf and adjusting /etc/syslog.conf to capture the generated messages. Having said all that, based on the messages below, I'd be curious to figure how why those processes are running around with UID 166128603. Was that ever a valid UID on your system? For whatever it may be worth, getpwuid() is a shim around DirectoryService APIs and the DirectoryService daemon. I'd try to get in contact with them. davez On Nov 15, 2007, at 12:39 PM, Matt DeFoor wrote:
Is there a means to attach to and debug launchd? Or to attach to a per user launchd process? I get the following when logged in as root and trying to attach to launchd:
(gdb) attach launchd.1 Attaching to program: `/sbin/launchd', process 1. Unable to attach to process-id 1: Operation not permitted (1). This request requires that the target process be neither setuid nor setgid and have the same real userid as the debugger, or that the debugger be running with administrator privileges.
I'm trying to determine why the call to getpwuid() in job_postfork_become_user() is failing. Here's a snippet from system.log:
Nov 15 14:39:35 dc3 com.apple.launchd[1] (com.apple.launchd.peruser.166128603[1036]): getpwuid("166128603") failed Nov 15 14:39:35 dc3 com.apple.launchd[1] (com.apple.launchd.peruser.166128603[1036]): PID 1002 "authorizationhos" has no account to back it! Real/effective/saved UIDs : 0/166128603/0 Nov 15 14:39:35 dc3 com.apple.launchd[1] (com.apple.launchd.peruser.166128603[1036]): PID 112 "authorizationhos" has no account to back it! Real/effective/saved UIDs: 0/166128603/0 Nov 15 14:39:35 dc3 com.apple.launchd[1] (com.apple.launchd.peruser.166128603[1036]): Exited with exit code: 1 Nov 15 14:39:35 dc3 com.apple.launchd[1] (com.apple.launchd.peruser.166128603): Throttling respawn: Will start in 10 seconds
Cheers, Matt _______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/launchd-dev
On Nov 15, 2007 5:28 PM, Dave Zarzycki <zarzycki@apple.com> wrote:
Traditionally, the kernel doesn't allow debuggers to attach to PID 1. As the author of launchd, I haven't felt strong enough to get the kernel team to change that policy. I've learned to live with logging. You can enable logging by adding "log level debug" to /etc/ launchd.conf and adjusting /etc/syslog.conf to capture the generated messages.
Thanks, will do.
Having said all that, based on the messages below, I'd be curious to figure how why those processes are running around with UID 166128603. Was that ever a valid UID on your system? For whatever it may be worth, getpwuid() is a shim around DirectoryService APIs and the DirectoryService daemon. I'd try to get in contact with them.
I should have explained the unusually high UID in my first message. The UID is generated by my Open Directory plugin. There's an algorithm that generates them for users authenticated via the plugin. High UIDs like that are also somewhat common in the AD plugin from what I understand. Anyway, these high UIDs haven't been a problem pre-Leopard GM. So, I'm a little suspicious about them. However, if I assign the user a low UID (something like 600) I can still reproduce the error. So, I've been spending quality time in the debugger trying to figure out if there's something in my plugin that would be causing getpwuid() to fail when/if it makes calls via DirectoryService. But, to this point, I haven't seen anything unusual. Like I said, the code was working fine from Panther to pre-Leopard GM. Cheers, Matt
participants (2)
-
Dave Zarzycki
-
Matt DeFoor