When a barman calls 'time' at the pub, they are letting you finish your drink. Unfortunately the standard command to pull down Nginx on Ubuntu Precise is a little more aggressive. When it calls time, it snatches your unfinished beer away right there and then.
Thankfully there's a really simple way to socialise Nginx. It is by calling the nginx server command directly with the -s argument instead of using the /etc/init.d/nginx or service nginx commands.
_-s_ lets you send signals to the Nginx master process and Nginx behaves differently whether it receives a quit signal versus a term signal.
# terminate the nginx master process immediately
$ sudo nginx -s stop
# terminate the nginx master process once all outstanding connections have been completed
$ sudo nginx -s quit
$ abonner@avalanche:~$ ps aux | grep nginx
root 1063 0.0 0.0 88796 3432 ? Ss Jan21 0:00 nginx: master process /usr/sbin/nginx
www-data 9786 1.3 0.0 91564 7352 ? S Feb03 190:11 nginx: worker process is shutting down
www-data 9788 1.3 0.0 91288 7072 ? S Feb03 189:02 nginx: worker process is shutting down
www-data 9789 1.3 0.0 91160 6956 ? S Feb03 190:03 nginx: worker process is shutting down
Let you visitors finish their drink, don't terminate nginx on a production server using /etc/init.d/nginx stop or service nginx stop.
Read more about Nginx's command line options
If for some reason you have forgotten the root password for an existing mysql installation you can recover the account by starting mysqld with the --skip-grant option. This is roughly analogous to starting a Unix system in single user mode.
First thing, shut down the running instance and then restart it directly
$ sudo -u <mysql_user> mysqld_safe --skip-grant-tables --skip-networking
The --skip-networking option is important, as by skipping the grant tables, any user can connect to the running mysqld service, will full permissions.
Once you've started the server up, login without a password, and issue an update query to the mysql.user table.
$ mysql -uroot mysql
mysql> UPDATE user SET password=password('newpassword') WHERE User = 'root'
Close down mysqld and restart. You're good to go.
I get really frustrated with Ruby packages, they promise so much and when on that special day the moon is aligned with Mars, it all just works, and life is great.
Unfortunately this doesn't happen very often and when using a stack of Rubygems, you almost always get bitten by something.
My cause for complaint today is Vagrant and Chef, well specifically Chef Solo. Vagrant is fine, it does what you tell it to do, but for most use-cases Chef Solo is the right tool to use for provisioning your virtual server. The Vagrant docs on Chef Solo unfortunately fib you, they say you can use Data Bags with Chef Solo, but by default you cannot.
This is a big deal as many useful Chef recipes make heavy use of Data Bags. Data Bags which let you provide environment specific configuration for your provisioning is not yet supported by the stock Chef Gem (currently version 10.12.0). In order to make use of Data Bags with Chef Solo, you need version 10.14.0 and above. This means building the gem from source.
I use Veewee to build my vagrant base boxes (you should too, it's awesome!), and you can edit the postinstall.sh file in your box definition folder to build Chef from source, rather than installing it directly via Rubygems.
You can repeat this for your local dev machine, and now you can get Chef Solo cooking up your recipes and happily using data bags.