Mam następujący problem, który zrekonstruowałem w tych dwóch mini skryptach perla. Jest to główny scenariusz:Wysyłanie sygnału do skryptu Perl podczas zamykania uchwytu pliku
#!/usr/bin/perl
$SIG{INT} = \&signal_handler_one;
open(my $pipe, "|-", "/home/pa/Desktop/POC2");
close $pipe;
sub signal_handler_one{
print "This is expected to print\n";
}
Na trzeciej linii otwiera rurę do tego skryptu:
#!/usr/bin/perl
$SIG{INT} = \&signal_handler_two;
sleep(10);
sub signal_handler_two{
print "This isn't expected to print\n";
}
Problem polega na tym, że gdy zacznę pierwszy scenariusz, a następnie wysłać SIGINT do niego podczas to zamyka rurę na linii 4, signal_handler_two jest odpalane zamiast signal_handler_one. Dlaczego tak się zachowuje? Czy jest jakiś sposób obejścia tego (moim celem jest uzyskanie signal_handler_one do wykonania).
Edit: pierwotnie wysłany sygnał na terminalu używając Ctrl + C, co powoduje „Nie należy oczekiwać, aby wydrukować” do wydrukowania. Ale kiedy wysyłam sygnał za pomocą kill do procesu nadrzędnego z innego terminala, po prostu go ignoruje.
Edycja 2: ostatecznie rozwiązać go nie używając otwarty dostać się do rury, ale przez ręczne rozwidlone, execing a następnie czeka na dziecko zamiast po prostu wywołanie blisko . Teraz wszystko działa dobrze. Wygląda na to, że to zachowanie było specyficzne dla mojego środowiska, ale jeśli ktoś mógł odtworzyć ten sam błąd, proszę dać mi znać.
Więc drugi skrypt to "POC2"? Jak dokładnie wysłać sygnał? Skąd wiesz, że to jest, gdy pierwszy skrypt zamyka rurę? – Borodin
Wysyłam go przez Ctrl + C na terminalu. Zamknij bloki wywołania, dopóki drugi proces nie zostanie zakończony, więc mam 10-sekundowe okno do wysłania Ctrl + C we właściwym czasie. Tak, POC2 to drugi skrypt. – Void
Myślę, że przekonasz się, że Ctrl-C wysyła sygnał do ostatnio aktywnego procesu. Możesz być bardziej selektywny, pobierając pierwszy proces, aby zgłosić swój PID za pomocą 'print" $$ \ n "', a następnie 'kill -s INT 1234' w linii poleceń, zastępując' 1234' aktualnym PID – Borodin