Изглежда, че се опитвате да стартирате продължителни процеси от уеб сървър и след това да проследявате тези процеси в база данни. Това не е невъзможно, но не е препоръчителна практика.
Основният проблем е, че HTTP заявка трябва да се обработва в момента във вашия уеб сървър, за да го направите, за да правите всичко (включително проследяване на процеси, изпълнявани в системата) - имате нужда от нещо, което може да работи през цялото време...
Вместо това, по-добра идея би била да има друг демонизиран процес на "мениджър" (както споменавате perl, това би било добър език за писане на него) да създава и проследява дълго изпълняваните задачи (чрез PID и сигнали) и за това процес за актуализиране на вашата SQL база данни.
След това можете да накарате вашия процес на "мениджър" да слуша заявки за стартиране на нов процес от вашия уеб сървър. Има различни IPC механизми, които можете да използвате. (например:сигнали, SysV shm, unix домейн сокети, опашки в процес като ZeroMQ и т.н.).
Това има множество предимства:
- Ако вашите създадени скриптове трябва да се изпълняват с изолация, базирана на потребител/група (от системата или един от друг), тогава вашият уеб сървър не трябва да работи като root, нито да бъде setgid.
- Ако създаден процес се „срине“, до процеса „мениджър“ ще бъде доставен сигнал, за да може да проследява неправилно изпълнение без проблеми.
- Ако използвате опашки в процес (напр.:ZeroMQ) за доставяне на заявки до процеса на „мениджър“, той може да „задушава“ заявки от уеб сървъра (така че потребителите да не могат умишлено или случайно да причинят D.O.S).
- Независимо дали създаденият процес завършва добре или не, нямате нужда от „активна“ HTTP заявка към уеб сървъра, за да актуализирате вашата база данни за проследяване.
Що се отнася до това дали нещо, което трябва be run е бягане, това наистина зависи от вашата семантика. (т.е. базирано ли е на известно време на изпълнение? въз основа на изразходвани данни? и т.н.).
Проверка дали е бягането може да бъде двукратно:
- Процесът „мениджър“ актуализира базата данни според случая, включително създадения PID.
- Кодът, хостван от вашия уеб сървър, може всъщност да изброява процеси, за да определи дали PID в базата данни е всъщност тичане и дори колко време е правело нещо полезно!
Проверете дали не изпълнението трябва да се основава на конвенцията:
- Наименувайте създадените процеси нещо, което можете да предвидите.
- Вземете списък с процеси, за да определите какво все още работи (несъществуващо?), което не трябва да бъде.
И в двата случая можете или да информирате потребителите, които са поискали процесите да бъдат създадени, и/или всъщност да направите нещо по въпроса.
Един подход може да бъде да имате CRON задача, която чете от SQL базата данни и изпълнява ps за да определи кои възникнали процеси трябва да бъдат рестартирани и след това отново изисква процеса на "мениджъра" да го направи, използвайки същия IPC механизъм, използван от уеб сървъра. Как ще разграничите стартиранията от рестартирането във вашето проследяване/мониторинг/регистриране зависи от вас.
Ако самият сървър загуби захранване или се срине, тогава можете да накарате процеса "мениджър" да извърши почистване, когато се стартира за първи път, напр.:
- Потърсете записи в базата данни за създадени процеси, за които се твърди, че са се изпълнявали преди спирането на сървъра.
- Проверете за тези процеси по PID и време на изпълнение (това е важно).
- Или пуснете отново създадените процеси, които не са завършили, или запазете нещо в базата данни, за да посочите на уеб сървъра, че това е така.
Актуализация №1
Според вашия коментар ето някои насоки, за да започнете:
Споменахте perl, така че предполагайки, че имате известни познания там - ето някои Perl модули, които да ви помогнат по пътя към писането на скрипта на процеса "мениджър":
Ако все още не сте запознати с него CPAN е хранилището за Perl модули, които правят почти всичко.
Daemon::Daemonize - Да демонизира процеса, така че да продължи да работи след като излезете. Също така предоставя методи за писане на скриптове за стартиране/спиране/рестартиране на демона.
Proc::Spawn
- Помага при "зараждане" на детски скриптове. По принцип прави fork() след това exec() , но също така обработва STDIN/STDOUT/STDERR (или дори tty) на дъщерния процес. Можете да използвате това, за да стартирате вашите дългосрочни Perl скриптове.
Ако предния код на вашия уеб сървър все още не е написан на perl, ще ви трябва нещо, което е доста преносимо за предаване на съобщения между процесите и опашка; Вероятно бих направил предния край на вашия уеб сървър в нещо лесно за внедряване (като PHP).
Ето две възможности (има много още):
Proc::ProcessTable - Можете да използвате тази проверка при работещи процеси (и да получите всякакви статистически данни, както беше обсъдено по-горе).
Time::HiRes - Използвайте функциите за време с висока детайлност от този пакет, за да внедрите вашата рамка за 'дроселиране'. По принцип просто ограничете броя на заявките, които премахвате от опашката за единица време.
DBI (с mysql ) - Актуализирайте вашата MySQL база данни от процеса "мениджър".
