• Posts
  • RSS
  • ◂◂RSS
  • Contact

  • I Like Upstart

    February 11th, 2015
    tech  [html]
    Recently it's been fashionable to complain about all the ways modern Unix has lost its way, departing from the true path of System V. Reading along without any experience in the tools I wasn't too sure; people often build things that are too complex, but people also don't usually rebuild core parts of operating systems unless there are significant problems with the old system. I just set up an Upstart job, though, and I really like it.

    There's a bit of a gap between how a program is released by its developers and how its used by things that depend on it. Take uwsgi. [1] I build it and start it up following the instructions:

    ./configure
    make
    sudo make install
    uwsgi \
      --socket :7090 \
      --wsgi-file example.py
    
    Now uwsgi will listen on port 7090 and respond to requests by running a python program, example.py and returning the output.

    My webserver is configured with:

    location /wsgi {
      include uwsgi_params;
      uwsgi_pass 127.0.0.1:7090;
      pagespeed off;
    }
    
    So now when a request comes into the webserver for /wsgi/foo it gets forwarded to uwsgi and from there to example.py which knows how to handle it.

    This is all great, but then I log off. This kills uwsgi, and all my requests to /wsgi/foo start getting "backend not responding" errors. So how do I keep uwsgi running when I log off? I could use nohup, right?

    nohup uwsgi \
      --socket :7090 \
      --wsgi-file example.py &
    
    Now when I log off it keeps running; great! But what if I reboot the machine?

    The traditional answer is to write a script, /etc/init.d/uwsgi that's responsible for starting and stopping uwsgi, and restarting it if there's a problem. These scripts are mostly boilerplate, however, with /etc/init.d/foo almost identical to /etc/init.d/bar. So in Upstart you instead write a short config file, /etc/init/uwsgi.conf:

    description "uwsgi server"
    start on runlevel [2345]
    stop on runlevel [06]
    respawn
    exec uwsgi \
      --socket :7090 \
      --wsgi-file /path/to/example.py
    
    And run it with:
    sudo service start uwsgi
    
    which will automatically happen on restart. [2]

    This is so much better! Simple, short, you just write what you need.

    (While the version of Ubuntu I'm running uses Upstart, the next version is planned to use systemd instead. While I haven't tried systemd, from looking at the docs it sounds like it also uses short declarative service configuration files.)


    [1] I don't mean to pick on uwsgi, and in fact they have pretty good documentation on how to manage it. Nginx would have been a better example here; when people want to install ngx_pagespeed it's often their first experience installing nginx from source, and the nginx docs here are kind of awkward. It's either "your distro will manage it" or "you should mostly know how to do this".

    [2] In the case of uwsgi it can handle some of these steps itself, so while the example I gave works you can do better; see the docs for uWSGI with Upstart.

    Comment via: google plus

    Recent posts on blogs I like:

    Who Should Bear the Risk in Infrastructure Projects?

    The answer to the question is the public sector, always. It’s okay to have private-sector involvement in construction, but the risk must be borne by the public sector, or else the private sector will just want more money to compensate for the extra risk. …

    via Pedestrian Observations November 30, 2020

    Fireside Friday, November 27, 2020

    Hey folks! Fireside this week. A bit of a change-up in terms of the coming attractions. I had planned to start “Textiles, How Did They Make It?” next, but I want to do a bit more reading on some of the initial stages of textile production (that is, the pr…

    via A Collection of Unmitigated Pedantry November 27, 2020

    Thoughts you mightn't have thunk about remote meetings

    Welcome to this week's edition of "building a startup in 2020," in which all your meetings are suddenly remote, and you probably weren't prepared for it. I know I wasn't. We started a "fully remote" company back in 2019, but …

    via apenwarr November 23, 2020

    more     (via openring)


  • Posts
  • RSS
  • ◂◂RSS
  • Contact