- launchd-dev - lists.macosforge.org

Re: [launchd-dev] Starting Agents in specific GUI sessions
by NuSkooler 19 Aug '13

19 Aug '13

Thanks again for your replies -- Maybe I didn't describe this well enough: - The daemon is non-graphical of course and runs with or without a login session as root. - I *do* have GUI applications (the "agents") that are to show UI. As mentioned, the "backup plan" is to use the plist system where they are registered to load at login (/Library/LaunchAgents/*.plist). This works for *most* of the cases. I know how to manually launch an application that's either registered or not *in the current session* via launchctl. The issue is launching one "in to" another specific session. > > Please don't have your daemon launch an app; that's an exercise fraught > with compatibility liability. Can you elaborate here more? I know they are different worlds, but we do this on Windows without any issue. I already know and track sessions, know when a user logs in or out, etc. > The most straightforward solution to this problem is to install a tiny GUI > launchd agent [1]. It can then communicate with the daemon, allowing the > daemon to know about all the login sessions and send messages to the agent > in one specific session or all sessions. If the agent needs to display > GUI, it can either do so directly or launch an app to do so. It's safe for > a GUI launchd agent to launch an app because it is, by definition, running > in a GUI login context. > Again this is what I'm calling my "back up plan". It does work most of the time, but there are edge cases in which it would be extremely desirable to programmatically (from the daemon) launch said GUI agents into a users session. In the end, I think I can make this work with the /Library/LaunchAgents plists perhaps with some KeepAlive logic, but it will require quite a few works arounds in our code base, and it seems odd that there are no clean APIs to programmatically target a session and launch a GUI agent in it from a privileged (e.g. root) service/daemon. Bryan

5 4

Starting Agents in specific GUI sessions
by NuSkooler 16 Aug '13

16 Aug '13

I am working on a large project that includes a kernel module (that talks with the daemon), a centralized daemon (that runs as root/privileged) and agents that interact with a user logged into a graphical session. In the Windows world, when the daemon needs to show UI it simply creates a new instance of a agent in the targeted session using CreateProcessAsUser() and friends. On OS X however, this type of functionality does not seem to be present. I've found discussions around the "bsexec" option of launchctl but this appears to no longer function in 10.7+. Are there new APIs/ways of doing this? I know the session ID (derived from audit session information/etc.) but do not see away to connect the dots. I know about registering plist's in /Library/LaunchAgents in order to have the agents start at login, but there are still times in which I need to start/stop new instances of agents "on the fly" from the daemon space. Thanks, Bryan Ashby

2 1

LaunchAgent suddenly appears in Dock bouncing when CGImageSourceCopyPropertiesAtIndex is called
by Kevin Meaney 13 Aug '13

13 Aug '13

Hi all, I've got a launch agent working and communicating with it using a terminal command nicely. I'm using NSXPCConnection classes. If I call CGImageSourceCopyPropertiesAtIndex within the launchagent then the launchagent appears in the dock bouncing. Calling CGImageSourceCopyProperties doesn't cause the same issue. I have tried adding to the LaunchAgent's bundle plist the key LSUIElement with a value of YES. This doesn't change the behaviour. The LaunchAgent continues to work properly and the dictionary obtained from calling CGImageSourceCopyPropertiesAtIndex is saved to disk which is what I wanted to happen. I'm linking against frameworks Foundation and ImageIO. Any thoughts as to why? Kevin

3 6

Mac OS Forge and launchd (was: Launchd "System" session type)
by Axel Luttgens 23 Jul '13

23 Jul '13

Le 23 juil. 2013 à 10:56, Quinn The Eskimo! a écrit : > > On 21 Jul 2013, at 02:37, Michael wrote: > >> Perhaps a better question: Where are these documented, > > [...] Hello Quinn, Thanks for having thought to share your reply to Michael with the rest of us. >> (and, I just realized, this list is launchd-dev; is there a launchd-users list?) > > No, but this is a perfectly reasonable place to just such things IMO. > [...] Which made me remind of a question I wanted to ask since several months now. What happened to the Launchd project on Mac OS Forge? Is there another place to look at (beside the source code, I mean)? TIA, Axel

