Re: How to make a static Lua?

[Sean Conner <sean@...>]

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.