Cancelar un proceso en Linux con Kill desde C++

[planeta9999]

 

Sigo leyendo cosas, y mi duda es que comando usar para llamar al programa externo desde C++. Parece que hay tres formas de hacerlo.

1.- system
2.- popen
3.- fork + exec

Tendré que conectar el Raspberry y probarlo todo, es un proyecto que lo tenía medio dormido y ya toca retomarlo, pero ahora con una solución más racional.

Me ha parecido que incluso podría lanzar la reproducción de los videos en ventanas, o poder mezclar la reproducción de un video con texto.

[KILLERJC]

Tal ves esto te ayude a decidirte:

https://stackoverflow.com/questions/8538324/what-is-the-difference-between-popen-and-system-in-c

[Geo]

Sigo leyendo cosas, y mi duda es que comando usar para llamar al programa externo desde C++. Parece que hay tres formas de hacerlo.

1.- system
2.- popen
3.- fork + exec

Tendré que conectar el Raspberry y probarlo todo, es un proyecto que lo tenía medio dormido y ya toca retomarlo, pero ahora con una solución más racional.

Me ha parecido que incluso podría lanzar la reproducción de los videos en ventanas, o poder mezclar la reproducción de un video con texto.

Lo que entiendo es que quieres es cerrar una aplicación que está corriendo en el sistema pero no te importa tener mayor control sobre ella. Para ello basta lo que ya AcoranTf mencionó, pkill o killall te permiten matar todos los procesos con el nombre que indiques, así tengas una, dos o más instancias del mismo proceso con esos comandos cerrarás todas.

¿Cómo llamarlos desde tu aplicación? Basta con algo como:

Código: C

1. system("pkill nombre_proceso");
2. system("killall nombre_proceso");

Ahora, la función system() devuelve un entero que, generalmente, corresponde al código de salida devuelto por el comando que ejecutaste (en este caso sería lo que devuelva pkill/killall), por lo que también podrías hacer algo como esto para tener alguna noción de qué resultó de tu llamada a pkill/killall:

Código: C

1. #include <stdio.h>
2. #include <stdlib.h>
3.  
4. int main(int argc, char* argv[]) {
5.     if (system("killall programa") == 0) {
6.         printf("programa estaba en ejecución, se cerró.");
7.     }
8.     else {
9.         printf("programa no está en ejecución.");
10.     }
11.  
12.     return 0;
13. }

Los valores que devuelve system generalmente corresponden a lo que devolvió el programa al terminar (p. ej. el return 0; al final del programa de ejemplo).

En cuanto a popen, te sería útil en caso de que quieras mayor control sobre las aplicaciones externas que estás ejecutando desde tu programa, por ejemplo, si la aplicación externa te devuelve algún texto en cierto formato, para recibir dicho texto puedes utilizar popen (system solamente devuelve un número). Para una aplicación que hice hace ya varios años utilizo precisamente esta opción para comunicarme con un reproductor de videos y obtener algunos datos que el reproductor proporciona (tiempo de avance de la reproducción, p. ej.).

Un ejemplo llamando a mkdir:

Código: C

1. #include <stdio.h>
2. #include <stdlib.h>
3.  
4. int main(int argc, char* argv[]) {
5.     if (system("mkdir dirtest") == 0) {
6.         printf("Se creó dirtest");
7.     }
8.     else {
9.         printf("No se creó dirtest.");
10.     }
11.  
12.     return 0;
13. }

Si no existe el directorio dirtest, la primera vez que ejecutas este programa, la salida sería esta:
$ ./creadirtest
Se creó dirtest

Pero si lo ejecutas una segunda vez (con el directorio ya creado):
$ ./creadirtest
mkdir: cannot create directory ‘dirtest’: File exists
No se creó dirtest.

Puedes observar que la salida de mkdir se mezcló con la de nuestro programa. Desde nuestro programa solamente sabemos que no obtuvimos una salida en 0, por lo que imprimimos que no se creó el directorio, pero no tenemos acceso al texto de salida de mkdir (mkdir: cannot create directory ‘dirtest’: File exists), para poderlo obtener en tu código tendrías que hacer uso de popen, aunque creo que no lo necesitas para lo que has comentado.

