A systemd service command line interactive takeover method and system based on FIFO named pipe

Abstract

The application discloses a systemd service command line interactive takeover method and system based on FIFO named pipe. The method creates an input named pipe and an output named pipe, configures a start script to transparently access the standard input and output of a service process to the named pipe in a shell redirection mode, starts a pipe keeper process to keep the pipe double-end open and consume output pipe data when there is no client connection to prevent service blocking, and a client realizes interactive communication by writing a command to the input pipe and reading a response from the output pipe. The application can restore the command line interaction capability of the server program in the systemd daemon process mode without modifying any source code of the server program, and has the characteristics of zero invasion, low resource consumption and low communication delay.

Description

Technical Field

[0001] This invention relates to the field of Linux system service management technology, and in particular to a method and system for command-line interactive takeover of systemd services based on FIFO named pipes. Background Technology

[0002] In Linux operating systems, systemd is the mainstream system and service manager. When an application registers as a systemd service, it runs as a daemon process, its standard input is disabled or connected to a null device, and standard output and standard error are redirected to the logging system. Many applications have built-in command-line interfaces based on standard input / output for runtime configuration, status queries, and troubleshooting. When such applications are deployed as systemd services, their command-line interface functionality becomes unavailable. Existing solutions typically require modifications to the server program, including adding a separate communication protocol listening port, integrating a bus communication framework, or embedding a network service interface. These solutions all require modifying the server source code, increasing system dependencies, and raising implementation complexity. Summary of the Invention

[0003] To address the shortcomings of existing technologies where standard input / output is disabled after an application registers as a system service, rendering its built-in command-line interface unusable, and where existing solutions all require modification of the server-side source code, this application provides a method and system for taking over the command-line interaction of a systemd service based on FIFO named pipes. This method creates a named pipe and uses shell redirection to transparently connect the service process's standard input / output to the pipe. A pipe holder process maintains the pipe path and consumes idle output, while the client enables interactive communication through the pipe. This restores the server's command-line interaction capabilities without modifying the server-side program's source code.

[0004] Specifically, this application provides the following technical solutions: Firstly, this application provides a command-line interactive takeover method for systemd services based on FIFO named pipes, including: Create input named pipes and output named pipes; The service process is started by a startup script. The startup script uses shell redirection to redirect the standard input of the service process to the input named pipe, and redirects the standard output and standard error of the service process to the output named pipe. The startup script starts the pipe holder process first, and then starts the service process. The pipe holder process keeps the read and write ends of the input named pipe and the output named pipe continuously open, and reads and discards the data in the output named pipe when no client connection is detected. The client opens the input named pipe in write mode and writes commands, and opens the output named pipe in read mode and reads responses, thereby enabling interactive communication with the service process.

[0005] Optionally, starting the service process via a startup script includes: The startup script starts the pipe holder process in the background and the service process in the foreground. The service process runs in the foreground, allowing the system service manager to monitor its lifecycle and trigger an automatic restart when the service process exits. The shell redirection uses append mode to write the standard output to the output named pipe.

[0006] Optionally, the pipe holder process keeps the read and write ends of the input named pipe and the output named pipe continuously open, including: Multiple threads are created to open the input named pipe in read-only mode and write-only mode respectively, and the output named pipe is opened in read-only mode and write-only mode respectively. By executing multiple threads in parallel, the blocking characteristic of the two ends of the named pipe is overcome.

[0007] Optionally, in the pipeline holding step, the pipeline holder process detecting the client connection status includes: The process identifier of the client is obtained through a shared memory region, and the client is determined to be in a connected state by checking whether the process corresponding to the process identifier is alive. When the process identifier is zero or the process corresponding to the process identifier no longer exists, it is determined that there is no client connection.

[0008] Optionally, when the pipe holder process reads and discards data in the output named pipe, the method further includes: Set the non-blocking flag at the read end of the output named pipe; It performs periodic readings at fixed intervals, reading and discarding data immediately when there is data in the pipeline, and returning immediately without blocking when there is no data in the pipeline.

[0009] Optionally, the method further includes: When the client starts, it writes its own process identifier into the shared memory area; The client clears the historical residual data in the output named pipe in a non-blocking manner and then enters the interactive loop.

[0010] Optionally, the method further includes: The client trims and reuses the line editing engine, command parsing framework, and history function from the command-line parsing library used by the service process; The client changes the input / output layer to communicate via the input named pipe and the output named pipe.

[0011] Optionally, after writing a command to the input named pipe, the client reads response data from the output named pipe and continues reading for a preset timeout period until no new data arrives, then returns to the command prompt.

[0012] Secondly, this application provides a systemd service command-line interactive takeover system based on FIFO named pipes, including: The pipe module includes input named pipes and output named pipes; The service startup module includes service unit configuration and startup script. The startup script starts the pipe retainer process and the service process, and connects the standard input and output of the service process to the pipe module through shell redirection. The pipe retainer module is used to keep the read and write ends of each pipe in the pipe module continuously open, detect the client connection status, and read and discard the data in the output named pipe when there is no client connection to prevent the service process from being blocked from writing. The client module enables interactive communication with the service process by sending commands through the input named pipe and receiving responses through the output named pipe.

[0013] Optionally, the pipe retainer module and the service startup module are configured to start automatically with the system service manager. The pipe retainer module continues to maintain pipe availability after the service process crashes and restarts, making the service restart transparent to the client module.

[0014] The beneficial effects of this application are as follows: By leveraging the operating system kernel's native named pipe mechanism and shell redirection syntax, the standard input and output of the service process are transparently connected to the named pipe during the service startup phase. A pipe maintainer process continuously maintains the pipe path and actively consumes output data when no client is connected to prevent service blockage, enabling clients to conduct interactive command-line communication with the service process via the pipe. Simultaneously, the service process still performs read and write operations through standard input and output; its original command-line logic based on standard input and output is fully preserved and functions correctly. This achieves takeover of the system service's command-line interactive capabilities without modifying any source code of the server program. The pipe maintainer process, as a lightweight background process, maintains the continuous availability of the pipe, ensuring that after the service process crashes and restarts, the new process connects to the pipe through the same redirection mechanism, transparently to the client. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the overall process of the systemd service command-line interactive takeover method based on FIFO named pipes provided in the embodiments of this application.

