systemctl (Fedora 17) und die Interaktion der erzeugten Prozesskonsolen

814
Sean

Einführung

Ich habe kürzlich ein Upgrade auf Fedora 17 durchgeführt und gewöhne mich an den neueren systemctlDaemon-Manager gegenüber Shell-Init-Skripts.

Ein Feature, das ich für einige meiner Daemons benötige, ist die Möglichkeit, mit ihren Konsolen zu interagieren, da nicht sauberes Herunterfahren, das nicht vom Prozess selbst initiiert wird, die Datenbank beschädigen kann. Wenn Sie systemctl stop service-name.servicebeispielsweise ein Beispiel ausführen, kann dies zu irreversiblen Datenverlusten führen.

Diese Konsolen lesen die Benutzereingaben über stdin oder ähnliche Methoden. Was ich in meinem alten Betriebssystem getan habe, ist, diese Dämonen in einer screenSitzung in den Vordergrund zu stellen, und ich habe die Bildschirmsitzung mit angehalten^A ^z . Es ist auch erwähnenswert, dass ich dies jetzt beim systemctlNeustart des Computers automatisch erledigt habe, aber es löst immer noch nicht mein potenzielles Datenbeschädigungsproblem, das ich zu vermeiden versuche.

Meine Frage

Gibt es eine Möglichkeit, systemctldirekt mit der Konsole von Prozessen zu interagieren, die sie erzeugt? Kann ich einen Prozess durchbinden systemctl, um auf seine Konsole zuzugreifen?

Vielen Dank

Ihr Jungs gibt immer großartige Antworten, also wende ich mich an Sie!

2
Im Allgemeinen sind Init-Skripte nicht interaktiv. Ein besserer Ansatz wäre, systemctl stop ein Signal an den Dämon senden zu lassen, der ihn dazu auffordert, sich sauber herunterzufahren. mattdm vor 12 Jahren 0

1 Antwort auf die Frage

1
0x90

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.

Ich denke, das ist eine sehr clevere Lösung für mein Problem. Sean vor 12 Jahren 1

Verwandte Probleme