[planeta9999]

Lo que entiendo es que quieres es cerrar una aplicación que está corriendo en el sistema pero no te importa tener mayor control sobre ella. Para ello basta lo que ya AcoranTf mencionó, pkill o killall te permiten matar todos los procesos con el nombre que indiques, así tengas una, dos o más instancias del mismo proceso con esos comandos cerrarás todas.

Lo que he leído es que system es la menos segura de las tres opciones, y fork-exec* la mejor en ese sentido.

No es solo para lanzar el pkill, también para lanzar el programa que reproduce el video con el parámetro del video a reproducir. En principio no necesito control sobre la reproducción del video, solo arrancarlo y cancelarlo para reproducir otro.

Lo mejor será probarlo todo en el Raspberry, a ver que ventajas tiene cada uno.

[KILLERJC]

no te va a preocupar lo seguro a vos. Al menos si la unica forma de entrar al sistema es atraves de una SD.. Lo que si con system() vas a tener para mi un pequeño problema, ya Geo te lo dijo pero no tan directamente:

Ahora, la función system() devuelve un entero que, generalmente, corresponde al código de salida devuelto por el comando que ejecutaste (

Es decir la funcion system es bloqueante, y unicamente va a avanzar de alli luego de que esta salga o se detenga. Esto quiere decir que en el mismo programa no vas a poder iniciar y detener el proceso.

Por otro lado la opcion de fork+exec si no mal lei el PID de aquello ejecutado por el exec es el el mismo devuelto por el fork, por lo tanto es mas simple para vos.

tiras un fork. si es padre solamente lees las entradas  procedes a matar (Usando el PID que te dio el fork) o esperar el proceso hijo que termine.
en el proceso hijo ejecutas el video que deseas.

Un ejemplo mas grafico:
https://stackoverflow.com/questions/4204915/please-explain-the-exec-function-and-its-family

[planeta9999]

Es decir la funcion system es bloqueante, y unicamente va a avanzar de alli luego de que esta salga o se detenga. Esto quiere decir que en el mismo programa no vas a poder iniciar y detener el proceso.

Entonces no me vale para lanzar el video, solo para cancelarlo con pkill.

Cuando lanzo el video, el programa principal tiene que seguir funcionando mientras se reproduce el video. En este programa se chequean el estado de una matriz de señales que leo con varios expansores de puertos MCP23s17, y según esas señales se lanzan nuevos videos, siempre cancelando antes el que pueda estar ejecutándose.

Lo de fork-exec*, no lo entiendo muy bien todavía. Parece que el fork duplica el programa actual, osea mi programa principal, algo yo no necesito, y el exec sería el que realmente lanzaría el nuevo programa, el reproductor de video.

¿ Entonces puedo hacer un exec desde el programa principal para lanzar el reproductor de video, o es neceario el fork también ?.


Vaya lío, a ver si voy cazando conceptos:

1.- system: ejecuta un programa externo al principal, pero no deja seguir al programa principal hasta que acabe el programa llamado. No me vale para lanzar el reproductor de video, pero si para el pkill.

2.- Fork-exec*:  fork crea un duplicado del programa actual (el principal), y desde ambos (original y copia) se puede detectar si estás en el programa padre o en el hijo, si estás en el programa hijo, con un exec* lanzaría el reproductor de video. En cualquier caso, el programa principal sigue su curso independiente del programa externo a llamar. Me vale para lanzar el reproductor de video, pero creo que no sería una buena elección para lanzar el pkill, porque el programa principal no debe de lanzar un nuevo video hasta que se cancele el que está en curso.

3.- Popen: no se todavía como funciona. Y este es el que han utilizado en los fuentes de ejemplo en Python que he puesto, que hacen algo parecido a lo que yo quiero hacer.


exec replaces the current process with another one.
system runs another program, wait for its completion.
fork copies the current process; both the original and the copy continue from the same point.
pipe sets up a pipe between two handles.
syscall makes a low-level system call.

[Geo]

system si es bloqueante, pero puedes agregar el operador & al comando que quieres ejecutar para que corra en "background". Considero que system es más que suficiente si solo requieres iniciar/detener una aplicación.

Código: C

1. system("killall programa &");

¿El reproductor que pretendes iniciar/cerrar es una aplicación propia o algún reproductor ya existente?

[tsk]

No veo cual es el problema, aunque system bloquee, no bloquea el programa principal. En el siguiente ejemplo inicio y detengo vlc en varias ocasiones.  Aunque no es el mejor ejemplo con lo que respecta a un buen programa, y mucho menos está terminado, pero te da idea de una de las formas en que se puede hacer.

Código: C

1. #include <iostream>
2. using namespace std;
3.  #include <cstdlib>
4.  
5. #include <sys/types.h>
6. #include <sys/wait.h>
7. #include <signal.h>
8. #include <unistd.h>
9.  
10. int pid = -1;
11.  
12. static void fork_process(char *cmd)
13. {
14.         int process;
15.         process = fork();
16.         switch(process)
17.         {
18.                 case -1:
19.                         cout << "Error" << endl;
20.                         break;
21.                 case 0:
22.                         pid = process;
23.                         setpgid(getpid(),getpid());
24.                         system(cmd);  //Si termina la ejecución se le puede agregar algo para que se espere
25.                                               //como un while(1){} para esperar a que el Proceso padre lo mate
26.                         break;
27.                 default:
28.                         cout << "Master Created subprocess" << endl;
29.                         cout << process << endl;
30.                         pid = process;
31.                         break;
32.         }
33.  
34. }
35.  
36.  
37. int main()
38. {
39.                 int gpid, user_response;
40.                 signal(SIGCHLD, SIG_IGN); //Para evitar Zombies
41.                 gpid = getpid();
42.                 cout << gpid << endl;
43.                 //cout << "0 - Iniciar VLC\n1-Detener VLC\n";
44.                 while(1)
45.                 {
46.                         cout << "0 - Iniciar VLC\n1-Detener VLC\n";
47.                         cin >> user_response;
48.                         switch(user_response)
49.                         {
50.                                 case 0:
51.                                         fork_process("vlc");
52.                                         cout << "----------------"<< endl;
53.                                         cout << getpid() << endl;
54.                                         cout << pid << endl;
55.                                   cout << gpid << endl;
56.                                         break;
57.                                 case 1:
58.                                         cout << "Killing Process " << pid << endl;
59.                                         kill(-pid, SIGKILL);
60.                                         break;
61.                                 default:
62.                                         break;
63.  
64.                         }
65.                 }
66.                
67.         return 0;
68.  
69. }

Código: [Seleccionar]

$ ./a.out
4755
0 - Iniciar VLC
1-Detener VLC
0
Master Created subprocess
4756
----------------
4755
4756
4755
0 - Iniciar VLC
1-Detener VLC
VLC media player 2.1.6 Rincewind (revision 2.1.6-0-gea01d28)
[0x6f9118] main libvlc: Ejecutar vlc con la interfaz predeterminada. Use «cvlc» para usar vlc sin interfaz.
1
Killing Process 4756
0 - Iniciar VLC
1-Detener VLC
1
Killing Process 4756
0 - Iniciar VLC
1-Detener VLC
0
Master Created subprocess
4765
----------------
4755
4765
4755
0 - Iniciar VLC
1-Detener VLC
VLC media player 2.1.6 Rincewind (revision 2.1.6-0-gea01d28)
[0x745118] main libvlc: Ejecutar vlc con la interfaz predeterminada. Use «cvlc» para usar vlc sin interfaz.
1
Killing Process 4765
0 - Iniciar VLC
1-Detener VLC
^C

Otra es que separes los dos programas y los comuniques por medio de sockets o tuberías, además también podrías también hacer uso de librerías como libevent o libuv

[planeta9999]

system si es bloqueante, pero puedes agregar el operador & al comando que quieres ejecutar para que corra en "background". Considero que system es más que suficiente si solo requieres iniciar/detener una aplicación.

Código: C

1. system("killall programa &");

¿El reproductor que pretendes iniciar/cerrar es una aplicación propia o algún reproductor ya existente?

El reproductor de video es un programa mío en C++. Cuando lo lance, el programa principal debe de seguir funcionando, no puede quedar bloqueado hasta que termine el reproductor de video.

Probaré lo del &.

[planeta9999]

No veo cual es el problema, aunque system bloquee, no bloquea el programa principal. v

No entiendo esto. ¿ que es lo que bloquea system ?, ¿ si lanzo un programa con system, el programa principal sigue funcionando aunque no haya terminado el programa llamado ?.

El programa principal debe de seguir su curso, no se puede quedar parado hasta que termine el programa llamado (reproductor de video), eso no me serviría.

[KILLERJC]

No entiendo esto. ¿ que es lo que bloquea system ?, ¿ si lanzo un programa con system, el programa principal sigue funcionando aunque no haya terminado el programa llamado ?.

El programa principal debe de seguir su curso, no se puede quedar parado hasta que termine el programa llamado (reproductor de video), eso no me serviría.

Por eso mismo usa el fork. Para que el child se bloquee con el system, mientras que el parent sigue su curso.

[tsk]

El fork hace una copia del programa y lo pone en otro proceso hijo, por lo que tendrías dos programas similares corriendo en paralelo, así que aunque system o cualquier otro bloquee, este no va a producir ningún efecto en el flujo del programa padre.

Código: [Seleccionar]

Padre    Hijo
''
''
''fork()
''==========
''        ''
''        ''
''        ''
''        ''
''        ''
''        ''
''        ''
''        ''
V         V

En el ejemplo que te mostré, es lo que hace, el proceso Padre puede crear y matar a su hijo a placer. El proceso Hijo la única función que tiene es la de ejecutar VLC, mientras el padre se dedica a otras cosas.

Aquí un video para que lo veas en acción

El estado cuando se inicia el programa (./a.out)



El estado cuando el padre crea al hijo y el hijo ejecuta el vlc a través de system. Se pueden ver dos procesos llamados ./a.out más los procesos específicos del reproductor multimedia VLC.



Cuando el padre mata a su hijo de nueva cuenta regresa al estado como el que se muestra en la primera imagen

[tsk]

El reproductor de video es un programa mío en C++. Cuando lo lance, el programa principal debe de seguir funcionando, no puede quedar bloqueado hasta que termine el reproductor de video.

Ya que es tuyo el programa, entonces te convendría ver la posibilidad de sobrescribir los manejadores de señales e incorporarlos en tu diseño.

Si haces un kill -l vas a ver las señales que pueden recibir cualquier proceso

Código: [Seleccionar]

1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3
38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8
43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7
58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2
63) SIGRTMAX-1 64) SIGRTMAX

