Hello,
sorry, for 1 more question on CentOS 5 -> CentOS 6 migration.
On my old CentOS 5.7 machine I have the following line:
pref:3:respawn:/bin/su -c '/usr/local/pref/pref.pl >/tmp/pref-`date +%a`.txt 2>&1' afarber
and this has served me well, I don't want to install anything else like daemontools etc. - to keep my web-server easily reinstallable (or movable to another hoster).
But now I have migrated to CentOS 6.0, added that line and the "init q", but nothing happens - as indeed promised by the comments in the new /etc/inittab.
Where should I move my line, which docs to read?
The pref.pl is a poll()ing TCP-sockets daemon for a game
Thank you Alex
On Tue, Oct 4, 2011 at 5:44 PM, Alexander Farber alexander.farber@gmail.com wrote:
Hello,
sorry, for 1 more question on CentOS 5 -> CentOS 6 migration.
On my old CentOS 5.7 machine I have the following line:
pref:3:respawn:/bin/su -c '/usr/local/pref/pref.pl >/tmp/pref-`date +%a`.txt 2>&1' afarber
and this has served me well, I don't want to install anything else like daemontools etc. - to keep my web-server easily reinstallable (or movable to another hoster).
But now I have migrated to CentOS 6.0, added that line and the "init q", but nothing happens - as indeed promised by the comments in the new /etc/inittab.
Where should I move my line, which docs to read?
The pref.pl is a poll()ing TCP-sockets daemon for a game
Thank you Alex
This sounds like something you should be using the 'service' framework for, instead of inittab. In CentOS 5 you would create a script in /etc/init.d and start the service from there. I'm not yet familiar with CentOS 6, but I would bet looking for docs on how to do that will lead you in the right direction.
-☙ Brian Mathis ❧-
On Oct 4, 2011 5:45 PM, "Alexander Farber" alexander.farber@gmail.com wrote:
Where should I move my line, which docs to read?
Like recent Ubuntus, C6 uses upstart in place of traditional Sys V init.
Likely, you will want this in /etc/init/ -- note!, not the same as /etc/init.d/
johnny
On Tue, 4 Oct 2011, Johnny Tan wrote:
Like recent Ubuntus, C6 uses upstart in place of traditional Sys V init.
Likely, you will want this in /etc/init/ -- note!, not the same as /etc/init.d/
I don't know WHAT you are looking at, if anything, but it is not a CentOS 6 install; 'upstart' is a non-starter for the future, and certainly not in CentOS' upstream's plans
[root@centos6-32 ~]# rpm -qa sys* sysvinit-tools-2.87-3.dsf.el6.i686 system-config-firewall-base-1.2.27-3.el6_0.2.noarch [root@centos6-32 ~]# cd /etc/init.d/ [root@centos6-32 init.d]# ls atd crond iptables netfs rsyslog single udev-post auditd functions killall network sandbox snmpd cgconfig halt named rdisc saslauthd snmptrapd cgred ip6tables netconsole restorecond sendmail sshd [root@centos6-32 init.d]# ls -al ../rc* -rwxr-xr-x. 1 root root 2617 Jun 25 00:07 ../rc -rwxr-xr-x. 1 root root 220 Jun 25 00:07 ../rc.local -rwxr-xr-x. 1 root root 19088 Jun 25 00:07 ../rc.sysinit
../rc0.d: total 8 drwxr-xr-x. 2 root root 4096 Oct 3 12:27 . drwxr-xr-x. 10 root root 4096 Aug 18 07:03 .. lrwxrwxrwx. 1 root root 13 Oct 3 12:02 K05atd -> ../init.d/atd lrwxrwxrwx. 1 root root 19 Oct 3 12:02 K10saslauthd -> ../init.d/saslauthd lrwxrwxrwx. 1 root root 14 Oct 3 12:02 K25sshd -> ../init.d/sshd lrwxrwxrwx. 1 root root 18 Oct 3 12:02 K30sendmail -> ../init.d/sendmail lrwxrwxrwx. 1 root root 20 Oct 3 12:02 K50netconsole -> ../init.d/netconsole lrwxrwxrwx. 1 root root 15 Oct 3 12:02 K50snmpd -> ../init.d/snmpd ...
-- Russ herrold
Hello,
unfortunately /etc/init.d doesn't seem to suit me:
I want my (sockets) script to be restarted when crashed or killed
(I kill it every night to solve memory issues with perl interpreter)
Regards Alex
On Wednesday 05 Oct 2011 07:04:36 Alexander Farber wrote:
unfortunately /etc/init.d doesn't seem to suit me:
I want my (sockets) script to be restarted when crashed or killed
It's not /etc/init.d but /etc/init. That's what upstart is for, by default it considers jobs to be services that need to be respawned if they exit. See also man init(5).
Upstart provides a compatibility interface for SysV so /etc/init.d is still there and used but this is not what you want.
On Wed, Oct 5, 2011 at 12:54 AM, R P Herrold herrold@owlriver.com wrote:
I don't know WHAT you are looking at, if anything, but it is not a CentOS 6 install; 'upstart' is a non-starter for the future, and certainly not in CentOS' upstream's plans
Yeah, about that. -> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Mig...
4.2 Service Initialization ->
"In Red Hat Enterprise Linux 6, *init* from the sysvinit package has been replaced with *Upstart*, an event-based init system. This system handles the starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running. For more information on Upstart itself, refer to the init(8) man page."
Upstart is very much a non-starter. It's already been replaced in recent fedora versions by systemd. HOWEVER, it's very much in RHEL6 and CentOS6.
While I don't think OP should necessarily be using inittab that way, there are certainly commercial pieces of software (I'm looking at YOU Tivoli Storage Manager!) that want to use inittab for keeping crash-prone things alive. /etc/init is the place for this, however the format is different... So OP is most likely going to need to rewrite things anyway.
Hello again,
I still have 1 minor problem -
I've created a new file /etc/init/pref.conf:
start on stopped rc RUNLEVEL=3 stop on starting rc RUNLEVEL=[!3] console output respawn chdir /tmp exec /bin/su -c '/usr/local/pref/pref.pl >/tmp/pref-`date +%a`.txt 2>&1' afarber
And started my script (a TCP-sockets daemon for a game) with
# sudo initctl start pref pref start/running, process 2590
I can also see it running with "ps uawx", "netstat -an" and
# sudo initctl status pref
But I can not restart it with:
# sudo initctl restart pref initctl: Unknown instance:
# sudo initctl stop pref initctl: Unknown instance:
Why so? I was hoping to use the last command in a nightly cronjob (I have to restart my script because of perl memory problems)
And also when I run
# sudo initctl start pref
several times, then I get
# sudo initctl status pref pref stop/waiting
- even though the process seems to run ok.
Thank you Alex
On Wednesday 05 Oct 2011 15:03:43 Alexander Farber wrote:
I still have 1 minor problem -
I've created a new file /etc/init/pref.conf:
start on stopped rc RUNLEVEL=3 stop on starting rc RUNLEVEL=[!3] console output respawn chdir /tmp exec /bin/su -c '/usr/local/pref/pref.pl >/tmp/pref-`date +%a`.txt 2>&1' afarber
And started my script (a TCP-sockets daemon for a game) with
# sudo initctl start pref pref start/running, process 2590
I can also see it running with "ps uawx", "netstat -an" and
# sudo initctl status pref
But I can not restart it with:
# sudo initctl restart pref initctl: Unknown instance:
# sudo initctl stop pref initctl: Unknown instance:
Does your pref.pl fork or daemonize itself? You may need to add 'expect fork' or 'expect daemon' to your pref.conf. Is the PID you get from `status pref' the same as you see in ps output?
Hello Michael and others -
On Wed, Oct 5, 2011 at 5:42 PM, Michael Gliwinski Michael.Gliwinski@henderson-group.com wrote:
On Wednesday 05 Oct 2011 15:03:43 Alexander Farber wrote:
start on stopped rc RUNLEVEL=3 stop on starting rc RUNLEVEL=[!3] console output respawn chdir /tmp exec /bin/su -c '/usr/local/pref/pref.pl >/tmp/pref-`date +%a`.txt 2>&1' afarber
# sudo initctl stop pref initctl: Unknown instance:
Does your pref.pl fork or daemonize itself? You may need to add 'expect fork' or 'expect daemon' to your pref.conf. Is the PID you get from `status pref' the same as you see in ps output?
No, it doesn't daemoniz or fork anything and prints stuff to stdout and stderr only - because I was running it with /etc/inittab on the CentOS 5.7 (and thus shouldn't daemonize).
The pid doesn't match or I can't get it:
(I've omitted "sudo " below, I use CLI as "afarber"):
# initctl status pref pref start/running, process 1507 # initctl restart pref pref start/running, process 2083 # initctl restart pref initctl: Unknown instance: # initctl restart pref initctl: Unknown instance:
# ps uwx USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND afarber 1532 0.0 0.0 108788 15084 ? S 16:05 0:00 /usr/bin/perl -w /usr/local/pref/pref.pl
# netstat -an | grep -w 8080 tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN
# initctl status pref pref stop/waiting
Any ideas please?
I've also added more details at http://serverfault.com/questions/318742/etc-inittab-respawn-script-migrating...
Thank you Alex
My script has 2 pecularities:
1) When it gets SIGTERM or SIGINT, it writes some data into PostgreSQL and this takes 10-15 seconds
2) When it is started numerous times, then the subsequent runs will fail immediately, because only the 1st instance will be able to listen at the TCP-port 8080
And in /var/log/messages I see:
... 17:44:25 static init: pref main process ended, respawning 17:44:26 static init: pref main process (2128) terminated with status 98 17:44:26 static init: pref main process ended, respawning 17:44:26 static init: pref main process (2133) terminated with status 98 17:44:26 static init: pref respawning too fast, stopped
is that all maybe the reason and is there something I could do? (maybe somehow delay the subsequent spawns?)
Regards Alex
On Wed, Oct 5, 2011 at 5:51 PM, Alexander Farber alexander.farber@gmail.com wrote:
http://serverfault.com/questions/318742/etc-inittab-respawn-script-migrating...
On Wed, Oct 5, 2011 at 12:04 PM, Alexander Farber alexander.farber@gmail.com wrote:
My script has 2 pecularities:
- When it gets SIGTERM or SIGINT, it writes some data into PostgreSQL
and this takes 10-15 seconds
- When it is started numerous times,
then the subsequent runs will fail immediately, because only the 1st instance will be able to listen at the TCP-port 8080
And in /var/log/messages I see:
... 17:44:25 static init: pref main process ended, respawning 17:44:26 static init: pref main process (2128) terminated with status 98 17:44:26 static init: pref main process ended, respawning 17:44:26 static init: pref main process (2133) terminated with status 98 17:44:26 static init: pref respawning too fast, stopped
is that all maybe the reason and is there something I could do? (maybe somehow delay the subsequent spawns?)
Can you make it sleep a bit and retry the socket open a few times if it fails due to the previous process not releasing the port yet?
Good idea, thank you!
On Wed, Oct 5, 2011 at 7:22 PM, Les Mikesell lesmikesell@gmail.com wrote:
Can you make it sleep a bit and retry the socket open a few times if it fails due to the previous process not releasing the port yet?
Les Mikesell wrote:
On Wed, Oct 5, 2011 at 12:04 PM, Alexander Farber alexander.farber@gmail.com wrote:
My script has 2 pecularities:
- When it gets SIGTERM or SIGINT, it writes some data into PostgreSQL
and this takes 10-15 seconds
- When it is started numerous times, then the subsequent runs
will fail immediately, because only the 1st instance will be able to listen at the TCP-port 8080
<snip> Ok, here's an option: change it to perl, and make it a multithreaded process, so that it can wait at the critical point.
fork do stuff that doesn't need the port if child, exit if parent if #0 ended, fork #2 else loop
mark
On Wednesday 05 Oct 2011 18:04:08 Alexander Farber wrote:
My script has 2 pecularities:
- When it gets SIGTERM or SIGINT, it writes some data into PostgreSQL
and this takes 10-15 seconds
- When it is started numerous times,
then the subsequent runs will fail immediately, because only the 1st instance will be able to listen at the TCP-port 8080
And in /var/log/messages I see:
... 17:44:25 static init: pref main process ended, respawning 17:44:26 static init: pref main process (2128) terminated with status 98 17:44:26 static init: pref main process ended, respawning 17:44:26 static init: pref main process (2133) terminated with status 98 17:44:26 static init: pref respawning too fast, stopped
is that all maybe the reason and is there something I could do? (maybe somehow delay the subsequent spawns?)
To solve this problem you can add 'kill timeout 30' to pref.conf, this basically tells upstart that a process may take up to 30 seconds to exit after SIGTERM, and only if it doesn't exit after that it will send SIGKILL.
But as for the issue of why upstart is not picking up the PID correctly, I'm not sure yet. I'm actually dealing with similar issue now so I'll post more when I find something.
BTW, just noticed you're using su -c to run the program. I think this spawns a shell which may be the cause. Could you add 'expect fork' to pref.conf and see if it changes anything?
--On Wednesday, October 05, 2011 7:32 AM -0500 Jim Perrin jperrin@gmail.com wrote:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/ Migration_Planning_Guide/index.html
4.2 Service Initialization ->
"In Red Hat Enterprise Linux 6, *init* from the sysvinit package has been replaced with *Upstart*, an event-based init system. This system handles the starting of tasks and services during boot, stopping them during shutdown and supervising them while the system is running. For more information on Upstart itself, refer to the init(8) man page."
For those wanting to get their head around Upstart, start here:
-
Alexander Farber -
Brian Mathis -
Jim Perrin -
Johnny Tan -
Kenneth Porter -
Les Mikesell -
m.roth＠5-cent.us -
Michael Gliwinski -
R P Herrold