1

I'm running Nginx, FCGI, and Request Tracker on a Debian Jessie server. Request Tracker is served by Nginx, but FCGI sits between them. The important thing is that the FCGI server sometimes fails, resulting in users of RT seeing a 502 error. The fix is simple enough, but only because I've done it countless times in the last month or so. If I'm not around and someone else has to restart the FCGI server, they may have difficulty. Plus, stopping and restarting the server is annoying, but you need to do it to apply changes to RT.

All that leads me to this: how can I best make the commands into an easier one? A script? A service, so it lives in /etc/init.d? Something else? I'm new to Debian, and Linux in general, so don't really know my options or how involved each might be. Here are the commands you have to issue:

netstat -antp | grep LIST | grep 12345

(This finds the FCGI server bound to port 12345, so I can get the PID. Say our PID is 8091.)

kill 8091
spawn-fcgi -u someUser -g someGroup -a 127.0.0.1 -p 12345 /opt/rt4/sbin/rt-server.fcgi

One important note here is that the netstat command could return nothing. If it does, the FCGI server has failed silently, so you skip the kill command and go right to the spawn-fcgi one. Otherwise, you keep the kill command in.

Ideally, I'd love to have start/stop/restart options for something like /etc/init.d/rt-fcgi-server. I have no idea what to do for killing the process, though, because of the need to find the PID first. I've thought about using a .pid file, but I don't know how to tell spawn-fcgi to use one and what to do with such a file even if I had it. I don't even know if it would do what I want (keep the PID so I could avoid using the netstat command).

I hope this is all making sense. I basically want to have one command, or something tied to /etc/init.d, to control the result of the spawn-fcgi command. I want non-root users, who know less about Linux than even I do, to be able to log in and run a single command, and I wouldn't mind a way to query the status of this process without using netstat, even if I don't have to get the PID to kill it. This way I can use something like Monit to auto-restart the server should it fail.

  • For init.d you can try something like this: drumcoder.co.uk/blog/2010/aug/04/debian-initd-script-fcgi – Paulo Almeida Oct 24 '16 at 18:07
  • This looks like what I'm after! If it works, I'll ask you to make your comment an answer so I can mark it. My only question is this "kill -HUP" command; I'm not clear on that option, and I can't find it online anywhere. Why does restart not simply call stop and then start? I'm also unclear on the "$1" thing, but am still researching that. – AH16 Oct 24 '16 at 19:17
  • Okay, it runs, at least echoing strings. I can't officially test it until tomorrow morning when no one is using the RT instance being hosted, but this looks good so far. Thanks! – AH16 Oct 24 '16 at 20:13
  • I forgot to say: this seems to work well. If you want to make your comment into an answer, I can mark it. – AH16 Oct 27 '16 at 13:05
0

I'm going to write this answer from a FreeBSD perspective, but it should be applicable to Linux and Debian ... package names and whatnot may change.

I was similarly displeased with spawn-fcgi. On FreeBSD, it has an rc.d script, but it doesn't obey rc.d rules (it can't "restart" for instance).

A the bottom of the spawn-fcgi manual, however, it mentions supervise. With some searching this revealed "daemontools" ... On FreeBSD, there were packages for daemontools and daemontools-encore. The -encore seemed to be newer and possessed more features, so I chose it. My version is 1.10_1 of daemontools-encore.

On FreeBSD, an rc.d script is provided for svscan. On FreeBSD this scans /var/service for sub-directories and runs a "supervise" for each one. I accepted this default configuration and put svscan_enable="YES" in /etc/rc.conf. For Linux, I don't know about the rc script, but it says /service is the default directory.

Inside /var/service, I created rt-fcgi and inside rt-fcgi I created run. "run" contains:

#!/bin/sh

spawn-fcgi -u www -g www -s /tmp/rt.sock -n -- /usr/local/sbin/rt-server.fcgi

Obviously, on linux, this needs to have the user and group you're using and the location of your rt-server.fcgi.

The svscan system seems to advertise the last few lines of error in a process title. There are other options. Mine looks like:

46495  -  IJ   0:00.01 /usr/local/bin/readproctitle service errors: ...tory (/var/run/rt44/data/gpg). GnuPG support has been disabled (/usr/local/lib/perl5/site_perl/RT/Config.pm:790)\n[52465] [Tue Mar  7 21:09:54 2017] [warning]: The requested port (443) does NOT match the configured WebPort (80).  Perhaps you should Set($WebPort, 443); in RT_SiteConfig.pm, otherwise your internal hyperlinks may be broken. (/usr/local/lib/perl5/site_perl/RT/Interface/Web.pm:1328)\n

... meaning I don'g have gnupg configured correctly. Seems like you might look for errors and whatnot there unless you configure the log for svscan.

This is a pretty heavy handed bit for one fcgi, but it's canned and it works. It deals with the script exiting for whatever reason, but it doesn't manage a PID file or the socket (other than creating the socket file).

I must say that I'm far more enamored with the WSGI standard than this mess.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.