Las que conocemos principalmente son SIGINT (cuando presionamos Ctrl+C), SIGKILL, SIGTERM, e incluso están los SIGUSR1 y SIGUSR2 que son definidos por el usuarios. Pero podemos sobre escribir la acción, de la siguiente forma.

Código: C

1. #include <iostream>
2. using namespace std;
3. #include <cstdlib>
4. //#include <csignal>
5.  
6. #include <sys/types.h>
7. #include <sys/wait.h>
8. #include <signal.h>
9. #include <unistd.h>
10.  
11. void custom_signal_handler(int signum)
12. {
13.         cout << "Acabas de presionar Ctrl+C, entonces Adios" << endl;
14.         exit(0);
15. }
16.  
17. int main()
18. {
19.         //Asignamos nuestra propia funcion para terminar el proceso a la
20.         //hora de recibir un Ctrl+C
21.         signal(SIGINT,custom_signal_handler);
22.  
23.         cout << "Presiona Ctrl+C para terminar el programa" << endl;
24.         while(1)
25.         {}
26.  
27.         return 0;
28. }

Y su salida

Código: [Seleccionar]

$ ./signals
Presiona Ctrl+C para terminar el programa
^CAcabas de presionar Ctrl+C, entonces Adios

De igual forma si nos sabemos su PID, podemos mandarle la señal SIGNT por medio del comando kill (kill -2 PID) o a través de otro programa en C/C++



