inetdCompatibility
Hi, 1. There is this patch on the Apple Support forums. Are exporting those environment variables the right way to pass the remote ip information to the spawned process? http://discussions.apple.com/thread.jspa?messageID=9360848&tstart=0 2. (unrelated to the above patch) Im having trouble with getting the inetdCompatibility feature to work. The popular example /System/Library/LaunchDaemons/ssh.plist Which was followed for nginx pretty much verbatem: http://gist.github.com/534777 Regardless, Launchd isn't starting nginx when a connection is made to http://localhost:8080. The 'http-alt' service is specified in "/etc/services" to point to 8080. So as far as I can see, this should be no different to Launchd than for triggering a start of sshd. The behaviour is confounding as Apple sshd will work just fine. Flicking inetdCompatibility to Wait => true has no effect either. Nothing. dreamcat4 dreamcat4@gmail.com
I seem to be confused about what this feature actually does. SSH works because it has a special inetd compatibility flag that will accept stream based socket connections from stdin (as per telnet). Wheras Nginx is a more streamlined and optimized kind of webserver, which would be too slow for operating in that inetd kind of way. Nginx just wants to be launched and be kept running after the first incoming connection. However once launchd loads a job with its Sockets listeners definition, it will remain bound to that incoming TCP port on behalf of that launchd job and not let it go. Im just wondering if its possible to get around all this with a starter script that can trigger nginx to load (on the first incoming connection). The starter script would also have to immediately unload itself from launchd. So as to get launchd to free up the incoming TCP port(s) for nginx. So the very first http connection might have to be dropped, however thats not really such a big problem. Nginx's launchd plist can be configured to start with KeepAlive => OtherJobEnabled => false. So to say "start up when the triggering job unloads itself". The triggering job would have to stay unloaded for the remainder of the previous OS session. But can a launchd job be configured to load itself again during the next boot? It seems the only way to get the above scenario to work. Short of reopening the launchd source code for new functionality / features. On Wed, Aug 18, 2010 at 2:59 PM, Dreamcat4 <dreamcat4@gmail.com> wrote:
Hi,
1. There is this patch on the Apple Support forums. Are exporting those environment variables the right way to pass the remote ip information to the spawned process?
http://discussions.apple.com/thread.jspa?messageID=9360848&tstart=0
2. (unrelated to the above patch) Im having trouble with getting the inetdCompatibility feature to work.
The popular example /System/Library/LaunchDaemons/ssh.plist
Which was followed for nginx pretty much verbatem:
Regardless, Launchd isn't starting nginx when a connection is made to http://localhost:8080. The 'http-alt' service is specified in "/etc/services" to point to 8080. So as far as I can see, this should be no different to Launchd than for triggering a start of sshd.
The behaviour is confounding as Apple sshd will work just fine. Flicking inetdCompatibility to Wait => true has no effect either. Nothing.
dreamcat4 dreamcat4@gmail.com
On Thu, Aug 19, 2010 at 11:48 AM, Dreamcat4 <dreamcat4@gmail.com> wrote:
I seem to be confused about what this feature actually does. SSH works because it has a special inetd compatibility flag that will accept stream based socket connections from stdin (as per telnet).
Wheras Nginx is a more streamlined and optimized kind of webserver, which would be too slow for operating in that inetd kind of way. Nginx just wants to be launched and be kept running after the first incoming connection.
However once launchd loads a job with its Sockets listeners definition, it will remain bound to that incoming TCP port on behalf of that launchd job and not let it go.
Im just wondering if its possible to get around all this with a starter script that can trigger nginx to load (on the first incoming connection). The starter script would also have to immediately unload itself from launchd. So as to get launchd to free up the incoming TCP port(s) for nginx. So the very first http connection might have to be dropped, however thats not really such a big problem.
Nginx's launchd plist can be configured to start with KeepAlive => OtherJobEnabled => false. So to say "start up when the triggering job unloads itself".
The triggering job would have to stay unloaded for the remainder of the previous OS session. But can a launchd job be configured to load itself again during the next boot?
It seems the only way to get the above scenario to work. Short of reopening the launchd source code for new functionality / features.
Well, that was easy enough http://gist.github.com/537897 When I do this, launchd does unload the starter job as requested. However it also report the following error to console: Aug 19 13:39:44 janitors-Mac-mini com.apple.launchd.peruser.502[852] (unload): Bug: launchd_core_logic.c:8873 (24108):0 Another thing is that when loading a User-Level job (from ~/Library/LaunchAgents), and specifying: <key>SockServiceName</key> <string>http-alt</string> Launchd reports another error: janitors-Mac-mini:~ id$ launchctl load -w ~/Library/LaunchAgents/unload.plist bind(): Permission denied However "http-alt" is actually port 8080, well above 1024. That doesnt seem right b/c the launchd.plist documentation refers to "Daemon/Agent writers" in the Sockets description. So Launch Agents should be supported.
On Wed, Aug 18, 2010 at 2:59 PM, Dreamcat4 <dreamcat4@gmail.com> wrote:
Hi,
1. There is this patch on the Apple Support forums. Are exporting those environment variables the right way to pass the remote ip information to the spawned process?
http://discussions.apple.com/thread.jspa?messageID=9360848&tstart=0
2. (unrelated to the above patch) Im having trouble with getting the inetdCompatibility feature to work.
The popular example /System/Library/LaunchDaemons/ssh.plist
Which was followed for nginx pretty much verbatem:
Regardless, Launchd isn't starting nginx when a connection is made to http://localhost:8080. The 'http-alt' service is specified in "/etc/services" to point to 8080. So as far as I can see, this should be no different to Launchd than for triggering a start of sshd.
The behaviour is confounding as Apple sshd will work just fine. Flicking inetdCompatibility to Wait => true has no effect either. Nothing.
dreamcat4 dreamcat4@gmail.com
On 19 Aug 2010, at 11:48, Dreamcat4 wrote:
Wheras Nginx is a more streamlined and optimized kind of webserver, which would be too slow for operating in that inetd kind of way. Nginx just wants to be launched and be kept running after the first incoming connection.
The correct approach to this problem is to have launchd open the listening sockets on behalf of nginx and then have nginx check in with launchd when it starts up. As part of this checkin process, it can acquire the listening socket and, from there, start servicing connections. The SampleD sample code shows how to do this. <http://developer.apple.com/mac/library/samplecode/SampleD/> It's typically quite easy to modify daemon code to work in this way. I took a look at the nginx source code and it seems to have one bottleneck routine for opening its listening sockets (ngx_open_listening_sockets). You can replace that routine with the code to check in with launchd and away you go. Except, of course, that launchd daemons must follow the rules outlined in the bulleted list at the top of <x-man-page://5/launchd.plist>. However, usually that just means disabling code if you're running in launchd mode. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
On Mon, Aug 23, 2010 at 10:41 AM, Quinn "The Eskimo!" <eskimo1@apple.com> wrote:
On 19 Aug 2010, at 11:48, Dreamcat4 wrote:
Wheras Nginx is a more streamlined and optimized kind of webserver, which would be too slow for operating in that inetd kind of way. Nginx just wants to be launched and be kept running after the first incoming connection.
The correct approach to this problem is to have launchd open the listening sockets on behalf of nginx and then have nginx check in with launchd when it starts up. As part of this checkin process, it can acquire the listening socket and, from there, start servicing connections. The SampleD sample code shows how to do this.
<http://developer.apple.com/mac/library/samplecode/SampleD/>
It's typically quite easy to modify daemon code to work in this way. I took a look at the nginx source code and it seems to have one bottleneck routine for opening its listening sockets (ngx_open_listening_sockets). You can replace that routine with the code to check in with launchd and away you go.
Thank you for that insight Quinn. That makes a lot easier to take this suggestion to nginx forums and make a patch. Unfortunately its rather more of a task to go around every other OSS project asking the same sort of thing. Interestingly, someone else (Fazekas Miklos) reworked SampleD program, so that it just unloads itself from launchd. Which avoids the bug raised by my original script. The unloading process can be used as a way to tell launchd to free the socket(s) of the job so they are freed and made available. Commentary about how it works at - http://github.com/dreamcat4/brew-launchd/blob/master/ext/launchd-socket-list...
Except, of course, that launchd daemons must follow the rules outlined in the bulleted list at the top of <x-man-page://5/launchd.plist>. However, usually that just means disabling code if you're running in launchd mode.
Another tip: Nginx can be configured with 'daemon off;' and 'master_process off;' in the nginx.conf. Those options make the nginx process(es) behave much more friendly to launchd. But they arent enabled in the default nginx configuration.
S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
participants (2)
-
Dreamcat4
-
Quinn "The Eskimo!"