As Corion has suggested, you have many design choices to make here, and no one here can realistically make these choices for you.

In the experience of many, a “loosely coupled” (so to speak...) system, linked by named-pipes, is often the most satisfactory arrangement because it can be scaled-up among multiple computer systems fairly easily.   Each of the worker daemons reads requests from a pipe, and posts completion status (including in-progress status reports) to another pipe or pipes.   Each daemon is also responsible for reading its own configuration files, and is obliged to lock and unlock those files (or to choose an appropriately exclusive open-mode) to ensure their integrity while doing so.

The daemons are running under the overall control of some kind of a workload-manager, which doles out work and handles any status messages.   It keeps its own “tote board” of what is going on.   Probably the easiest way to handle a monitoring GUI, then, is to define another type of request, which the GUI can make.   This request is handled by the monitor process in exactly the same way as any other.   The GUI fires requests using a timer, then updates its display based on the response received.   (If the timer goes off again before the first response is returned, the GUI does not send another one.)

What you’ll notice about a design like this is that ... it’s asynchronous.   The pipes are acting as rubber-hoses between the various pieces, each of which can basically be single-threaded.   It does not presuppose the existence of a network file-system.

What you’ll also notice about a design like this is that, it is extremely common.   The world is full of systems just like this.   They are a dime a dozen.   Yes, there are plenty of CPAN modules for building them.   And, no, I’m not going to suggest one.