Maybe Bash is Better for Managing Processes

After mucking a bit with system processes in Dart yesterday, I think today will be a “step back” day. Even though Dart currently lacks a hook to run code when the Dart VM exits, there is still plenty of power in the current Process class. Nevertheless, my initial assumptions when I first started on processes have been proven wrong, so now is a good time to take a look at what I really want to accomplish.

I need scripts that start, stop and (probably one to) clean up by-products of running my “real fake” web server for testing Dart HTTP clients. Rather than thinking of these in terms of how I might accomplish those scripts in the confines of a single Dart process, how might I accomplish them from a Bash script? More importantly, how might I accomplish doing so from a Bash script that is running plummbur_kruk (the name of the “real fake” library) as a package included in another package or application?

In the plummbur_kruk test suite itself, I have a similar Bash script that starts the server with:

dart test/dummy_server.dart &

I can then grab of the process ID of the forked Dart server so that I can kill it later.

That works inside the plummbur_kruk package, but I am going to need to run this from other packages, which means that I need to have my server start/stop/cleanup scripts directly in lib so that I can run them as:

dart packages/plummbur_kruk/server.dart &

And this is where the step back comes in—do I really need to require that programmers using plummbur_kruk start the Dart VM to perform these actions? On the one hand, any Dart developer will have access to Dart, so this is a little more platform independent. On the other hand, does platform independence matter in this case? I think not. I think that the primary use-case of plummbur-kruk is as part of a continuous integration script, which currently runs best on services like drone.io—services that run continuous integration in a Bash script.

So instead of mucking with processes and file system work in Dart, I think Bash is the better tool for this case.

Even though these will be Bash scripts in my Dart package, they will need to reside in the lib top-level directory, which is normally reserved for Dart code. Once installed in another project, only the lib directory is visible (at least presently). To access these scripts from within plummbur_kruk or from another package, I can invoke packages/plummbur_kruk/start.sh.

So I write a start.sh:

#!/bin/sh

#####
# Start a Kruk server

pid_file="kruk.pid"

dart packages/plummbur_kruk/server.dart &
server_pid=$!
echo "$server_pid" > kruk.pid

That writes the PID to a kruk.pid file.

In stop.sh, I read the PID and use it to kill the test server:

#!/bin/sh

#####
# Kill a running Plummbur Kruk server and to clean up any by-products

pid_file="kruk.pid"

if [ ! -e "$pid_file" ]
then
    echo "Kruk is not running"
    exit
fi

pid=$(cat $pid_file)
kill $pid

packages/plummbur_kruk/clean.sh

At the end, the stop.sh script cleans up by calling clean.sh, which will also be available from outside the package:

#!/bin/sh

#####
# Clean up any by-products of a Kruk server

rm -f test.db
rm -f kruk.pid

Armed with those three scripts, I can rewrite plummbur_kruk's tests as:

# Start the test server
packages/plummbur_kruk/start.sh

# Run the actual tests here...

# Stop the server
packages/plummbur_kruk/stop.sh

And that seems to work fairly well. Those scripts even ought to work if copied into another project's test or script directory should a programmer dislike the idea of running Bash scripts from plummbur_kruk's lib directory.

And in the end, I cannot say that I am thrilled with running Bash scripts plummbur_kruk's lib directory myself. But it does beat mucking with managing processes between Dart scripts and still reads fairly well. I will sleep on it, but this seems like a reasonable working solution.


Day #858

‹prev | My Chain | next›