Así que puedes reescribir los manejadores para algunos de las señales (SIGUSR1, SIGUSR2) para que detenga la ejecución del video para que le de la oportunidad de leer algún valor que otro programa le envíe a través de una tubería para que cambie de video o que simplemente detenga la ejecución del mismo.

Por lo tanto puedes tener dos programas totalmente independientes, simplemente el programa que verifica el estado de las entradas le va a enviar las señales adecuadas al proceso del reproductor de vídeo, para que se detenga unos momentos a leer algo que le estas enviando, así te evitas el dichoso fork() y al no tener que cerrarse el reproductor de video podrías pensar en realizar transiciones más complejas(entre videos) de lo que podrías hacer con sólo cerrar y abrir de nuevo la aplicación.

------
Añado que aparentemente puedes enviar datos usando sigqueue. Nunca lo había visto pero podrías ser también prometedor

http://man7.org/linux/man-pages/man3/sigqueue.3.html

[planeta9999]

El fork hace una copia del programa y lo pone en otro proceso hijo, por lo que tendrías dos programas similares corriendo en paralelo, así que aunque system o cualquier otro bloquee, este no va a producir ningún efecto en el flujo del programa padre.

Me refería a un system desde el programa principal, sin hacer un fork, eso es lo que entendí que bloquearía el programa principal hasta que termine el programa llamado.


