Mystery httpd

Fucking Apple.
Dear Lazyweb,

I have Apache installed via MacPorts instead of using the macOS 12.3.1 system httpd, but something keeps killing it and running /usr/sbin/httpd instead.

How do I tell what keeps launching it and make it stop?

"launchctl list" does not list either "org.apache.httpd" or "org.macports.apache2", and both /System/Library/LaunchDaemons/org.apache.httpd.plist and /Library/LaunchDaemons/org.macports.apache2.plist contain "disabled true". Running "launchctl load -wF" does not change that.

I can't even tell how MacPorts thinks one is to launch httpd. It's such a mess. If "port load apache2" does anything, I don't know what that is. "launchctl stop" does not kill the httpd processes, maybe because it thinks the idle/looping "daemondo" process is the real httpd service? Doing "killall httpd" followed by "launchctl stop" causes "daemondo" to re-launch, which also re-launches the "httpd" processes. So obvious!

The only reason I'm using the MacPorts version instead of the system version is that Apple decided to make it impossible to run PHP, which is, you know, not convenient for me.

I have a script that runs once a minute to restart both sshd and httpd if they are wrong or have gone nonfunctional -- but the whole thing is fucking annoying.


Tags: , , ,

47 Responses:

    • Carlos says:

      Given that link is 8 years old, and the pace at which Apple obsoletes and replaces its configuration and management tools (see: CADT), I would be surprised if that works...


  1. neil says:

    I apologize in advance if this is impertinent, but could you explain some of the reasons you choose to host a website on macOS 12.3.1? Or maybe link to post in which you've already given these reasons?

    • jwz says:

      It is my desktop development machine. I need to test things before deploying them.

      • Dagon says:

        I'd love to see a post about why you'd continue to torture yourself by doing dev directly on the mac, rather than using the UI and tooling on Mac, but running a virt or Docker that shares the folders (for instant edit/test cycles) but runs the actual software your production server will.

        For me, I remote-mount my test server's directories to my dev laptop, but that's less portable and less transparent than a VM on my laptop would be.

        • jwz says:

          No, I will not be your dancing monkey. Also vigorously uninterested in your opinions on this topic.

          • David K says:

            I have a confession: this is precisely why I look at the comments on your posts about software; the guy who thinks he’s going to open your eyes to a whole new world you didn’t know existed, and your eloquent, unique, and cordial explanation that he can bite you. It’s a long-standing guilt pleasure.

  2. RobinDumontChaponet says:

    Either Port does things differently or Brew found a workaround some apple bug, but yeah (it may not help if your invested in macport) but the homebrew version works without issue.

  3. Aka_Nabla says:

    You may want to include the following key at the end your /Library/LaunchDaemons/org.macports.apache2.plist so that daemondo keeps restarting MacPorts' httpd:


  4. Aka_Nabla says:

    You may want to include the following key at the end your /Library/LaunchDaemons/org.macports.apache2.plist so that daemondo keeps restarting MacPorts' httpd:


  5. a_0001 says:

    At least on macOS 11.6.5, I ran both the unload subcommand mentioned in Sean’s link and a disable subcommand:

    sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist
    sudo launchctl disable system/org.apache.httpd

    If that doesn’t vanquish it, try garlic—but perhaps I can at least clear up two other parts of the mystery:

    The launchd.plist(5) manual page says the Disabled key no longer matters: “Previous Darwin operating systems would modify the configuration file's value for this key, but now this state is kept externally.”

    To see what jobs are loaded, you may need to run sudo launchctl list, which for me gives different output than launchctl list run as an ordinary user. The newfangled equivalent of list, by the way, is print, as in:

    sudo launchctl print system/org.apache.httpd

    • jwz says:

      "sudo launchctl disable system/org.apache.httpd" does not change what "sudo launchctl print system/org.apache.httpd" prints, which, suspiciously, includes "state = spawn scheduled".

      Also the "runs" number seems to be increasing all on its own, so I guess what's going on is: every now and then macports httpd dies, and since the system is repeatedly trying to spawn its own httpd, sometimes it succeeds.

      • a_0001 says:

        I ran both the unload and disable commands above in quick succession, after which sudo launchctl print system/org.apache.httpd prints only the expected:

        Could not find service "org.apache.httpd" in domain for system

  6. Sin2x says:

    Honestly, just use Nginx.

  7. Carlos says:

    This happens to me, too - undoubtedly not as often as to jwz, since he's much more public - but what exactly is it that causes 'net commenters, when presented with a question like "How do I make X do Y?", to respond with a critique of Z and a suggestion to do ABC instead because "you shouldn't want Y"?

    It bugs the shit out of me.


    • NdrU says:

      Sometimes "you're doing it wrong" is the only acceptable answer. Like this legendary SO post

      • Carlos says:

        Indeed, sometimes the question contains an incorrect assumption. That's usually when the questioner has little or no experience with the subject.

        That ain't the case here. jwz has a system that is fighting him as he tries to do something reasonable, even if it's not what others might choose. And he's getting answers that boil down to "you shouldn't want that" from people who almost certainly have less experience in software development than he does.


    • tfb says:

      I assume it is almost always CADT by proxy. Just as rather than solving any problem it is, somehow, always preferable to invent a vast new layer of poorly-designed shit which, if it doesn't have the original problem itself, will certainly have 3,000 others, so also rather than suggesting useful solutions to someone else's problem it is always preferable to suggest using some vast new layer of poorly-designed shit. I think it makes people feel good about their superior knowledge.

      (And of course the whole idiocy will then be justified by some hopelessly non-applicable case where there really was an XY problem. 'I would like the machine to run my program, not keep restarting its own broken one' is not an XY problem.)

    • Ben says:

      Fortuitous choice of letters, because it's literally called the XY Problem.

      Basically every unknown person who asks a weird question online should be queried to understand what they're actually trying to do. It's an extremely well established pattern of people getting into a new field.

      People are just misapplying it here to someone who "was there when it was written".

  8. Jay says:

    For what it's worth, these days developing in Docker is easy and everyone (php, apache, mysql, etc) has their own official Docker image you can just run in whatever Linux environment they prefer. I get to ignore all of Apple's shenanigans because they are isolated from the rest of my system. I use Docker desktop with a docker-compose.yaml file and so far It Just Works and I haven't had to learn all of docker's incantations or mess with building custom images

    • Carlos says:

      Paraphrased: you shouldn't want to do it the way you said, you should do it the way I like to.


      • jwz says:

        Fucking knock it off.

        I am well aware that docker exists, and if I had questions about docker, that's what I would have asked.

        That's not what I asked.

        Fucking. Stop.

      • NdrU says:

        Honest question: what do you see as an advantage of running httpd directly on the dev machine instead of in a container?

        • jwz says:

          Fuck off.

        • k3ninho says:

          Maybe because macOS hates containers? You can't easily run Cloud-Native Computing Foundation libcontainer in macOS, it usually is inside a linux VM which I'm pretty certain isn't Jamie's server environment.


      • mrz80 says:

        This rubs up against a philosophical question that has bugged me ever since Gnome 2.0 took away some of the knobs in 1.4 I used to arrange my desktop the way I want it: Why the sam freaking bloody hill is it that every time a new generation of software is "More powerful!" or "More user friendly!" it is simultaneously LESS CONFIGURABLE (which seems to me to be the OPPOSITE of "More user friendly!")?!?!?!?!?

        Or am I just a whiny old curmudgeon who should go refurbish an 029 and play with his punchcards? :P

        • Carlos says:

          [...] every time a new generation of software is "More powerful!" or "More user friendly!" it is simultaneously LESS CONFIGURABLE

          Completely agree - it's madness. GNOME gets worse with every iteration; I switched to Cinnamon to stop the bleeding, but a lot of the GNOME braindamage was already in there when they forked it.

          I mean, taking away the ability of configure my monitors not to go to sleep? I can't turn this "power saving" mode off at all, and the longest delay it will let me configure is 2 hours. It's insane. It's my computer; why the hell are you telling me what I can and cannot do with it?

          I don't think it's curmudgeonly; I just think us older people actually remember when the user was given some consideration by the designers/developers. Well, let's be honest, it's the designers that are the problem, usually, not the devs.


        • tfb says:

          It is in fact a theorem that there is absolute conservation of configurability. In this case all the configurability which used to exist in window managers (or whatever they are called now) has leaked out into 'serious' cameras, which now come with thousand-page manuals (as PDFs without tables of contents) explaining the menu system you need to fight your way through to make the device do what any camera made more than 15 years ago would have done by default and which is all anyone would ever want it to do.

          And this conservation law has really serious consequences which have recently been discovered: as the 'serious' camera market is now in irreversible collapse and, effectively, behind an event horizon which prevents configurability escaping other than into other camera models, the remaining models are growing configuration options at an increasing rate. It would be tempting to call this 'exponential' but it is far worse than this: exponentials become large but they are always finite. As seen from the co-moving camera user, the amount of configurability in the last remaining camera will become infinite in finite, and rather short, proper time.

          It is unclear what happens after this point: camera physicists disagree. One possible option is that at the point of this configuration singularity a shockwave of configurability is emitted, washing outwards over and being absorbed by other configurable systems. What happens during this absorption process is not obvious: naïvely it would seem plausible that old, lost, configuration options would reappear; in fact this will occur with probability which is asymptotically zero. Instead bewildering new options will appear: whereas, once, there might have been options to set the x and y spacing of icons, now there will be options to alter the components of the icon vector expressed in the occupancy-number basis of the Fock space for the icon configuration. On days which are prime in the Mixtec calendar this will be in old-style roman numerals, while on other days the Oksapmin counting system, must be used.

          However based on some recent work (a preprint is available on application to the usual address) I believe that it is now clear that this view is confused. In fact it is quite clear that, from the perspective of distant observers (and you do not want to be anything other than a distant observer) the configurability in fact resides essentially on the event horizon rather than passing through it, from where it is radiated via so-called Falconer's radiation to be gradually reabsorbed. The end-state is the same, but the reappearance, or rather the appearance of strange new options will happen far more gradually.

          Or so it is to be hoped.

          • Jeremiah Cornelius says:

            These are the replies that make me fondly recollect the 4 years that represent the golden years of Usenet, with its propensity for the generation of erudite, orthogonal essayists.

  9. Is there perhaps some log rotation cron job (or equivalent) configured that has $PATH set incorrectly?

    Wild guess, of course.

  10. Adam says:

    A lot of people seem to assume that JWZ is doing it wrong, but there are plenty of instances on a Mac where software gets installed and removing all those adobe sync daemons (or whatever) is like black magic because Apple changes the way their configs works and won't tell you. Being able to turn off code (Photos Memories Creepy AI service? Keychain ICloud Sync) that you don't want is fundamental to owning your computer.

    I would love to know the answer to the question he's asking.

    • jwz says:

      For those kinds of problems ("what is this stupid daemon and why is it phoning home") I cannot recommend Little Snitch highly enough. It's $45 but well worth it.

      • Adam says:

        Thanks! LS is great. If you haven't tried it, you might also like blockblock - it prevents the install of startup daemons. If you I have to let things through to make the software work (again, Adobe), getting those things to stop until I tell them to run again is crazy complicated.

        But it doesn't deal with the "apple installed it and it always runs" problem.

      • tobias says:

        I haven't monterey yet.

        There was some crap about port 5000 being occupied by some built in mac Airplay receiver service so make sure it's not that.

        Another wild idea is to apply the xattr on the built in httpd - maybe that could give you an idea, but this is just yet another wild suggestion.

        • tobias says:

          oh yea another boneheaded suggestion -> put your own /usr/sbin/httpd that is a shell script that calls their one and dump 'whoami' '$@' '$BASH' or whatever the relevant variables are for your shell of choice.

          • jwz says:

            Dude, stop throwing spaghetti at the wall. I can make wild-assed guesses as well as, and probably better than, you can.

            You have not been able to modify files in /usr/sbin/ for YEARS.

      • Jeremiah Cornelius says:

        For the stingy, there is LuLu - a fully capable replacement for LittleSnitch, if less elegant in popup dialogs. Along with xscreensaver and ports/homebrew, it's one of the 2 or 3 things I immediately stamp onto a new Mac.

        LuLu is donationware. LS killed me off, with the arbitrary costs to upgrade with my current MacOS versions. Somehow, LuLu manages to use the same .kext between kernel changes - until BigSur finally changed the extension loading framework.

        I use it with Activity Monitor - or htop, netstat and lsof because I'm stubborn.

  • Previously