3 3

Re: [launchd-dev] Launchd "System" session type
by Quinn "The Eskimo!" 23 Jul '13

23 Jul '13

On 21 Jul 2013, at 02:37, Michael <keybounce(a)gmail.com> wrote: > Perhaps a better question: Where are these documented, Some of this stuff is documented in the "Daemons and Services Programming Guide". <https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BP…> But probably the best reference is Technote 2083 "Daemons and Agents". <https://developer.apple.com/library/mac/#technotes/tn2083/_index.html> > why does the man page for "launchctl" list them but not define them, nor reference the file/tech document where they are defined? You should feel free to file a bug against the man page requesting that. <http://developer.apple.com/bugreporter/> > But actually understanding -- and being able to predict -- what is actually happening/what will happen (including why I see launchd running jobs for people not logged on, usually mdworker), that's still beyond me. In the general case, launchd is a highly dynamic system, which makes predicting its behaviour somewhat tricky. For example, consider gssd. It's on-demand trigger is: <dict> <key>com.apple.gssd</key> <dict> <key>HostSpecialPort</key> <integer>19</integer> </dict> </dict> which means it launches when other code either a) messages a Mach port registered as "com.apple.gssd" in the Mach bootstrap namespace, or b) messages the HOST_GSSD_PORT Mach special port. Both of these can be done by any process on the system, and the latter can be done by kernel code as well (such as the SMB VFS plug-in). From a launchd perspective it's hard to predict--and, in the bigger picture, it just doesn't matter--when other components of the system will do this. In the specific case of mdworker, all the mdworker jobs are carefully managed by the Spotlight infrastructure, and the details of that management are not clearly visible to you (note that all the mdworker jobs have a single "MachService" on-demand trigger, which isn't very enlightening). Spotlight starts an particular flavour of mdworker when it has work for that flavour to do; launchd is involved in the mechanics of starting and tracking the job, but not the decision about which job to start when. > (and, I just realized, this list is launchd-dev; is there a launchd-users list?) No, but this is a perfectly reasonable place to just such things IMO. Share and Enjoy -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware

1 0

Launchd "System" session type
by Jeremy Reichman 19 Jul '13

19 Jul '13

The launchd man page for OS X 10.8 describes five session contexts: Aqua, LoginWindow, Background, StandardIO and System. The "System" context appears to be new since OS X 10.7. It is not described in TechNote 2038 and I could not find more about it in any of the launchd man pages. If it were to be described in that TechNote's "Table 1: Types of launchd agent," how might the "System" session type be explained? -- Jeremy

2 1

Hanging system calls with non-system users
by Axel Luttgens 14 Mar '13

14 Mar '13

