is antiweb officially/unofficially supported on os x?
clayton
I just got antiweb up and running on an OpenSUSE 11.3 VM, using SBCL
1.0.45. The anti webpages look really interesting, and I was able to
get a hello world .awp working correctly.
Although, wanting more, I would like to get antiweb running on the
bare-bones os x hardware of my macbook laptop (instead of a linux VM
running within it). I was able to compile antiweb using ccl on the
machine, and I can follow the installation instructions through
running this command: antiweb -hub /var/aw
However, I can't run this one: sh-3.2# antiweb -worker /var/aw/
worker.conf
When I do, I get this error: FATAL: aw_conn_unix: connect(/var/aw/
hub.socket): Connection refused
My best guess is that the error occurs because os x is messing with
port 80 when I toggle the 'web sharing' radio button. I'm guessing
that when sharing is on, apache is running, and antiweb is colliding
with apache on port 80. But when sharing is off, port 80 is shut down,
so antiweb can't work in this configuration either.
Any help would be appreciated.
Thanks, and looking forward to building my web-based project with
Antiweb!
-Clayton
Doug
On 10-12-19 10:06 PM, clayton wrote:
> Hey everyone,
>
> I just got antiweb up and running on an OpenSUSE 11.3 VM, using SBCL
> 1.0.45. The anti webpages look really interesting, and I was able to
> get a hello world .awp working correctly.
>
Nice, thanks for the compatibility report.
> Although, wanting more, I would like to get antiweb running on the
> bare-bones os x hardware of my macbook laptop (instead of a linux VM
> running within it). I was able to compile antiweb using ccl on the
> machine, and I can follow the installation instructions through
> running this command: antiweb -hub /var/aw
>
> However, I can't run this one: sh-3.2# antiweb -worker /var/aw/
> worker.conf
>
> When I do, I get this error: FATAL: aw_conn_unix: connect(/var/aw/
> hub.socket): Connection refused
>
>
This means the worker was unable to connect to the hub's
unix socket. Are you sure the hub started correctly? I would
check this by attempting to run:
antiweb -stats /var/aw
If you see an AW statistics report, the hub is running and
processing requests.
Otherwise, the hub probably did not start. I would check this log
file for any error messages:
/var/aw/aw_log/syslog
> My best guess is that the error occurs because os x is messing with
> port 80 when I toggle the 'web sharing' radio button. I'm guessing
> that when sharing is on, apache is running, and antiweb is colliding
> with apache on port 80. But when sharing is off, port 80 is shut down,
> so antiweb can't work in this configuration either.
>
Antiweb is not officially supported on OS X although I'm sure
it could be ported easily. It should be just a matter of ensuring
kqueue is used as the event API and working around OS X
dynamic library linking annoyances. I don't use OS X and don't
really have any interest in doing the port but will accept any
patches that do.
Thank you very much for writing and for your interest in AW.
Doug
clayton stanley
Wohoo! I got it to work, but it's ugly. I was hoping you might help me
clean these changes up a bit. Here's what I had to do.
[1] I could only get things to work with SBCL. CCL would compile the
files in the bin directory, but I kept getting the error I listed
previously when trying to start the hub, so it was a dead end for me.
[2] The SBCL binary on the website for OS X is 1.0.29; I couldn't get
things to compile with this version of steel-bank, so I downloaded the
1.0.45 src, and compiled on my own machine.
[3] After compiling and installing this version of steel-bank, I could
get to the point where the lisp was looking for a libantiweb64.dylib
file. That file didn't exist, but a libantiweb64.so file did, so I
tricked the system into thinking it was linux by changing Ln 206 in
the libraries.lisp file in the cffi folder:
(cffi-features:darwin . ".so") ;this has been changed from .dylib
to .so, to get AW to build on os x
[4] This small tweak to the libraries.lisp file got AW to build. I
then got to the point of starting a hub process, and when trying to
launch the process, I got a memory fault:
sudo antiweb -sbcl -hub /var/aw
fatal error encountered in SBCL pid 3156:
Unhandled memory fault. Exiting.
[5] But, if I don't start the hub process as a daemon, things work just fine:
sudo antiweb -nodaemon -hub /var/aw
Launching hub process (3178)
Hub started. Entering event-loop...
Started logger process (3181)
Launching logger process (3181)
Logger started. Entering event-loop...
[6] The worker process can't be started as a daemon either. I also had
to comment out the max-fds xconf in the worker.conf file to get it to
work:
sudo antiweb -nodaemon -worker /var/aw/worker.conf
Launching worker process (3246)
FATAL: aw_set_nofile: Invalid argument
After commenting that line out, things start up just fine:
sudo antiweb -nodaemon -worker /var/aw/worker.conf
Launching worker process (3293)
Worker started. Entering event-loop...
; compiling file "/private/tmp/localhost/doc.awp/aw_load.lisp"
(written 21 DEC 2010 04:15:18 PM):
; /tmp/localhost/doc.awp/aw_load.fasl written
; compilation finished in 0:00:00.005
With both of these processes up and running, I'm able to access a
hello world awp from localhost.
So, my first questions here are:
[1] Why the need to change dylib to so? That's in the packaged cffi
code, so I don't think I should really be changing it.
[2] Why the need to launch the processes in interactive mode
[3] What's going on with max-fds?
Not sure how much (or little) work is involved with these quirks here.
I understand if you feel that to reliably run the AW server, you
recommend that I just run Linux in a VM. If that's the case then I'll
do it. But if it's not too much work to get through these quirks, I
could really use the extra headroom to get this software running in OS
X, where the rest of the components will be running.
Thanks,
-Clayton
Doug
Sorry for the delay!
Glad to hear it's (sort of) working for you. I'd like to use your
experience to help get antiweb running out of the box on OS X. I may
have to buckle down and borrow a macbook for a day or two to get it
working but reports like yours are very much appreciated.
[1] Why the need to change dylib to so? That's in the packaged cffi
code, so I don't think I should really be changing it.
I think it's because the antiweb build script has a .so extension
hardcoded in it and .dylib is the default on OS X. Since the version of
CFFI distributed with antiweb has already diverged from the official
CFFI (and is way way out of date) I will probably go ahead and make the
same change you did.
[2] Why the need to launch the processes in interactive mode
No idea on this one... It may be some anomaly about starting the logger
process but I really need to look into it in more details.
[3] What's going on with max-fds?
All that the aw_set_nofile function does is try to do a
setrlimit(RLIMIT_NOFILE) which increases the maximum number of open
files... On OpenBSD it's some ridiculously low number for antiweb's
workflow. I should probably make this a warning instead of a fatal error.
Still I'm not sure why OS X doesn't like this... It may be some kind of
hard system limit like in OpenBSD where you have to run:
sysctl kern.maxfiles=32768
Hope this helps and thank you so much for the portability report.
Hopefully I'll have some more satisfying answers soon.
Doug
clayton
Thanks for your response, and thoughts on OS X compatibility. I'm not
sure how large the potential OS X user base would be for Antiweb, but
I for one would sure appreciate it.
-Clayton