Showing posts with label upstart. Show all posts
Showing posts with label upstart. Show all posts

Sunday, September 14, 2014

Minecraft server upstart script

I see a lot of people running minecraft server in strange ways: nohup, bg & disown, tmux, screen, etc. The problem with those options is that they are all ephemeral. If you restart your server you'll need to do it all over again.

Here's a simple upstart script that starts and watches your minecraft server. It runs as a service and works for centos 6.5+ and ubuntu 12.04+

Once you create the file at /etc/init/minecraft.conf, simply run:

initctl reload-configuration
service minecraft <start|stop|status>

upstart script:
# Minecraft upstart script

start on (local-filesystems and net-device-up IFACE!=lo)
stop on [!12345]

respawn

chdir SOME_MINECRAFT_DIRECTORY

exec java -Xmx1024M -Xms1024M -jar minecraft_server.1.8.jar nogui

Logs for the server will be rotated by the server and are available at /var/log/upstart/minecraft.log

Friday, February 14, 2014

Move over upstart and make way for systemd

Earlier this week the Debian technical committee voted to make systemd the default init system for Debian. It was a nail-biter to follow, and it essentially came down to a tie-breaker vote cast by Bdale Garbee.

The result is clear: systemd will be the default init system for Debian -- and also Ubuntu -- going forward.

Mark Shuttleworth of Canonical confirmed Ubuntu's decision to follow suit in a blog post called "Losing Graciously". No drama, no attempt to revote or repeal the vote.

If only politics worked that smoothly.

Now it's time to familiarize yourself with systemd. I recommend you start writing all future init scripts in systemd.

The time frame for obsolescence of upstart and sysVinit is unclear for Ubuntu, but I predict around 7 years, so you have time to migrate.

Here's how I got that number (remember that odd number of releases are 2 year support):

13.04 is already out and obviously not part of the decision
14.04 is too far into the development stages
15.04 nobody will use because it's not "true" LTS
16.04: the only logical next release to enforce this decision.

I'll be writing more about systemd in the future. First I'm going to begin my own conversation from upstart so I can figure out how to use the dang thing. I'm glad that now I can write a service that will work across multiple distros.

Sunday, May 26, 2013

varnish and varnishncsa init (upstart) script

Here is a simple upstart script for the varnish and varnishncsa daemon. As of 3.0.3 upstart scripts aren't included in the standard debian package.

Nothing too fancy here. I'm going to be referencing these upstart scripts when I talk about plugging in logstash to varnishnicsa in another post. The real beauty is you get to hook varnishncsa into starting and stopping with varnish starts and stops.

varnish init (upstart) script:

# varnish - HTTP accelerator   
#   
     
description  "load balancer for Python api workers"   
     
start on (local-filesystems   
   and net-device-up IFACE!=lo)   
stop on runlevel[!2345]   
     
respawn   
     
# These are from the default init.d script   
limit nofile 131072 131072   
limit memlock 82000 82000   
     
exec "/usr/sbin/varnishd -F -a :80 -T localhost:6082 \   
   -f /etc/varnish/default.vcl -S /etc/varnish/secret \   
   -u varnish -g varnish -s malloc,256m" 

varnishncsa init (upstart) script:

# varnishncsa - Logging daemon for varnish  
#  
   
description   "logging daemon for varnish"  
   
env LOG_OPTIONS='%h %l %u %t "%r" %s %b %{Varnish:time_firstbyte}x %{Varnish:handling}x'  
start on started varnish  
stop on stopped varnish  
   
respawn  
   
exec /usr/bin/varnishncsa -a -F "$LOG_OPTIONS" -w /var/log/varnish/varnishncsa.log  

Remember that when you replace the init.d script with the upstart version you effectively deprecate the settings in /etc/defaults/varnish*, so you'll need to incorporate any of those configuration settings into these scripts.

You can test these settings by running:

 $ service varnish start  
   varnish start/running, process 13562  

And behold! It started both varnish and the varnishncsa logging daemon:

$ ps aux | grep varnish   
  root  13617 8.0 2.0 117236 84684 ?  SLs 19:13 0:00 /usr/sbin/varnishd -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -u varnish -g varnish -s malloc,256m   
  root  13618 0.0 0.0 93840 684 ?  Ss 19:13 0:00 /usr/bin/varnishncsa -a -F %h %l %u %t "%r" %s %b %{Varnish:time_firstbyte}x %{Varnish:handling}x -w /var/log/varnish/varnishncsa.log   
  varnish 13628 0.0 0.0 270936 1400 ?  Sl 19:13 0:00 /usr/sbin/varnishd -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -u varnish -g varnish -s malloc,256m  
   

If it looks funny to you that there are 2 varnishd programs running, don't forget that varnish intentionally spawns a child.

I hope that helps.