Hello, I'm encountering a problem that seems to be launchd-related, hence my post here. Beside Dovecot's case, I tend to believe this could be of interest for everyone devising daemons. Dovecot may be configured with pure "virtual" users, i.e. users with an uid/gid pair unknown in the system; this allows to fetch those users from, say, a database while providing increased security (virtual user A should not be able to access the mailbox of virtual user B). On Mac OS X (10.8.2 here), with Dovecot 2.1.14, this works up to a certain point; for example, connecting as "user1" (100016/100016) for the first time, one gets this in the logs: dovecot[97622] <Info>: master: Dovecot v2.1.14 starting up (core dumps disabled) dovecot[97624] <Info>: pop3-login: Login: user=<user1>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=97632, secured, session=<rziWFXnW0gB/AAAB> dovecot[97624] <Debug>: pop3(user1): Debug: Effective uid=100016, gid=100016, home=/_Data/Mailstores/100016 dovecot[97624] <Debug>: pop3(user1): Debug: Home dir not found: /_Data/Mailstores/100016 dovecot[97624] <Debug>: pop3(user1): Debug: fs: root=/_Data/Mailstores/100016/mboxes, index=, control=, inbox=/_Data/Mailstores/100016/mboxes/inbox, alt= dovecot[97624] <Debug>: pop3(user1): Debug: Namespace : /_Data/Mailstores/100016/mboxes doesn't exist yet, using default permissions dovecot[97624] <Debug>: pop3(user1): Debug: Namespace : Using permissions from /_Data/Mailstores/100016/mboxes: mode=0700 gid=-1 dovecot[97624] <Debug>: pop3(user1): Debug: Namespace : /_Data/Mailstores/100016/mboxes/inbox doesn't exist yet, using default permissions dovecot[97624] <Debug>: pop3(user1): Debug: Namespace : Using permissions from /_Data/Mailstores/100016/mboxes: mode=0700 gid=-1 dovecot[97624] <Debug>: pop3(user1): Debug: Namespace : /_Data/Mailstores/100016/mboxes/inbox doesn't exist yet, using default permissions dovecot[97624] <Debug>: pop3(user1): Debug: Namespace : Using permissions from /_Data/Mailstores/100016/mboxes: mode=0700 gid=-1 dovecot[97624] <Debug>: pop3(user1): Debug: In my_hostdomain: 100016 100016 100016 100016 com.apple.launchd[1] (com.apple.launchd.peruser.100016[97633]) <Error>: getpwuid("100016") failed com.apple.launchd[1] (com.apple.launchd.peruser.100016[97633]) <Notice>: Job failed to exec(3). Setting up event to tell us when to try again: 3: No such process com.apple.launchd[1] (com.apple.launchd.peruser.100016[97633]) <Notice>: Job failed to exec(3) for weird reason: 3 and the pop3 process then hangs forever; but many things have nevertheless been done for user1, especially the creation of needed files/directories. Subsequent connections as "user1" (after having restarted Dovecot and sent KILL to the pop3 process) systematically end with hanging pop3 processes, but without those com.apple.launchd.peruser messages in the logs anymore. Debugging has been quite a challenge (at least, with my poor skills), since all of this becomes quite elusive with the silent interposition of launchd; but it is now almost certain that the hangs occur on a call to gethostbyname() from the code of the pop3 executable. I suspect this to be more general and to be liable to occur with other system calls as well (probably those from LibInfo). So, I've devised the pieces of code at the end of this message so as to provide a skeleton of how Dovecot's master process spawns its children, for example a child pop daemon upon a client connection on port 110. They really are a skeleton, as Dovecot performs much more initializations (pre-exec() and post-exec() setups in the comments below). Yet, they may be viewed as a proof of concept: a child process running as a virtual user may invoke a system call such as gethostbyname() without encountering any problem; in the logs: pseudomaster[11946] <Notice>: Master: started. pseudomaster[11947] <Notice>: Child: forked. Unknown[11947] <Notice>: Pseudochild: started. Unknown[11947] <Notice>: Pseudochild: gethostbyname() returned almba.local pseudomaster[11946] <Notice>: Master: child done. pseudomaster[11946] <Notice>: Master: looping. pseudomaster[11949] <Notice>: Child: forked. Unknown[11949] <Notice>: Pseudochild: started. Unknown[11949] <Notice>: Pseudochild: gethostbyname() returned almba.local pseudomaster[11946] <Notice>: Master: child done. pseudomaster[11946] <Notice>: Master: looping. [...] So, the question is to know what Dovecot may do so as to trigger hangs of gethostbyname(). Note that the problem disappear with Dovecot as soon as one makes use of a "real" gid, such as the one of group "staff": a "semi-virtual" user with 100016/20 may connect without any problem; this may perhaps provide a clue about the kind of settings Dovecot makes use of. Conversely, what kind of additional settings should I consider in my skeleton so as to trigger similar hangs in the child process? But more generally, what exactly is the rationale for having launchd entering the game? Many thanks in advance, Axel pseudomaster.c ============== #include <syslog.h> #include <unistd.h> #include <stdlib.h> int main( int argc, const char * argv[]) { pid_t pid; int retstatus; char * dummyargs[] = { NULL }; syslog(LOG_NOTICE|LOG_MAIL, "Master: started."); for (;;) { pid = fork(); if (pid < 0) { syslog(LOG_NOTICE|LOG_MAIL, "Master: fork() failed."); } else if (pid == 0) { syslog(LOG_NOTICE|LOG_MAIL, "Child: forked."); // Pre-exec() setups, e.g. wrt file descriptors. if (execv("/_COD/pseudochild", dummyargs) < 0) { syslog(LOG_NOTICE|LOG_MAIL, "Child: execv() failed."); _exit(1); } } waitpid(-1, & retstatus, 0); syslog(LOG_NOTICE|LOG_MAIL, "Master: child done."); sleep(5); syslog(LOG_NOTICE|LOG_MAIL, "Master: looping."); } } pseudochild.c ============= #include <syslog.h> #include <netdb.h> #include <unistd.h> #include <stdlib.h> int main( int argc, const char * argv[]) { struct hostent *hent; gid_t gidset[1]; uid_t uid = 100016; gid_t gid = 100016; gidset[0] = gid; syslog(LOG_NOTICE|LOG_MAIL, "Pseudochild: started."); if (setgid(gid) != 0) { syslog(LOG_NOTICE|LOG_MAIL, "Pseudochild: setgid() failed."); _exit(1); } if (setgroups(1, gidset) != 0) { syslog(LOG_NOTICE|LOG_MAIL, "Pseudochild: setgroups() failed."); _exit(1); } if (setuid(uid) != 0) { syslog(LOG_NOTICE|LOG_MAIL, "Pseudochild: setuid() failed."); _exit(1); } // Other post-exec() setups hent = gethostbyname("ALMba.local"); if ( hent != NULL ) { syslog(LOG_NOTICE|LOG_MAIL, "Pseudochild: gethostbyname() returned %s\n", hent->h_name); return(0); } else { syslog(LOG_NOTICE|LOG_MAIL, "Pseudochild: gethostbyname() failed."); return(1); } } pseudomaster.plist ================== <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>ServiceDescription</key> <string>Master test</string> <key>Label</key> <string>pseudomaster</string> <key>Disabled</key> <true/> <key>KeepAlive</key> <true/> <key>ProgramArguments</key> <array> <string>/_COD/pseudomaster</string> </array> </dict> </plist>

