[khiltd]

Well, we’re even further from that machine, but attempting to sort it out on another one will at least tell you whether it’s something generally wrong with that specific system or if it’s something you’re doing incorrectly. A more generalized troubleshooting approach may very well be in order if launchd is indeed failing to run a simple job.

[khiltd]

So you replaced the entire contents of your script file with that single line? If a launchd job does not run for at least 30 seconds then launchd assumes that it has died and attempts to restart it repeatedly. If you do nothing but log a single line, then it’s not going to work out very well. Similar behavior will be observed if you fork or daemonize as stated in the article:

[i]”Jobs run from launchd should not duplicate launchd functionality; for instance, they should not use chroot(2). Furthermore, they should not do the things normally required of daemon processes, such as detaching from the terminal they are initially attached to. The only things that are strictly prohibited, however, are fork()/exit() combinations (including indirect methods, such as the daemon(3) library call). A server which attempts to run itself as a daemon in this way will seem to have finished running, potentially leading to launchd respawning it, or disabling the service.”[/i]

Try something like

[code]#! /bin/sh

while true

do

echo “Pointless script running…”

sleep 10

done[/code]

[khiltd]

Yes, there is a “Nice” key as well as the “HardResourceLimits” set of keys. I’m not certain that anything specified in either of these will apply to processes other than the shell in which your script is being executed, so while your script might get a lower priority, the tools it fires off might not. I haven’t really played with it so I don’t know.

Loop unrolling is an optimization technique which strives to increase execution speed by eliminating superfluous conditional branch instructions. Such a feature would not be beneficial in this case even if it did exist, but no, shell scripts are interpreted, not compiled, and the commands contained within them are not issued asynchronously unless a given command explicitly forks or daemonizes itself. vpnd is one such tool which does this regardless of the command line options it is supplied, and so it does not get along well with launchd at all. What awstats.pl does is something which might warrant further investigation, but log analyzers are not usually very resource friendly.

It should be fairly simple to determine whether or not your script is running. Just send some output to stdout and watch the logs.

[khiltd]

Well that script is basically two completely unyielding loops, both of which fire off other CPU hogging processes repeatedly. I’d suggest making friends with nice and renice to lower your scheduling priority.

[khiltd]

[QUOTE][u]Quote by: macshome[/u][p]So what is it that people are trying to accomplish here?[/p][/QUOTE]

I believe we’re trying to get AppleJack Leopard compatible so we can reduce the number of hours we have to sit there rebooting machines ad infinitum.

[khiltd]

I see a number of flaws in your reasoning here:

1. StartInterval is clearly [b]not[/b] all you need if what you need is to specify a start time. StartInterval specifies, obviously, an interval, not any particular point in time.

2. Schedulers are generally not written to be oven timers. In order to provide accuracy and reliability, it makes far more sense to calculate times based on offsets from absolute reference points. That way you more or less just check to see if the current number of seconds since Unix Epoch is an even multiple of a job’s interval and you’re done calculating. I don’t know for a fact that this logic is employed by launchd, but it wouldn’t surprise me if it were. If you need your job to run the instant it’s loaded, that’s what the RunAtLoad tag is for.

3. XML files are only used in situations where human readability is a concern, and in most cases, it is not. Just because you can edit “jobs” doesn’t mean you can do anything useful with any given file. If people were any good at sight-reading arbitrarily formatted computer files then data recovery services would be a whole lot cheaper.

4. launchd is open source, so anyone who is interested can find out how it works. In briefly looking over the relevant portions it’s apparent that launchd relies upon BSD’s kqueue methods for its scheduling and watchpath functionality. I’ve not looked at [b]that[/b] code at all, but even if we do assume that the kernel does in fact waste time writing its timers’ intervals out to a “diary” file on disk rather than simply storing them in volatile memory, it’d be a fairly safe bet that these files would not be safe for human consumption and should be left alone.

[khiltd]

If there is such a private file I’m certain Apple wouldn’t want you mucking around with it. Why [i]can’t[/i] you use a StartCalendarInterval tag for this?

[khiltd]

[QUOTE][u]Quote by: macshome[/u][p]I’ve not messed with it in a while, but [url]http://www.dns-sd.org/[/url] is the canonical resource for this stuff.[/p][/QUOTE]

Yes, I’m aware of that site and own Stuart Cheshire’s book. Nothing in either, unfortunately.

[khiltd]

It’s difficult to say whether simply restarting AFP will cure whatever problem you were encountering, but I believe it lives at /usr/sbin/AppleFileServer and can be killed like any other process.

launchd will more than likely restart it for you almost immediately, so if you want to prevent this then you’ll need to do a launchctl unload on /System/Library/LaunchDaemons/com.apple.AppleFileServer.plist

[khiltd]

Worked a charm. Grazie.

[khiltd]

It’s in the sources, and I wouldn’t recommend using it for that purpose as it definitely kicks off the GUI in addition to leaving it hanging in a completely unusable state.

[khiltd]

I’d verify that it is actually in PEM format and try decrypting the key before importing it. I’ve never run a chat server, but Googling that error message suggests this is a fairly common problem.

[khiltd]

There are a whole lot of reasons why a VPN connection might fail; firewall is only one of them. Some general troubleshooting would be in order, probably starting with log inspection on the router, client and server.

[khiltd]

I’ve found the security tool to be broken to the point of nigh-uselessness on Leopard. It almost seems as though it was not updated to support any of the new features of Security.framework and is still heavily reliant upon now deprecated functions.

[khiltd]

[QUOTE][u]Quote by: l008com[/u][p][QUOTE][u]Quote by: Magus255[/u][p]This should give you everything you need.
http://docs.info.apple.com/article.html?artnum=106439%5B/p%5D%5B/QUOTE%5D

That actually gives about the same info as the firewall gui itself, plus RFC numbers. It doesn’t really explain what ports I need. For example there are at least 4 different VPN related ports. And 4 or more remote desktop related ports. [/p][/QUOTE]

So those 4 would obviously be the ports you’d need to open up/forward in order for those services to work. What part of that is confusing for you?

[Author]

Posts