[0016] Figure 2 This is a schematic diagram of the system initialization and service startup process provided in the embodiments of this application.

[0017] Figure 3 This is a schematic diagram illustrating the interaction timing between the CLI client and the service process provided in an embodiment of this application.

[0018] Figure 4 This is a schematic diagram of the working process of the pipe retainer provided in the embodiments of this application.

[0019] Figure 5 This is a schematic diagram of the data consumption process without client connection provided in an embodiment of this application.

[0020] Figure 6 This is a schematic diagram of the architecture of a systemd service command-line interactive takeover system based on FIFO named pipes provided in an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with the accompanying drawings and specific embodiments. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0023] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0024] This embodiment provides a method and system for taking over command-line interaction of a systemd service based on FIFO named pipes. This method creates two FIFO named pipe files in a fixed system path as bidirectional communication channels between the service process and the client. A startup script is configured in the systemd service unit file to transparently connect the service process's standard input, standard output, and standard error to the two FIFO named pipes using bash shell redirection syntax. A resident background FIFO keeper process (fifo_keeper) maintains the pipes open at both ends using multi-threading and actively consumes data from the output pipes when no client is connected to prevent the pipe buffer from overflowing and causing write blocking of the service process. A CLI client, tailored from the service program's own command-line parsing library, enables interactive command-line communication with the service process through the FIFO pipes. This allows the complete command-line interaction capability lost in systemd daemon mode to be restored without modifying any source code of the server program. This method solves the technical problem that in the prior art, the standard input and output of an application are turned off after it is registered as a systemd service, which makes its built-in command line interface function unavailable. Existing solutions all require modification of the server source code, increase system dependencies and implementation complexity. This method achieves the beneficial effects of zero intrusion, low resource overhead and low communication latency.

[0025] In this embodiment, the system consists of the following coordinating components: systemd service manager (PID 1 process), daemon startup script, FIFO keeper process (fifo_keeper), service master process (dpdk-testpmd as an exemplary embodiment), and CLI client (dpdk-testpmd-cli). The components coordinate and communicate with each other through two FIFO named pipes (stdin.fd and stdout.fd) and System V shared memory.

[0026] like Figure 6 As shown, the system architecture is a star topology centered around FIFO named pipes. The data flow direction of stdin.fd is from CLI clients to the service process, used to transmit user-input commands; the data flow direction of stdout.fd is from the service process to the CLI client, used to transmit service output and responses. The pipes are located in a fixed path, for example, / usr / local / sbin / dpdk_app / bin / , created by the installation script using the mkfifo system call. The shared memory coordination mechanism uses the System V shared memory interface (shmget / shmat), whose data structure includes a client process identifier field; a value of 0 indicates that no client is currently connected.

[0027] like Figure 1 As shown, this method includes the following steps: S100 creates an input named pipe and an output named pipe.

[0028] like Figure 2 As shown, this phase covers the complete initialization process from installation and deployment to FIFO pipeline readiness. Specifically: S110, clears historical residual processes and rebuilds pipeline files.

[0029] Before performing the pipe creation operation, the installation script (install_service.sh) forcibly terminates any remaining processes that might be occupying FIFO pipe file descriptors, such as the service master process (dpdk-testpmd), the FIFO keeper process (fifo_keeper), and the CLI client process (dpdk-testpmd-cli). The forced termination uses the operating system's process signal mechanism, sending a SIGKILL signal (signal number 9) to the target process name. The SIGKILL signal is a forced termination signal that cannot be caught, ignored, or blocked by the target process. Upon receiving this signal, the kernel directly terminates the target process and reclaims its resources, ensuring that any remaining processes are completely eliminated without being prevented from exiting due to their own signal handling logic. The standard error output (file descriptor 2) of the killall command is redirected to the / dev / null null device file. This is based on the following considerations: during the initial system installation, the names of the three processes mentioned above do not exist in the process list of the / proc file system. killall would output a "no process found" error message to standard error. Redirecting to the null device suppresses these non-critical error outputs to keep the terminal output clean during the installation process. The presence of residual processes may cause FIFO pipe files to be occupied and unable to be deleted and rebuilt, or may cause resource contention between newly started processes and residual processes.

[0030] After the residual processes are cleared, the installation script deletes any existing old FIFO pipe files and recreates them in the preset path. The creation of the FIFO named pipe file is achieved through the mkfifo system call, which creates a special type of file node in the file system, and its behavior follows the first-in-first-out queue semantics.

[0031] For example, create two FIFO named pipe files in the path / usr / local / sbin / dpdk_app / bin / : stdin.fd as the input pipe, with data flow direction of CLI client writing and service process reading; stdout.fd as the output pipe, with data flow direction of service process writing and CLI client reading.

[0032] FIFO named pipes exist as files in the file system and do not require the communicating parties to be related. Any process with appropriate permissions can open and use the pipe through the file path. This allows systemd-managed service processes, independently running FIFO holder processes, and user-initiated CLI clients to establish a communication link through the same pair of FIFO files.

[0033] S120 generates the systemd service unit configuration file.

[0034] The installation script automatically generates a systemd service unit configuration file (.service file), which defines the service's startup method, dependencies, and lifecycle management strategy.

[0035] For example, the key contents of the service unit configuration file are as follows: The [Unit] section specifies the service description and startup dependencies, declaring that the service starts after the network target (network.target) is ready; in the [Service] section, the ExecStart field points to the full path of the daemon startup script (e.g., / bin / bash / usr / local / sbin / dpdk_app / dpdk_daemon), the Restart field is set to always to enable automatic restart after the service exits, and the RestartSec field is set to 5 seconds as the restart interval; in the [Install] section, the WantedBy field is set to multi-user.target to be automatically enabled in multi-user mode.

