systemctl (Fedora 17) and interacting spawned processes's consoles

Question

Introduction

I've recently upgraded to Fedora 17 and I'm getting used to the newer systemctl daemon manager versus shell init scripts.

A feature I need on some of my daemons is the ability to interact with their consoles because unclean shutdowns not initiated by the process itself can cause database corruption. So, performing a systemctl stop service-name.service for example might cause irreversible data loss.

These consoles read user input through stdin or similar methods, so what I've been doing on my old OS is to place those daemons foregrounded in a screen session, and I suspended that screen session with ^A ^z. It's also worth noting that I've now made systemctl do this automatically if the computer reboots, but it still doesn't solve my potential data corruption problem I'm trying to avoid.

---

My Question

Is there a way to use systemctl in order to directly interact with the console of processes it spawns? Can I hook a process through systemctl to get access to its console?

---

Thanks

You guys always give great answers, so I'm turning to you!

Answer 1

It looks like you might be able to redirect it to a tty.

StandardInput=

Controls where file descriptor 0 (STDIN) of the executed processes is connected to. Takes one of null, tty, tty-force, tty-fail or socket. If null is selected standard input will be connected to /dev/null, i.e. all read attempts by the process will result in immediate EOF. If tty is selected standard input is connected to a TTY (as configured by TTYPath=, see below) and the executed process becomes the controlling process of the terminal. If the terminal is already being controlled by another process the executed process waits until the current controlling process releases the terminal. tty-force is similar to tty, but the executed process is forcefully and immediately made the controlling process of the terminal, potentially removing previous controlling processes from the terminal. tty-fail is similar to tty but if the terminal already has a controlling process start-up of the executed process fails. The socket option is only valid in socket-activated services, and only when the socket configuration file (see systemd.socket(5) for details) specifies a single socket only. If this option is set standard input will be connected to the socket the service was activated from, which is primarily useful for compatibility with daemons designed for use with the traditional inetd(8) daemon. This setting defaults to null.

Link to quote

Oh, and if that doesn't work, we'll do something really complicated with Unix sockets that I'm sure you'll love.

Screw that nonsense, try something like this if the above isn't acceptable:

You could try writing to it's /proc pid directory. Say your daemons' pid is 2000, try writing to /proc/2000/fd/0

source

You could add that line to ExecStop=, which frees you from having to interact manually whatsoever.