Hi Stuart,
thank you very much for the review and updates.
On Mon, Oct 11, 2021 at 10:25:57PM +0100, Stuart Henderson wrote:
[...]
> Hi Sergey. Updated version attached, A few notes on my changes, there
> are probably some others too but this is what I remember:
>
> - reduce unnecessary variables, the UNIT_xxx were only used to pass
> to configure and create directories in fake-install. The directory
> creation is pointless, so I dropped the variables and passed directly
> to configure.
>
> - move libexec to lib. openbsd standard use for libexec is for
> executables invoked by some software. other similar ports use lib for
> plugin modules.
>
> - /var/run and tmp are cleared at boot so must be created by the rc
> script, I added rc_pre. there is no point including them in the package
> because it gives a false sense that things will work after boot.
>
> - tidy dependencies
>
> - use a valid uid for @newuser/@newgroup lines
>
> - enable tests
>
> A couple of issues remain:
>
> - ruby linkage looks a bit wrong, but I think that's on the ruby side
> not the unit side. the NEEDED ELF header in unit's ruby module is set to
> just "libruby30.so" and not "libruby30.so.0.0", I think this is probably
> due to the symlink in /usr/local/lib/libruby30.so -> libruby30.so.0.0
> and/or lack of SONAME in libruby30. Maybe another porter has an idea
> what to do with this though I think it's probably not a show-stopper..
>
> - rc script nearly duplicates the standard rc_stop section but adds
> -QUIT instead of using the default (-TERM). currently the two singals
> do the same in unit anyway but comments suggest it is intended for a
> graceful shutdown (not yet implemented). I don't think that will work
> very well with rc.d anyway (rcctl restart will wait for shutdown,
> so you either use 'fast shutdown' and kill active connections, or
> use 'graceful' and have a gap while you stop accepting new connections
> while draining old). So I think it might be better to drop the rc_stop
> function.
Will take a look on that and let you know, thank you so much.
Two more questions from my side:
- the first one is related to support of different versions of
programming languages: i.e. lang/python supports three versions, 2.7,
3.8, and 3.9. It's a bit unclear how to implement that, so I need
your guidance here;
- NGINX Unit supports PHP as well, to compile a corresponding NGINX
Unit's module a shared library support needs to be enabled. That's
the `--enable-embed' configure option for php, and a couple of files
will be installed, a header file and a shared library.
> Other than those, it builds and starts ok, I have run out of patience
> trying to figure out how to configure to test runtime myself though
> (I was looking for a simple static-file config but there is nothing
> obvious). However the tests that I've enabled look promising (a couple
> of F/E in test_perl_application.py and test_respawn.py, and a couple
> of TLS-related ones, looks fairly minor).
NGINX Unit has an excellent tests suite and that one based on a recent
version of pytest. There's no static-file config, but it's possible to
talk to NGINX Unit through a control socket in JSON format.
--
Sergey Osokin
No comments:
Post a Comment