[0036] After the configuration file is generated, the installation script executes the following commands in sequence: `systemctl daemon-reload` to reload the systemd configuration, `systemctl start` to start the service, and `systemctl enable` to set the service to start automatically at boot. The `Restart=always` policy ensures that when the main service process exits for any reason, systemd will automatically re-execute the daemon startup script pointed to by `ExecStart`, thereby restarting the FIFO maintainer and the service process. The new process then re-establishes the communication link through the same FIFO pipe file.

[0037] S200, configure the systemd service unit file so that it starts the service process through a startup script. The startup script first starts the pipe holder process in the background, and then starts the service process in the foreground. It also uses shell redirection to redirect the standard input of the service process to the input pipe, and redirects the standard output and standard error of the service process to the output pipe.

[0038] The daemon startup script is interpreted and executed by the bash shell. This is because shell redirection syntax (<, >>, 2>&1) must be parsed and executed by bash. Bash is responsible for orchestrating the startup order (FIFO maintainers first, then service processes), and it also cleans up any remaining processes. Specifically, it includes the following sub-steps: S210, start the script to clear residual processes.

[0039] The first operation performed by the daemon startup script is to clear any remaining processes. In scenarios where systemd triggers an automatic restart, the previous FIFO keeper and service processes may not have completely exited, and file descriptors held by these remaining processes can prevent new processes from properly opening the FIFO pipe. The script clears these remnants by sending forced termination signals to the fifo_keeper and dpdk-testpmd process names. Output is redirected to a null device to suppress error messages generated when there are no remaining processes.

[0040] S220, start the pipe holder process in the background and start the service process in the foreground.

[0041] After the residual processes are cleared, the core operations of the script execution are divided into two steps.

