Re: How to make a static Lua?

[Daurnimator <quae@...>]

On 17 April 2016 at 13:12, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Steve Litt once stated:
>> Hi all,
>>
>> After introduction of the systemd init system, a lot of people are
>> creating their own init systems. One guy did it in Ruby.
>
>   I started down that road myself, using Lua.  And it's a nice design too,
> but not all currently developed Unix daemons would work out of the box with
> it (daemons that daemonize themselves [1] with not option to run in the
> foreground for instance).
>
>> I'm thinking that Lua is much smaller than Ruby, and in my opinion it's
>> more understandable, and from what I read, it's faster. The reason it
>> would be good to be static is so that an initramfs wouldn't be
>> necessary (though it usually is for other reasons). But static
>> compilation isn't absolutely necessary: all the libraries could go in
>> an initramfs.
>>
>> The version of Lua for this thing would need to have signal handling,
>> forking, and exec'ing. Are those features in place with standard Lua?
>
>   No, they are not.  There are Lua modules that will do that though, for
> instance:
>
>         org.conman.signal       [2]
>         org.conman.process      [3]
>
> The fork() and exec() calls are easy enough to deal with in Lua, but
> signals?  Not as straightforward to handle [4] and it gets messy rather
> quickly.
>
>> Is 5.3 available pretty much everywhere these days? If not, which Lua
>> is the most widely available?
>
>   I don't know, but my guess would be Lua 5.1, followed by Lua 5.3 (there
> just isn't a compelling reason to upgrade to Lua 5.2 in my opinion).  I
> should note that the modules I listed above can compile against Lua 5.1, Lua
> 5.2 and Lua 5.3).
>
>   -spc
>
> [1]     If that doesn't mean anything to you, don't worry about it.
>
> [2]     https://github.com/spc476/lua-conmanorg/blob/master/src/signal.c
>
> [3]     https://github.com/spc476/lua-conmanorg/blob/master/src/process.c
>
> [4]     gopher://gopher.conman.org/0Gopher%3aSrc%3areapchild.c [5]
>
> [5]     If you can't fetch that, here's the relevant bit:
>
> * This entire file exists *because* I can't properly handle SIGCHLD in the
> * server process.  What I want to do is just get the reason for a handler
> * process terminating, but not wanting to deal with EINTR, so I set the
> * handler to restart system calls.  But while I can do that in Lua, the Lua
> * signal handler doesn't get control until the Lua VM gets control, and if
> * we're sitting in a system call, that might take some time.  So, we do this
> * in C, which can get the job done.
> *
> * This code is straightforward---just export a single function to Lua that
> * run called, catches SIGCHLD, and the signal handler will reap the
> * children.

What's wrong with using signalfd? (or on a BSD: kqueue with EVFILT_SIGNAL)
When your signalfd for SIGCHLD polls ready, call wait() with NOHANG
until it doesn't return a pid.