deutrino's picture
deutrino - Sun, 2021/10/03 - 09:15

the mediawiki build is blowing up in tkldev, apparently because it's trying to start apache??

I cloned the mediawiki repo in products and ran 'make'

fab-chroot build/root.patched --script conf.d/main
+ DB_NAME=mediawiki
+ DB_USER=mediawiki
+ mcookie
+ DB_PASS=95134a2f46f0e96b051cee8d1c066b54
+ ADMIN_NAME=admin
+ ADMIN_PASS=turnkey123
+ SRC=/usr/local/src
+ WEBROOT=/var/www/mediawiki
+ tar xf /usr/local/src/mediawiki-1.35.1.tar.gz -C /usr/local/src
+ rm -rf /usr/local/src/mediawiki-1.35.1.tar.gz
+ mv /usr/local/src/mediawiki-1.35.1 /var/www/mediawiki
+ chown -R www-data:www-data /var/www/mediawiki
+ service mysql start
[ ok ] Starting MariaDB database server: mysqld.
+ service apache2 start
AH00112: Warning: DocumentRoot [/var/www/html] does not exist
AH00557: apache2: apr_sockaddr_info_get() failed for tkldev
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
+ a2dissite 000-default
Site 000-default disabled.
To activate the new configuration, you need to run:
  systemctl reload apache2
+ a2ensite mediawiki
Enabling site mediawiki.
To activate the new configuration, you need to run:
  systemctl reload apache2
+ a2enmod rewrite
Enabling module rewrite.
To activate the new configuration, you need to run:
  systemctl restart apache2
+ service apache2 reload
httpd not running, trying to start
(98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Forum: 
Support
Tags: 
mediawiki
tkldev

OnGle - Mon, 2021/10/04 - 07:31

It looks to me as though you already have apache2 running. Perhaps in another build? In tkldev, each "appliance" is built in a chroot. but chroot's are not containers, all chroot's still share the same ports. Since apache uses port 80, and apache is commonly used with a lot of appliances, it's pretty common for 1 build (even a failed build) which was not properly cleaned to cause issues with another build. If this is the case, luckily it's an easy fix. First confirm it is an extra copy of apache by running the following on your tkldev:

ps aux | grep apache

should show apache running if not, check the output of this:

 netstat -ltpW | grep 80

Which will likely show nginx, or some other webserver interfering.
Next we need to figure out which appliances might be mounted, and therefor potentially interfering. We can do this with:

mount | sed -n '/^overlay/ s|.*products\/\(.*\)\/build.*|\1|p'

Which runs `mount` (the mount command without arguments will list all mounted filesystems), filters by overlay mount-type, then uses regex to pull the appliance name out of the path. Alternatively you could just run

mount

And just look for any line that begins with "overlay on" and includes "/turnkey/fab/[appliance-name-here]/build/..."

The last step is figuring out which of these appliances are running apache/something bound to port 80. If you've only got a couple of appliances, and you've already built them,the easiest way to ensure none of them are interfering with the mediawiki build is to clean each of your other builds, this will remove the chroots entirely along with any processes running inside them, make sure you've already copied out any build artifacts you want to keep then run the following:

# For each appliance listed above
cd /turnkey/fab/products/[appliance-name-here]
make clean

If you don't want to clean the build, you can instead

# For each appliance listed above
cd /turnkey/fab/products/[appliance-name-here]
fab-chroot build/root.build/ service apache2 stop

This will preserve the build, but stop apache2. If this is the issue you're encountering, you may experience it again with other software, for example mysql. The fix will also be the same, although the port may be different.

deutrino's picture

deutrino - Tue, 2021/10/05 - 05:30

Is there a downside to running 'make clean' ?

I didn't realize the build process could leave services etc running.

OnGle - Tue, 2021/10/05 - 07:21

downside is relative to your goals but make clean is roughly equivilent to the following:

# fab uses stamps to determine which stage it's at, as stages can fail we can't just check for the decks directly. This effectively tells fab the build is in a clean state.
rm build/stamps/* 
rm build build/root.spec # remove the spec from which root.build is built (i.e., resolved plan)
rm -rf build/cdroot # intermediate stage between root.product and product.iso
rm build/product.iso # remove build iso

# these are "decks", decks are just stacks of overlayfs mounts

# removes the "sandbox" deck, not included in builds, just useful for quick-feedback because you can wreck it, undeck it then rebuild it incredibly quickly
deck -D build/root.sandbox 

# removes "patched" deck, this deck applies the conf.d scripts, plan and overlay of the specific app you're building
deck -D build/root.patched

# removes "build" deck, this deck applies the conf.d scripts, plan and overlay relevant to this app from common (see /turnkey/fab/common if you're at all interested).
deck -D build/root.build

# this removes the bootstrap deck, this is just a debian bootstrap, we used to ship our own special minimum debian bootstrap but now we just leverage debootstrap.
deck -D build/bootstrap

If you want to preserve the chroots of your previous builds, failed or otherwise then you'll need to manually go in and stop any running services. If you only want to preserve the built iso then just copy/move it out before cleaning. If you're using buildtasks rather than making directly and the build successfully completed this is irrelevant as all artifacts (containers, images, etc.) are copied out of the build directory after it finishes.

(You may be interested in the tkldev docs https://github.com/turnkeylinux-apps/tkldev/tree/master/docs if you want to understand the build process in more detail they're a little old, but it should still hold up)

As far as leaving processes running, yeah It's certainly not intuitive, but often very useful for debugging, hopefully sometime in the not-so-distant future we'll move to systemd-containers instead of chroots so this'll be a non issue and we can have the best of both worlds.

Add new comment