[0042] The first step is to start the FIFO holder process in the background (using the shell's & postfix operator). Starting it in the background ensures that the FIFO holder completes the opening operation at both ends of the pipe before the service process, putting the pipe in a ready state. The multi-threading mechanism of the FIFO holder will be explained in detail in subsequent steps.

[0043] In the second step, the service process is started in the foreground mode and IO redirection is performed simultaneously. Exemplarily, the structure of this command is: the path of the service executable file is followed by startup parameters, and then the shell redirection syntax. Therein, <stdin.fd connects the standard input (file descriptor 0) of the service process to the FIFO input pipe, so that the service process reads commands from this pipe; >>stdout.fd writes the standard output (file descriptor 1) to the FIFO output pipe in the append mode; 2>&1 merges the standard error (file descriptor 2) to the same target of the standard output. Writing to the output pipe using the append mode (>>) instead of the overwrite mode (>) has important technical significance — the append mode avoids truncation operations on the pipe file at each write, ensuring complete data transmission.

[0044] Running the service process in the foreground mode is a key design decision of this solution. When the dpdk-testpmd process exits, since it is the foreground process of the daemon script, the script exits accordingly. After systemd detects that the main process exits, it automatically re-executes the entire daemon script according to the Restart=always policy, thereby achieving a full restart including the FIFO keeper. If the service process runs in the background mode, the daemon script will exit immediately, and systemd may misjudge that the service has exited normally and will not trigger a restart.

[0045] Exemplarily, the content of the daemon startup script (dpdk_daemon) can be divided into three functional segments in the execution order. The first functional segment is a residual process clearing segment, which includes two forced termination commands to clear the fifo_keeper and dpdk-testpmd processes respectively, and the standard error of each command is redirected to the null device to suppress error prompts generated when there is no target process. The second functional segment is a FIFO keeper startup segment, which starts the fifo_keeper executable file in the background mode, and the & symbol at the end of this startup command instructs bash to place the process to run in the background. The third functional segment is a service process startup and IO redirection segment, which is the core content of the script, including the path of the service executable file, all startup parameters (EAL parameters and application parameters), and three redirection operators. The execution of the three redirection operators is processed by bash sequentially in a left-to-right order: First, <stdin.fd is processed: bash calls open() to open the stdin.fd file in O_RDONLY mode to obtain a file descriptor, and then copies this file descriptor to the position of file descriptor 0 (standard input) through dup2(); Next, we process stdout.fd. Bash calls open() to open the stdout.fd file in O_WRONLY|O_APPEND mode to obtain another file descriptor, and then uses dup2() to copy it to the position of file descriptor 1 (standard output). Finally, by processing 2>&1, bash uses dup2() to point file descriptor 2 (standard error) to the target currently pointed to by file descriptor 1 (i.e., stdout.fd), thus merging standard error into the same output channel as standard output.

[0046] After all redirection settings are complete, bash calls the execve() system call to replace itself with the process image of the service executable file. The service process inherits all the file descriptor mappings that bash has set.

[0047] The startup parameters for dpdk-testpmd are divided into two groups, separated by double hyphens (--). The parameters before the hyphens are EAL (Environment Abstraction Layer) parameters, used to configure the DPDK runtime environment. These include specifying the CPU core set to use (the logical core list is specified via the -l parameter), specifying the large page memory configuration (the amount of large page memory allocated to each NUMA node is specified via the --socket-mem parameter), and specifying the network device to bind to (the PCI device address is specified via the -a parameter). The parameters after the hyphens are application layer parameters. The -i parameter instructs dpdk-testpmd to enter interactive mode—a prerequisite for command-line takeover in this solution. This mode allows dpdk-testpmd to read command strings from standard input (redirected to stdin.fd) and execute corresponding forwarding configuration operations after startup. If the -i parameter is not specified, dpdk-testpmd will run in automatic test mode, not listening to standard input, and command-line takeover will not be effective.

[0048] S300, the pipe retainer process keeps the read and write ends of the input pipe and the output pipe continuously open.

[0049] like Figure 4As shown, the FIFO keeper (fifo_keeper) is a resident background process used to keep both ends of the FIFO pipe continuously open, preventing the service process from being blocked or abnormally exiting due to abnormal pipe status. When there are no readers at the write end of the pipe, the write operation will generate a SIGPIPE signal, causing the write process to terminate abnormally; when there are no writers at the read end of the pipe, the read operation will return the end-of-file marker. Without a FIFO keeper, when the CLI client is not yet connected or has been disconnected, the service process writing data to stdout.fd will receive a SIGPIPE signal due to the lack of readers, causing the service to exit abnormally. The FIFO keeper ensures that the pipe is always available by continuously holding the file descriptors at both ends of the pipe. Specifically: S310 opens all ports of the pipe in parallel using a multi-threaded approach.

[0050] When a FIFO is opened in read-only mode, the `open()` call will block until another process opens the same FIFO in write mode; and vice versa. A FIFO holder needs to open all four ends of two FIFO pipes simultaneously in read-write mode (the read end of `stdin.fd`, the write end of `stdin.fd`, the read end of `stdout.fd`, and the write end of `stdout.fd`). If opened sequentially, the first `open()` call will block indefinitely because the open operation on the other end will never be executed.

[0051] To overcome this blocking characteristic, the FIFO holder adopts a multi-threaded concurrent opening scheme.

[0052] Specifically, four threads are created, each responsible for opening a file descriptor: the first thread opens stdin.fd in O_RDONLY mode (read end of the input pipe), the second thread opens stdin.fd in O_WRONLY mode (write end of the input pipe), the third thread opens stdout.fd in O_RDONLY mode (read end of the output pipe), and the fourth thread opens stdout.fd in O_WRONLY mode (write end of the output pipe).

[0053] Since the four threads execute in parallel, the read-end open operation and the write-end open operation of stdin.fd satisfy each other's waiting conditions, and the same applies to stdout.fd. Thus, all four open() calls can be completed smoothly without deadlock.

[0054] After the threads are created, the main thread of the FIFO holder waits for all four threads to finish executing through the thread synchronization mechanism (pthread_join) to confirm that all file descriptors have been successfully opened.

[0055] This multi-threaded opening scheme works closely with the startup order in the daemon startup script. The daemon script first starts the FIFO holder in the background, and the FIFO holder's four threads quickly complete the opening operations at both ends of the pipe; then the service process redirects via shell (<stdin.fd> When a pipe is opened (>stdout.fd), the service process's open() call will return immediately without blocking because the FIFO holder already holds the file descriptors of the other end of each pipe. This timing guarantee is fundamental to the correct operation of the scheme.

[0056] S320, the pipe retainer continuously holds the file descriptor to maintain pipe availability.

[0057] After all file descriptors are successfully opened, the FIFO holder enters a resident running state. Throughout its lifecycle, the FIFO holder continuously holds the four file descriptors without closing them. This ensures that regardless of whether a CLI client is connected, there is always at least one reader and one writer at each end of the FIFO pipe. This guarantees that the service process's write operations will not trigger a SIGPIPE signal due to the lack of readers, and the service process's read operations will not receive an end-of-file marker due to the lack of writers. Since the FIFO holder process itself is a lightweight resident process, it mainly remains in a dormant state when no output / consumption operations are required, thus its consumption of system resources is negligible.

[0058] In typical service operation scenarios, the CPU utilization of the FIFO holder process is low, the resident memory usage is less than one megabyte, and the performance impact on the host system is negligible.

[0059] Regarding the kernel buffer mechanism of FIFO pipes, the Linux operating system allocates a circular buffer in kernel space for each FIFO pipe. Since Linux version 2.6.11, the default size of this buffer is 65536 bytes (64KB), which can be adjusted using the `F_SETPIPE_SZ` command in the `fcntl()` system call. The maximum size is limited by the ` / proc / sys / fs / pipe-max-size` kernel parameter. When a writing process calls `write()` to write data to the pipe, the kernel copies the data from user space to the pipe buffer; when a reading process calls `read()` to read data from the pipe, the kernel copies the data from the pipe buffer to user space and releases the corresponding buffer space. This kernel-level data copying operation constitutes the lower limit of pipe communication latency. Because data transmission does not pass through the network protocol stack and does not involve serialization / deserialization overhead, its latency is in the microsecond range, far lower than communication schemes based on sockets or HTTP.

[0060] When the pipe buffer is full, subsequent `write()` calls will be suspended in blocking mode until the reading end removes data from the buffer and releases the space. With the default 64KB buffer configuration, assuming the service process outputs 1KB per second (typical log and status output), if no process consumes output data, the buffer will fill up in approximately 64 seconds. After this, any standard output write operations by the service process will be blocked. The 100ms polling consumption mechanism of the FIFO holder ensures that data in the buffer is cleared before it accumulates, reducing the risk of service blocking.

[0061] In addition, the FIFO holder uses the POSIX thread library (pthread) to implement multi-threaded concurrent opening. The main thread creates four worker threads using the `pthread_create()` function. Each worker thread's entry function receives a parameter indicating the target it is responsible for opening (the input pipe's read end, input pipe's write end, output pipe's read end, or output pipe's write end). The worker threads directly call the `open()` system call in their entry functions, which blocks until the other end of the FIFO pipe is opened. Because the four worker threads execute in parallel, when thread 1 executes `open(O_RDONLY)` on `stdin.fd`, it blocks waiting for the write end to be ready, while thread 2 simultaneously executes `open(O_WRONLY)` on `stdin.fd`. Both threads return simultaneously after satisfying each other's waiting conditions. The two threads for `stdout.fd` behave similarly. After all four `open()` calls return successfully, each worker thread exits. The main thread waits for all worker threads to complete execution sequentially through four `pthread_join()` calls, confirming that all file descriptors have been successfully acquired before entering the main loop phase of the pipe holding process.

[0062] It's important to note that all four `pthread_create()` calls must complete before any thread begins executing `open()`. In practice, since `pthread_create()` only creates the thread's kernel data structures and adds them to the scheduling queue, and the actual execution of the thread depends on the operating system scheduler's allocation, a thread might begin execution before all four `pthread_create()` calls are completed. However, even if a thread executes `open()` first and enters a blocked state, it is merely waiting for the other thread's open operation; no error or timeout will occur. When the other thread is finally scheduled to execute and completes `open()`, the blocked thread will immediately return.

[0063] For example, assume the system starts the fifo_keeper process at the initial moment. About 1 millisecond after startup, the main thread creates threads T1 to T4 through 4 pthread_create() calls.

[0064] Specifically, T1 is responsible for opening stdin.fd in O_RDONLY mode, T2 is responsible for opening stdin.fd in O_WRONLY mode, T3 is responsible for opening stdout.fd in O_RDONLY mode, and T4 is responsible for opening stdout.fd in O_WRONLY mode.

[0065] Suppose the operating system scheduler first schedules T1 to execute. After T1 calls open(stdin.fd, O_RDONLY), it enters a blocked state (waiting for the write end of stdin.fd to be opened). Then, the scheduler schedules T2 to execute. T2 calls open(stdin.fd, O_WRONLY). At this point, the kernel detects that the read end of stdin.fd has already been opened by T1, so T2's open() immediately returns successfully. Simultaneously, the kernel wakes up the blocked T1, and T1's open() also returns successfully.

[0066] Similarly, T3 and T4 execute sequentially and unblock each other. Then, all four `pthread_join()` calls in the main thread return, confirming that all four file descriptors have been acquired. The entire pipeline readiness process is completed within milliseconds, much earlier than the start of the service process in the daemon script (the initialization process of dpdk-testpmd typically takes several seconds, involving large page memory allocation, network interface card binding, and forwarding engine initialization).

[0067] Furthermore, in systemd's service management model, the process started by the command specified by ExecStart is considered the main process of the service. When ExecStart points to a shell script, the shell process itself becomes the main process of the service. Commands running in the foreground within the script (without the '&' suffix) will block the shell process until the command exits. In this case, the exit of the shell process is equivalent to the exit of the main service process, and systemd can correctly detect this exit event and execute the corresponding action according to the Restart policy. Conversely, if the service process runs in the background (with the '&' suffix), the shell script will immediately execute the next command or exit after starting the background process. Systemd will detect the shell process exiting and mistakenly judge it as the service having stopped.

[0068] The `RestartSec=5` parameter specifies the service restart interval, meaning it waits 5 seconds after detecting a service exit before executing the restart. This interval is designed to prevent a storm of frequent restarts if the service crashes during startup. The 5-second interval provides a cooling window, allowing transient conditions that could cause crashes (such as temporary resource unavailability or dependent services not yet being ready) to dissipate during this time. During restart execution, the daemon script first clears the old FIFO maintainer process (created in the previous startup and potentially still running after a service crash), then recreates the FIFO maintainer and service processes in the normal startup order. Since the FIFO pipe files always exist in the file system (they are created during installation and are independent of the service process's lifecycle), the new FIFO maintainer and service processes reconnect to the pipes via the same file path, making the entire restart process transparent to the pipe file level.

[0069] Furthermore, the FIFO holder is started in the daemon startup script in the background (with the '&' suffix). This means it's not a service process directly managed by systemd, but rather a child process of the daemon script. When the daemon script exits (due to the foreground service process exiting), the FIFO holder, as a background child process, is adopted by the init process (PID 1) and continues running. This behavior ensures that the FIFO holder still holds the pipe's file descriptor during service restarts, and the pipe doesn't become unavailable because all ports are closed. However, the daemon script actively cleans up the old FIFO holder process upon re-execution. This is because the new daemon script needs to start a completely new FIFO holder to ensure state consistency, as the old FIFO holder might be in an unexpected state (e.g., a failed client PID remains in shared memory). Using a new instance avoids this kind of state residue problem.

[0070] S400, the pipe retainer process detects the connection status of the client. When no client connection is detected, it reads and discards the data in the output pipe to prevent the service process from being blocked from writing due to the pipe buffer being full.

[0071] like Figure 5 As shown, a FIFO pipe maintains a fixed-size buffer in the operating system kernel. When this buffer is full, subsequent write operations will be blocked until data is read from the buffer. During operation, the service process continuously writes log information, status updates, and notifications to standard output. In scenarios without CLI client connections, if no process reads data from the output pipe, the pipe buffer will gradually fill up, eventually causing the service process's `write()` system call to block, and the entire service to stop responding. Specifically: The S410 detects client connection status through a shared memory region.

[0072] State coordination between the FIFO maintainer and the CLI client is achieved through a shared memory mechanism. This embodiment uses the System V shared memory interface, employing the `ftok()` function to generate a unique shared memory key based on a fixed directory path and a fixed identifier, ensuring that the FIFO maintainer and the CLI client can locate the same shared memory region. The data structure of this shared memory region includes a client process identifier field (user_pid), used to record the process ID of the currently connected CLI client. When this field has a value of 0, it indicates that no CLI client is currently connected.

[0073] The FIFO (FIFO Keeper) executes client connection status detection logic in its main loop. In each loop iteration, the FIFO first reads the process identifier field from shared memory. If this field is not zero, the FIFO further checks whether the process corresponding to that process identifier is still alive through the operating system interface. The process liveness check is implemented by sending a signal 0 (empty signal) to the target process. This signal has no effect on the target process and is only used to detect its existence. If the process is alive, the FIFO determines that the CLI client is still connected, skips the output consumption operation, and leaves the data in the output pipe for the CLI client to read. If the process is detected as no longer existing (i.e., the CLI client has exited but has not cleared the process identifier in shared memory), the FIFO clears the process identifier field in shared memory to zero, restoring the state to one without client connections.

[0074] It should be noted that when the CLI client starts, it writes its own process identifier into the shared memory. After the FIFO holder detects that the process identifier is non-zero and the process is alive, it stops consuming output data, and the data remains in the pipe for the CLI client to read. When the CLI client exits or the FIFO holder finds that the process corresponding to the process identifier does not exist, the FIFO holder resumes consuming output data.

[0075] The S420 periodically reads and discards output pipe data in a non-blocking manner.

[0076] When the FIFO holder determines that there is no CLI client connection, it enters output data consumption mode. The FIFO holder uses the `fcntl` system call to set the `O_NONBLOCK` flag on the file descriptor at the read end of the output pipe, switching it to non-blocking mode. In non-blocking mode, the behavior of the `read()` system call changes: when there is data to read in the pipe, `read()` immediately returns the amount of data read and removes the data from the pipe buffer; when there is no data in the pipe, `read()` immediately returns the error code `EAGAIN` instead of blocking and waiting. This ensures that the FIFO holder will not hang while waiting for data.

[0077] The FIFO holder is polled at fixed intervals in the main loop.

[0078] For example, a polling interval of 100 milliseconds strikes a balance between CPU utilization and responsiveness. Too short an interval will increase CPU usage, while too long an interval may cause the pipe buffer to fill up between polls. The default buffer size for a FIFO pipe in the Linux kernel is 65536 bytes. Within a 100-millisecond polling interval, even if the service process continuously outputs data at a rate of 10KB per second, the amount of data accumulated in a single polling cycle is approximately 1KB, far less than the buffer capacity, and will not trigger write blocking.

[0079] In extreme scenarios (such as when a service process performs a statistics dump operation, generating a large burst of output), the FIFO holder may need to execute multiple read() calls in a single poll to empty the buffer. The design of cyclically reading until EAGAIN ensures that even in the face of a sudden surge of output, the data can be fully consumed. In each poll, the FIFO holder calls read() repeatedly until it returns EAGAIN, ensuring that all data in the pipe buffer is completely consumed and discarded. The read data is not saved or processed; it only serves to empty the pipe buffer and keep the pipe open. This ensures that the service process's data plane can still function normally when there is no CLI client connection, and its write operations to standard output will not be blocked due to a full pipe buffer.

[0080] S500, the client opens the input pipe in write mode and the output pipe in read mode, and realizes interactive communication with the service process by writing commands to the input pipe and reading responses from the output pipe.

[0081] like Figure 3 As shown, this step describes the complete interaction process between the CLI client and the service process. The CLI client is a terminal program that allows users to interact with the systemd service process via command line.

[0082] S510, Client Startup and Shared Memory Registration.

[0083] When the CLI client starts, it first executes an initialization sequence. The first step of initialization is to write its own process ID (PID) to the process ID field of the shared memory region, notifying the FIFO holder to stop consuming data from the output pipe. The write operation is implemented through the System V shared memory interface (shmget / shmat), using the same ftok() parameters as the FIFO holder to generate a shared memory key value, ensuring that it locates the same shared memory block.

[0084] The second step of initialization is to open stdout.fd (the output pipe) in read-only mode (O_RDONLY) and set it to non-blocking mode. Subsequently, the CLI client performs a clearing operation for any remaining historical data. This is because, within the time window between the FIFO holder stopping consuming output data and the CLI client completing the connection establishment, the service process may have written new data to the output pipe. This data belongs to the output before the CLI client connected and should be discarded. The clearing operation is implemented by repeatedly calling the non-blocking read() function, reading and discarding all data in the pipe until read() returns EAGAIN, indicating that the pipe is empty. After clearing, the CLI client displays a command prompt on the terminal (exemplarily testpmd>) and enters an interactive loop waiting for user input.

[0085] S520 is an interactive loop of command sending and response receiving.

[0086] In the interactive loop, the CLI client waits for the user to type commands. The characters entered by the user at the command prompt are processed locally by the CLI client, including line editing operations (cursor movement, character deletion and insertion, Home / End key positioning), command history browsing (accessing historical command records stored in the loop buffer using the up and down arrow keys), Tab key auto-completion (prefix matching based on registered command tags), and parsing and responding to VT100 terminal control sequences.

[0087] After the user presses Enter to confirm the input, the CLI client sends the edited command string to the service process. The command sending implementation is unique: each time a command is sent, the CLI client independently opens stdin.fd (the input pipe) in write-only mode (O_WRONLY), writes the command string to the pipe using the write() system call, and immediately closes the file descriptor after writing. Each subsequent command send executes an independent open-write-close sequence, thus avoiding resource leaks that could result from holding the file descriptor for an extended period. The service process reads the command from its standard input (redirected to stdin.fd) and executes the corresponding processing logic. The processing result is written to the output pipe via its standard output (redirected to stdout.fd).

[0088] After sending a command, the CLI client enters the response receiving phase. Response receiving employs a timeout mechanism: the CLI client records the current timestamp as the start time and continuously reads data from stdout.fd in a non-blocking manner within a preset timeout period (exemplarily 500 milliseconds). In each read loop, the CLI client calculates the time difference between the current time and the start time; if this time difference exceeds the preset timeout, the read loop exits. Data successfully read within the timeout window is immediately output to the user terminal, allowing the user to see the service process's response in real time.

[0089] It's important to note that the CLI client's timeout read is implemented using a polling-based approach rather than a signal-based one. Specifically, after sending a command, the CLI client enters a while loop. In each iteration, it performs the following operations: First, it retrieves the current system timestamp and calculates the time difference from the start time. If the time difference exceeds a preset timeout threshold, it exits the loop. Then, it calls `read()` in non-blocking mode to read data from `stdout.fd`. If valid data is found, it writes it to the terminal's standard output and resets the timeout start time (because the arrival of new data means the service process is still outputting response content, and the timeout timer should restart from the moment the latest data arrived). If `read()` returns `EAGAIN`, it indicates that there is no data in the pipe, and the CLI client performs a short sleep (exemplarily 10 milliseconds) before entering the next loop iteration. This ensures that even if the service process's response output is written multiple times (each `write()` call outputs one line or one data block), as long as the interval between two adjacent outputs does not exceed the timeout threshold, the CLI client will continue to wait and receive the entire response content.

[0090] Additionally, the command string written by the CLI client to stdin.fd must end with a newline character (ASCII code 0x0A) because the service process's command line parsing logic uses the newline character as the termination marker for command input. When the service process's standard input reads a newline character, its cmdline library's line buffering logic submits the characters accumulated in the buffer as a complete command to the command parser for processing. If the command string does not end with a newline character, the service process will continue to wait for more input without executing the command, causing the CLI client to receive no response after a timeout.

[0091] When a user enters the `quit` command or presses Ctrl+D in the CLI client, the CLI client executes the following exit cleanup sequence: First, it clears the process identifier field in shared memory to zero, notifying the FIFO maintainer to resume output data consumption; then, it closes the open stdout.fd read-end file descriptor; finally, it calls the process exit function to terminate itself. Clearing the process identifier in shared memory ensures that the FIFO maintainer can promptly detect the CLI client's disconnection and immediately resume output data consumption after the CLI client exits, preventing the service process from eventually blocking due to the pipe buffer gradually filling up after the CLI exits.

[0092] The CLI client reuses the `cmdline_parse` module, which registers a set of command descriptors during initialization. Each command descriptor defines the syntax structure of a valid command (including command keywords, parameter types, and the number of parameters). When the user presses the Tab key, the `cmdline_rdline` module passes a portion of the input from the current input buffer to the `cmdline_parse` module's completion function. This function iterates through all registered command descriptors, checks the command prefix of each descriptor to see if it matches the current partial input, and returns a list of all matching command candidates to the `cmdline_rdline` module. If only one candidate command matches, the `cmdline_rdline` module automatically fills the remaining characters into the input buffer and displays it on the terminal; if multiple candidate commands exist, it displays the entire candidate list on the terminal for the user to choose from. Because the command descriptors registered by the CLI client and those used internally by the service process originate from the same source (both are trimmed from the command registry of the DPDK cmdline library), the Tab completion result of the CLI client is consistent with when the user operates directly within the service process.

[0093] S530, command line editing functionality is trimmed and reused from the service program command line parsing library.

[0094] The CLI client's command-line editing functionality was not developed from scratch, but rather directly tailored from the command-line parsing library used by the service program (dpdk-testpmd). Specifically, the CLI client reuses four core modules from the DPDK cmdline library: the cmdline_rdline module provides line editing and command buffering functions, implementing interactive operations such as cursor positioning, character insertion and deletion, and jumping to the beginning and end of lines; the cmdline_parse module provides a command parsing framework, maintaining the syntax tree structure of registered commands and performing lexical analysis and syntax matching; the cmdline_vt100 module is responsible for processing terminal control sequences, parsing and responding to ANSI / VT100 escape sequences to achieve terminal display control; and the cmdline_cirbuf module stores command history in a circular buffer data structure, supporting the use of the up and down arrow keys to browse executed historical commands.

[0095] The CLI client's modifications to the aforementioned modules are limited to the adaptation of the IO layer, replacing the original direct reading and writing of standard input / output (or network sockets) with communication via FIFO pipes. Upper-layer functionalities such as the command parsing framework, auto-completion logic, and history management remain completely unchanged. This reuse strategy brings two key advantages: First, the CLI client's command syntax and completion behavior are completely consistent with the service's internal structure, providing a user experience identical to running the service program directly in the terminal, eliminating protocol incompatibility issues. This means that every command executed by the user in the CLI client has the same syntax, parameter types, parameter value ranges, and output format as when operating directly in the service process's interactive terminal, eliminating the need for operations personnel to learn new command sets or adapt to different interaction styles. Second, the development workload is minimal, requiring only adaptation of a small amount of IO layer code, without needing to reimplement the complete command-line interaction framework.

[0096] The applicable scenarios for this solution include, but are not limited to, the following: In DPDK data plane application scenarios, DPDK programs requiring interactive mode, such as dpdk-testpmd, can regain their full CLI management capabilities after service-oriented deployment using this solution. Operations personnel can query port status, modify forwarding rules, and diagnose data plane faults in real time without stopping data plane forwarding. In embedded device service scenarios, resource-constrained embedded platforms typically lack the capacity to run HTTP servers or the D-Bus framework. This solution relies solely on the operating system kernel's native FIFO pipe mechanism. The FIFO holder process has approximately 300 lines of C code, with minimal memory footprint, making it suitable for deployment in such resource-constrained environments. In traditional CLI program service-oriented scenarios, applications originally running in foreground interactive mode can be registered as systemd services without any modifications to the program source code. Only a daemon startup script and a FIFO holder need to be written to achieve CLI takeover after service-oriented deployment. In debugging and production-compatible scenarios, the same program can be run directly in the terminal via the `debug_mode` script for development debugging, or it can be run as a service via a `daemon` script for production environments. Switching between the two running modes only involves selecting the startup script; the program binary files are completely identical. In actual engineering practice, the systemd service deployed based on this solution has been running stably on multiple physical servers and virtualization environments, verifying the portability and reliability of the solution across different hardware platforms and operating system distributions.

[0097] This embodiment also provides a systemd service command-line interactive takeover system based on FIFO named pipes, such as... Figure 6 As shown, the system includes a pipeline module, a service startup module, a pipeline retainer module, and a client module. Wherein: The pipeline module includes an input named pipe and an output named pipe created under a preset path. The data flow direction of the input named pipe is from the client module to the service process, used to transmit user-input commands. The data flow direction of the output named pipe is from the service process to the client module, used to transmit service output and response. The named pipes are created as special file nodes of type FIFO in the file system through the mkfifo system call, following the first-in-first-out queue semantics. In this embodiment, the input named pipe is the stdin.fd file, and the output named pipe is the stdout.fd file, both located under the same fixed path.

[0098] The service startup module includes a systemd service unit configuration and a daemon startup script. The systemd service unit configuration defines the service startup method and lifecycle management strategy; its ExecStart field points to the daemon startup script, and its Restart field is set to always for automatic restart. The daemon startup script is interpreted and executed by the bash shell, responsible for starting the pipe maintainer module and the service process in the correct order: first, starting the pipe maintainer in the background to ensure both ends of the pipe are ready, and then starting the service process in the foreground using shell redirection syntax (…).<stdin.fd> `stdout.fd 2>&1)` connects the standard input and output of the service process to the named pipes in the pipe module. The service process runs in the foreground, enabling the systemd service manager to detect its exit event and trigger an automatic restart. After restarting, the new process connects to the same pair of named pipes through the same redirection mechanism.

[0099] The pipe maintainer module is a resident background process, and its startup and lifecycle are managed by the daemon startup script of the service startup module. During startup, the pipe maintainer module simultaneously opens four file descriptors (read and write ends) of two pipes in the pipe module using a multi-threaded approach, leveraging parallel execution to overcome the blocking characteristic of the FIFO pipe's `open()` call. During its resident operation, the pipe maintainer module continuously holds these file descriptors to maintain pipe availability and monitors the connection status of the client module through a shared memory coordination module. When no client connection is detected, the pipe maintainer module periodically reads and discards data in the output named pipe in a non-blocking manner to prevent the service process from writing and blocking due to a full pipe buffer. The pipe maintainer module is configured to start automatically with systemd, continuing to maintain pipe availability even after the service process crashes and restarts, making service restarts transparent to the client module.

[0100] The client module is an interactive terminal program. Its command-line editing functionality is tailored from the command-line parsing library used by the service process itself. It reuses the line editing engine (cmdline_rdline), command parsing framework (cmdline_parse), terminal control sequence processing (cmdline_vt100), and circular buffer history recording (cmdline_cirbuf) modules, only changing the I / O layer to communicate through FIFO named pipes in the pipe module. Upon startup, the client module registers its process identifier in the shared memory coordination module, opens the input named pipe in write mode to send commands, and opens the output named pipe in read mode to receive responses. The client module provides command syntax parsing, tab auto-completion, and command history navigation functions locally that are completely consistent with those within the service process.

[0101] The system also includes a shared memory coordination module, implemented based on the System V shared memory mechanism, which stores the process identifiers of the client modules. This shared memory coordination module serves as a state coordination channel between the pipe holder module and the client modules. Specifically, when a client module connects, it writes its process identifier to the shared memory. The pipe holder module stops consuming output data after detecting a non-zero process identifier and that the process is alive. When a client module disconnects, the pipe holder module clears the process identifier and resumes consumption after detecting that the process no longer exists. The shared memory coordination module uses the `ftok()` function to generate unique keys based on a fixed directory path and a fixed identifier, ensuring that all modules locate the same shared memory region.

[0102] In a specific deployment embodiment of the system, the installation and configuration process of each module is executed in the following order. First, the installation script creates a system deployment directory under the specified path, including an executable file subdirectory, a data subdirectory, and a log subdirectory. Second, the installation script creates two FIFO named pipe files, stdin.fd and stdout.fd, in the executable file subdirectory using the mkfifo system call. Then, the installation script copies the compiled fifo_keeper, dpdk-testpmd, and dpdk-testpmd-cli executable files to the executable file subdirectory. Next, the installation script generates the daemon startup script and the CLI startup script and sets their executable permissions. Finally, the installation script generates the systemd service unit configuration file and installs it into the systemd service directory, performing configuration reloading and service startup operations.

[0103] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit described above can be implemented in hardware.

[0104] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A systemd service command-line interactive takeover method based on FIFO named pipes, characterized in that, include: Create input named pipes and output named pipes; The service process is started by a startup script. The startup script uses shell redirection to redirect the standard input of the service process to the input named pipe, and redirects the standard output and standard error of the service process to the output named pipe. The startup script starts the pipe holder process first, and then starts the service process. The pipe holder process keeps the read and write ends of the input named pipe and the output named pipe continuously open, and reads and discards the data in the output named pipe when no client connection is detected. The client opens the input named pipe in write mode and writes commands, and opens the output named pipe in read mode and reads responses, thereby enabling interactive communication with the service process.

2. The method according to claim 1, characterized in that, Starting the service process via the startup script includes: The startup script starts the pipe holder process in the background and the service process in the foreground. The service process runs in the foreground, allowing the system service manager to monitor its lifecycle and trigger an automatic restart when the service process exits. The shell redirection uses append mode to write the standard output to the output named pipe.

3. The method according to claim 1, characterized in that, The pipe holder process keeps the read and write ends of the input named pipe and the output named pipe continuously open, including: Multiple threads are created to open the input named pipe in read-only mode and write-only mode respectively, and the output named pipe is opened in read-only mode and write-only mode respectively. By executing multiple threads in parallel, the blocking characteristic of the two ends of the named pipe is overcome.

4. The method according to claim 1, characterized in that, The pipe retainer process detects client connection status including: The process identifier of the client is obtained through a shared memory region, and the client is determined to be in a connected state by checking whether the process corresponding to the process identifier is alive. When the process identifier is zero or the process corresponding to the process identifier no longer exists, it is determined that there is no client connection.

5. The method according to claim 4, characterized in that, When the pipe holder process reads and discards data in the output named pipe, the method further includes: Set the non-blocking flag at the read end of the output named pipe; It performs periodic readings at fixed intervals, reading and discarding data immediately when there is data in the pipeline, and returning immediately without blocking when there is no data in the pipeline.

6. The method according to claim 4, characterized in that, The method further includes: When the client starts, it writes its own process identifier into the shared memory area; The client clears the historical residual data in the output named pipe in a non-blocking manner and then enters the interactive loop.

7. The method according to claim 1, characterized in that, The method further includes: The client trims and reuses the line editing engine, command parsing framework, and history function from the command-line parsing library used by the service process; The client changes the input / output layer to communicate via the input named pipe and the output named pipe.

8. The method according to claim 1, characterized in that, After writing a command to the input named pipe, the client reads response data from the output named pipe and continues reading for a preset timeout period until no new data arrives, at which point it returns to the command prompt.

9. A systemd service command-line interactive takeover system based on FIFO named pipes, characterized in that, include: The pipe module includes input named pipes and output named pipes; The service startup module includes service unit configuration and startup script. The startup script starts the pipe retainer process and the service process, and connects the standard input and output of the service process to the pipe module through shell redirection. The pipe retainer module is used to keep the read and write ends of each pipe in the pipe module continuously open, detect the client connection status, and read and discard the data in the output named pipe when there is no client connection. The client module enables interactive communication with the service process by sending commands through the input named pipe and receiving responses through the output named pipe.

10. The system according to claim 9, characterized in that, The pipe retainer module and the service startup module are configured to start automatically with the system service manager. The pipe retainer module continues to maintain pipe availability after the service process crashes and restarts, making the service restart transparent to the client module.

Images