AuthorTopic: DSLStats on FreeBSD - Redux (Read 991 times)

A while back I was asking around about getting DSLstats running on FreeBSD. I'd got as far as building it from source successfully and got the MDWS uploading working and was looking into getting it packaged up for installation via FreeBSD Ports system.

However, that turned out to be rather complex, and I wasn't sure I'd have the free time to act as the port maintainer in future.

Since then, there's been success making DSLstats available as a Docker container. That's great if you're already using Docker on your FreeBSD system. But, if you'd like to keep things 'slim', or your machine isn't meaty enough for the job, here's an alternative.

BackgroundFreeBSD has the ability to load 'personalities' via kernel modules. These modules act as an abstraction, making FreeBSD's kernel appear to be a different OS to selected software.

Alongside the kernel module, FreeBSD also provides a subset of Linux's 'user-land' libraries.

If we activate the Linux kernel module and install the relevant Linux libraries, DSLstats will run perfectly well on FreeBSD!

PrerequisitesThis guide assumes that you have a working FreeBSD installation, including an Xorg-based windowing system. If you want to run the machine headless, I'd suggest using the xrdp package. This will let you use a Remote Desktop client on another machine to access a virtual X session for DSLstats to run within.

Also, the guide will list the steps I took to get DSLstats running on a FreeBSD 11.1 system. I'll update this with info regarding 10.x systems when I get a chance to set up a virtual machine for testing. The steps should be very similar if not identical, so feel free to have a try and post feedback if you're running 10.x and feeling adventurous!

Also, this is using the 32 Bit version of DSLstats. I'm seeing some odd behaviour with the 64-bit version which I've not yet sorted. However, the 32-bit version works fine on my 64-bit FreeBSD 11.1 system.

Enabling Linux Emulation

First, take a look to see if the linux kernel module is already loaded. From a terminal prompt, issue the kldstat command:

Once downloaded, extract the archive file. Personally, I like to rename the resulting folder to simply 'dslstats'. I'll assume you've done the same, and that the folder is in your home directory. Feel free to move it elsewhere (/usr/local/ is probably the best place).

Back at a terminal, change to the dslstats directory:

cd ~/dslstats

Now, we need to 'brand' the executables to tell FreeBSD that these are Linux binaries that it should run within the Linux environment:

NOTE: You may get some errors/warnings about the location of 'curl' -- and maybe even some unhandled exception messages. I found that this happened on first launch, but if I hit Ctrl+C in the terminal window and relaunched, the exception messages stopped.

Setting Up DSLstats

Set up DSLstats as normal, but there's one setting you'll need to change if you're uploading to MDWS - the Path to curl executable.

Under the Configuration -> MyDSLWebStats tab, set the Path to curl executable to /usr/local/bin/curl.

Remember to untick and re-tick the Upload data to MyDSLWebStats for the change to take effect.

You're Done!

Please leave any feedback for corrections, etc. and I'll investigate/update as needed.

I hope this is helpful to some people!

To-Do

I currently run DSLstats in an xrdp virtual session. This is great because my machine's headless and I only need the most minimal of GUI environments for DSLstats. Unfortunately it means I must remote-desktop into the machine and re-launch DSLstats should it ever reboot. I need to find a way in the xrdp/x session configuration to get it to create a session and launch DSLstats automatically at startup.

Thanks! And feel free to link away - more than happy to answer forum threads, but maintaining a port is a little beyond me at the mo!

I’d like to get to the bottom of the problems with the 64bit version. The exception at startup states that there’s another instance of the program already running when there’s not - so clearly there’s some problem creating a mutex or somesuch under x64 which the code is assuming means the mutex/lock already exists. Funny one, that.

Plus, the access violations at initial startup are odd - especially how they magically go away!

Out of curiosity, does Lazarus give you to option of creating debug builds? If so, and if you’re happy to, would you mind doing a ‘with-symbols’ debug build alongside your next update? It’s not critical, since we’ve got something that works. But with that build, I’d be able to see where in the code the exception’s happening and perhaps infer what needs tweaking in the environment to avoid the errors!

Lazarus can create debug builds with symbols quite simply. It's just a couple of tick boxes in the project configuration. The debug builds are compatible with GDB, and can optionally generate code for valgrind as well. I can do this whenever you want.

The crash-on-startup in x86_64 is in the uniqueinstance.pas module. The code that uses this in dslstats.pas is even commented to say 'this doesn't work on FreeBSD' and is wrapped in a platform-check. Of course, as this is the Linux build, it's executing. Quite why it fails in Linux emulation on the x86_64 version but not the x86_32 is a bit of a mystery.

gdb sadly gets itself into an unstable state stepping into this exception, so there's no really useful info to be gleaned. It successfully detects that the IPC channel hasn't been created, but fails when creating it.

I think I'll need to dust off my Pascal knowledge and build a small test app to see what's going on and experiment!

I can easily remove the unique instance code. It's there because you can't sensibly run two instances of DSLstats on the same machine because they would both be overwriting each other's data in the configuration files directory. But if it's useful for your FreeBSD adaptation then it would be quite simple to do.