Otra técnica que he leído es crear un pipe, creo que es un canal de comunicación entre el programa principal y el llamado, desconozco si bidireccional o en un solo sentido.

Por ejemplo usando el video reproductor omxplayer, sería así.

1. Create fifo file ( i.e. mkfifo /dev/shm/buffer.fifo )
2. Let omxplayer read this ( omxplayer /dev/shm/buffer.fifo )
3. Use an other command line window to put data into the fifo. Examples:
cat FILE.mp4 > /dev/shm/buffer.fifo
nc -p 5001 -l > /dev/shm/buffer.fifo

[planeta9999]

Así que puedes reescribir los manejadores para algunos de las señales (SIGUSR1, SIGUSR2) para que detenga la ejecución del video para que le de la oportunidad de leer algún valor que otro programa le envíe a través de una tubería para que cambie de video o que simplemente detenga la ejecución del mismo.

Por lo tanto puedes tener dos programas totalmente independientes, simplemente el programa que verifica el estado de las entradas le va a enviar las señales adecuadas al proceso del reproductor de vídeo, para que se detenga unos momentos a leer algo que le estas enviando, así te evitas el dichoso fork() y al no tener que cerrarse el reproductor de video podrías pensar en realizar transiciones más complejas(entre videos) de lo que podrías hacer con sólo cerrar y abrir de nuevo la aplicación.

------
Añado que aparentemente puedes enviar datos usando sigqueue. Nunca lo había visto pero podrías ser también prometedor

http://man7.org/linux/man-pages/man3/sigqueue.3.html

El problema es que parar el vídeo desde dentro del programa de propio reproductor no es tan sencillo. Yo solo lo he conseguido, esperando a que al menos se reproduzcan 2 segundos de vídeo, pero esto varía según el tamaño del vídeo.

La reproducción del vídeo se hace en un bucle que lee los datos del fichero a trozos y va alimentando a la GPU en un proceso bastante complejo, apenas documentado y difícil de entender. No he conseguido salir al instante del bucle sin que la GPU se bloquee.

Sin embargo, espero que el Pkill al proceso del reproductor de video, no dejé colgada la GPU, si no tendré que meter un pequeño retardo, pero no quedaría tan bien, porque los videos deben de responder al instante en función de señales externas.