Apt, Apache, and Lua
Today I tried upgrading my server which is running Debian unstable. I noticed that apache2 was held back. Here are some notes and a few questions at the end. Any help and comments will be greatly appreciated. Thanks!
Apt and Apache
root@lol ~ # apt-get update
Get:1 http://deb.debian.org/debian unstable InRelease [198 kB]
Get:2 http://deb.debian.org/debian unstable/main Sources [10.6 MB]
Get:3 http://deb.debian.org/debian unstable/main amd64 Packages [9,944 kB]
Get:4 http://deb.debian.org/debian unstable/main Translation-en [7,230 kB]
Fetched 28.0 MB in 2s (16.2 MB/s)
Reading package lists... Done
root@lol ~ # apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
apache2 apache2-bin apache2-data apache2-utils
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
root@lol ~ #
I wondered why apache2 was held back. I took a quick look at man apt-get and then tried to investigate with the --dry-run flag.
root@lol ~ # man apt-get
root@lol ~ # apt-get full-upgrade --dry-run
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following package was automatically installed and is no longer required:
liblua5.3-0
Use 'apt autoremove' to remove it.
The following NEW packages will be installed:
liblua5.4-0
The following packages will be upgraded:
apache2 apache2-bin apache2-data apache2-utils
4 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Inst liblua5.4-0 (5.4.6-3+b1 Debian:unstable [amd64])
Inst apache2 [2.4.59-2] (2.4.60-1 Debian:unstable [amd64]) []
Inst apache2-bin [2.4.59-2] (2.4.60-1 Debian:unstable [amd64]) []
Inst apache2-data [2.4.59-2] (2.4.60-1 Debian:unstable [all]) []
Inst apache2-utils [2.4.59-2] (2.4.60-1 Debian:unstable [amd64])
Conf liblua5.4-0 (5.4.6-3+b1 Debian:unstable [amd64])
Conf apache2 (2.4.60-1 Debian:unstable [amd64])
Conf apache2-bin (2.4.60-1 Debian:unstable [amd64])
Conf apache2-data (2.4.60-1 Debian:unstable [all])
Conf apache2-utils (2.4.60-1 Debian:unstable [amd64])
root@lol ~ #
Lua and Apache
Looks like
- liblua5.3.0 had been installed,
- the apache upgrade wanted liblua5.4.0, and that
- apt was being careful by not auto-removing liblua5.3.0, which might have been in use.
Lua? Why Lua? I didn't remember installing liblua. I had heard that Lua was a computer language, but I didn't know about Lua.
The first result of a Google search for "liblua apache" was a link to an article, Lua for Apache, at admin-magazine.com. The article didn't seem to have a date, which always is a big red flag for me, but I decided to take a quick look. I was surprised that the article seemed well written.
I noticed that the article listing on Admin-magazine's home page had dates. So I searched in their search box for articles containing the word "lua." The second result was the article I wanted, Lua for Apache. The listing contained the date "10.07.2012."
The article explains that Lua is a scripting language developed in 1993 with these prominent features:
- small, fast interpreter,
- C interface,
- imperative and functional,
- "rudimentary" support for object-oriented programming, and
- "minimal syntax."
The article says that the minimal syntax "makes Lua programs more cryptic than their PHP counterparts."
According to the article, there have been several implementations of Lua scripting for Apache. Several implementations are listed in the article. One of these, mod_wombat, by Brian McCallister, in 2006, has become [had become by 2012?] the mod_lua in the Apache mod family along with mod_perl and mod_php.
The article continues with
- how to compile Apache with Lua enabled,
- Apache configuration [again from 2012?] for Lua,
- a Lua Hello world example,
- an example form for first and last name, and
- a discussion of hooks.
Questions
It looks like my Apt and apt-get options include
apt autoremoveand thenapt-get upgrade, andapt-get full-upgrade.
Do I understand right that the former will leave liblua marked as autoinstalled, but that the latter will mark liblua as manually installed?
Does anybody here use Lua? Does anybody here use Lua with Apache? If yes, what particular feature of Lua appeals to you for your project?
New Apt Terminal Colors
By the way, Apt in Debian unstable has cool new terminal output colors! The new Apt colors look really great! It's fun to watch the Apt output!
Wish
Speaking of terminal colors, is anybody here using Wish?
I hope everyone gets the servers they want!
Comments
Debian's Changelog for apache2 has:
So I think you'll have to do
apt-get full-upgradefollowed byapt-get autoremove(I don't thinkapt-get upgradeever installs new packages)I am not using lua with apache, but have used it for some scripting (have written a lua scripting interface for clang and added lua scripting to exim4)
What does the output of 'apt autoremove' show? I wouldn't think it would remove liblua5.3-0 because you still have a dependency on it because of your current version of apache2, right? autoremove will only remove dependencies if they are no longer required by another package, therefore the upgrade would still hold apache2 because liblua5.3-0 is still installed.
apt full-upgrade will handle changes in dependencies by installing new packages and removing old ones, if needed - this will be your best option to upgrade apache2 as it will install liblua5.4-0 and remove liblua5.3-0 if no longer needed by any other packages.
A apt full-upgrade would also mark the liblua5.4-0 package as automatically installed as it was installed for a dependency against apache2.
I've used Lua lightly in the past, nothing extreme and never used it with Apache either.
SharedGrid | Fast, secure, and reliable UK, USA and Singapore web, reseller and VPS Hosting
Litespeed, Redis Cache, NVMe Drives, Daily Backups, 24x7 Support, Wordpress Optimised.
As you've searched, Lua is a scripting language designed for extending applications.
For example, I wrote a trivial Lua script for FCEUX (a NES/Famicom emulator) to monitor and modify the weapons used in game Super Contra .
FCEUX can't hard code the cheat code in source code for every game, but when combined with Lua, it provides an interpreter which is able to read player's script to cheat, thus extending the functions of the software.
As for apache's case, I guess it may be the same.
If someone likes this nostalgic Super Contra, you may try this Lua code:
MicroLXC is lovable. Uptime of C1V
Looks like a couple more updates were added since yesterday.
Looks like you are exactly right.
I hope everyone gets the servers they want!
Thanks for the link to the changelog. I have to look at those changelogs!
Yup! See
apt full-upgradeoutput just posted above.May I please ask, did you pick Lua for speed in these two uses? Or, was there another advantage of Lua which was especially attractive in these two applications?
Thanks for your reply here! Much appreciated!
I hope everyone gets the servers they want!
@entrailz mentioned on OGF that Cloudflare uses Lua. I didn't know that! I found https://blog.cloudflare.com/more-consistent-luajit-performance which is a really interesting blog post from December 2018 covering Lua performance testing at King's Collge London that was sponsored by Cloudflare. The post doesn't talk about why Cloudflare uses Lua and where Cloudflare uses Lua, but it sure seems clear that Cloudflare had been looking at Lua very carefully as of 2018. Fun to read!
I hope everyone gets the servers they want!
Mainly because Lua is very small (much smaller than something like Python) and easy to interface with C and/or C++ code (again, the Lua C API is a lot easier to work with than the Python API).
Google Gemini wrote a program in response to my request to compare time taken to write "hello world" 10,000 times to /dev/null in C versus in Lua from C versus in Python from C. Here is the program, the compile command, and the result in case anybody might be interested. No claim that the program makes sense and no claim that the result is meaningful.
But it definitely was fun messing with this program! 
I hope everyone gets the servers they want!
Gemini and I kept going through many more versions of this program, trying to modify it to use either with the regular Lua Interpreter or with LuaJIT. Finally we mutually decided to give up on the idea of combining Lua Interpreter and LuaJIT in the single program. Gemini wanted to simplify by writing two separate programs, one comparing C, Lua, and Python, and the other comparing C, LuaJIT, and Python. Here is the first of the two programs, the compile command, and the output.
I hope everyone gets the servers they want!
Here is the second version or the program using LuaJIT. with the compile command and the output.
I hope everyone gets the servers they want!
I was actually wondering why Lua time went from
to
as that's a huge difference.
Well, in the first version you are opening '/dev/null' on each iteration, while in the next versions you open '/dev/null' only once.
And then looking at the Python code, you are also always opening '/dev/null' on each iteration. To get a slightly fairer comparison, the Python code to be executed should really be:
and then I get something like:
which is a bit more reasonable.
Interesting. Took the liberty to copy and extend the lua (not the jit) script to measure the same with pypy -- crude, ran it on a new function with system(pypy a.py) on my notebook (not a vm).
Cool.
@cmeerw
Thanks for catching this mistake! You made my day!!
Please let me work through what you said to make sure that I understand.
This change you are decribing starts with the write_hello_lua() function in Version 5 (the first version posted above)
where it can be seen that the line
opens /dev/null for each write.
By contrast, the second and third versions posted above are hello_world_files_lua-9.0.c (the second version posted above)
and hello_world_files_luajit-9.1.c. (the third version posted above)
In the second and third versions posted above, the following lines open /dev/null only once, ahead of the write loop.
Yes! In Version 5,
and in hello_world_files_lua-9.0.c,
and in hello_world_files_luajit-9.1.c,
the identical line
" print('hello world from Python', file=open(os.devnull, 'w'))"always opens /dev/null for each write.
It's unfair to make Python open /dev/null 10,000 times when Lua and LuaJIT only have to open /dev/null once!
I will change the Python portion of the code as you recommend, recompile, and post the revised results.
Thanks again for taking the time to point out the mistake in the code and for providing the correction! I really appreciate it!
I hope everyone gets the servers they want!
I hope everyone gets the servers they want!
I hope everyone gets the servers they want!
I ran three sets, each set consisting of the two programs compiled from the above hello_world_files_lua-10.0.c and hello_world_files_luajit-10.0.c source code. The file results2 shown at the end of this post contains the complete output of all three sets. Prior to the results2 file, there are shown greps of the C, Lua, LuaJIT, and Python average execution time results.
Can somebody please explain to me why the average execution times vary so much?
Could the variance be caused by the fast and slow cores on the i9-13900?
The server isn't busy, so other work probably is not a factor.
Thanks! Much appreciated!
I hope everyone gets the servers they want!
Significant variation in repeated execution times of the same C program might be normal and expected:
https://stackoverflow.com/questions/54271755/why-the-execution-time-of-the-same-code-on-the-same-computer-could-be-different
https://scholar.google.com/scholar?hl=en&q=execution+time+variance+c+program
I hope everyone gets the servers they want!