Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


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?


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

share|improve this question
In general, init scripts are not meant to be interactive. A better approach would be to make systemctl stop send a signal to the daemon telling it to shut itself down cleanly. – mattdm Sep 23 '12 at 0:15
up vote 1 down vote accepted

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


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


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

share|improve this answer
I think that this is a very clever work-around for my problem. – Sean Sep 21 '12 at 5:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .