a utility written using PSGI and Perl where the author lamented having to write additional scripts to ensure the services were running.
Same problem as with almost any setup where webserver and applications run on in different processes. PSGI is perl-specific, FastCGI is not. FastCGI keeps your application running in an isolated process, so crashing the webserver does not kill the application, and crashing the application does not kill the webserver. Getting the application process running is a problem.
You could start it manually. Every time your application crashes.
You could construct something crazy, involving hand-started scripts, cron jobs, and I don't know what else to start the application process.
Or you could make starting your application a problem for the operating system. After all, it is able to start the webserver without manual intervention, so it can do the same to your application. (With daemontools and runit, you simply need a shell script to invoke your application. With systemd, you write an INI-style configuration file to do the same job in a much more complicated way. With a classic init system, you set up a daemon by an init script, or invoke it directly from init. On Windows, you need to set up a service.)
Apache also offers mod_fcgid to manage your FastCGI application process(es) for you, instead of using operating system services. Other webservers might offer similar modules. This has the advantage that you don't need to keep the application process(es) running if there are no requests for them. The disadvantage is that they are not as isolated from the webserver as a process started as an independant daemon started by init, daemontools, runit, or systemd.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
karl@rantanplan:~/src/perl$ pm2 status --no-vizion --no-color
┌────┬────────────────────┬──────────┬──────┬───────────┬──────────┬──────────┐
│ id │ name │ mode │ ↺ │ status │ cpu │ memory │
├────┼────────────────────┼──────────┼──────┼───────────┼──────────┼──────────┤
│ 1 │ gizmo │ fork │ 0 │ online │ 0% │ 7.9mb │
│ 0 │ mredis │ fork │ 0 │ online │ 0% │ 3.5mb │
└────┴────────────────────┴──────────┴──────┴───────────┴──────────┴──────────┘
The process with id 1 is a Perl daemon.
| [reply]
[d/l] |
The ids don't seem to be Unix process ids, more like an internal array index. Why doesn't it report the true process ID?
The problem with all of those managing software is complexity and feature creep. A sane /sbin/init running as process 1 fits on a page of A4 paper, without resorting to unreadably small letters: Re^14: CPAN failed install
And I would prefer to have a tiny init, too stupid to crash. Why? Because if init crashes, you are f***ed. init MUST NOT CRASH. Adding a lot of dependencies adds a lot of ways to crash. init has one job, and it is in its name: It must initialize the system. Keeping it running is the job of other programs. These programs should not crash, but if they do, init will restart them.
Want to have some fun? Disturb the connection between systemd and dbus. Hope and pray that your data survives that: Re: How not to implement updaters. It is almost like hitting the reset button on a running system, but via SSH.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply] |
| [reply] |