1 2

Talk to correct launchd
by Rolf Howarth 04 Feb '13

04 Feb '13

Hi, I have a launch daemon in /Library/LaunchDaemons and want to let users manually start and stop the service from my application's user interface, which involves them authenticating of course. I am therefore running launchctl with an effective uid of 0 but their own real user id. I believe launchctl uses the EUID to decide which launchd to talk to, and so it's talking to the wrong (per user, not system) launchd. Is there any way to get launchd to use the EUID instead of RUID and force it to talk to the system-wide root launchd instead? -Rolf

2 1

Compiling launchd
by louis.granboulan＠free.fr 22 Jan '13

22 Jan '13

Dear all, I tried to compile launchd, and I failed. I downloaded the tarball and ran Xcode on launchd.xcodeproj It needs private headers from CoreFoundation or DiskArbitration, which I can download. But I don't know how to find many .defs files that are also needed. For example, Xcode is looking for a /usr/local/include/xpc/domain.defs and there is apparently no such file on http://www.opensource.apple.com What should I do? Thanks, Louis

1 0

Launchd
by Cameron Mc Gorian 12 Dec '12

12 Dec '12

Hey, I have a server app that I need to to start when the computer runs. To start it in terminal I would type sudo ~/.bridge/server start I had a look at the docs re Daemons and Agents and wrote a .plist of my own to start the process but it does not seem to be working. This is the .plist <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd>"> <plist version="1.0"> <dict> <key>Label</key> <string>com.getbridge.bridge_server</string> <key>ProgramArguments</key> <array> <string>/Users/MacbookPro/.bridge/server</string> <string>start</string> </array> <key>KeepAlive</key> <true/> <key>RunAtLoad</key> <true/> </dict> </plist> Am I doing something wrong and if I need to ask this question somewhere else then please let me know. Thanks in advance. Best Regards, Cameron Mc Gorian

2 4