Something many people have to realize is that they are not using screen during long things like rsyncing 1 TB+ of data. Those of you that have yet to enjoy something so lovely, you should always run it in a screen session or in tmux, etc. If for some reason you are running a long command in a terminal and need to disconnect here’s a helpful hint using disown. While a command is running, hit `Ctrl+z` to suspend the foreground job and use `bg` to put it in the background. Now you can use disown %n. You can find out what n is by running `jobs`. Run `jobs` after you disown again to make sure the job is now being controlled by init or a simple ps aug | grep process.
Ran into an interesting problem this week with file descriptors and TCP sessions on a server in Ubuntu. Using God to monitor a process, I had god starting a process with:
w.start = "ulimit -c unlimited ; ulimit -n 500000 ; /usr/sbin/process /etc/process.conf
Built a new instance in AWS, bootstrapped the machine with Chef, attached the role to the machine, let chef-client do it’s thing and allow connections to it from devices. Next, god starts up and file descriptors aren’t changing correctly for that process and there are hundreds of thousands of connections are attempting to come up.
By default, processes spawned in Ubuntu had a limit of 1024 open files, but changing that limit via ulimit or by /etc/security/limits.conf had no effect. I discovered that changes in /etc/security/limits.conf (and subsequently /etc/pam.d/common-session ) are only applied to process spawned by a login shell. Programs that launch on startup via “upstart” do not get these limits applied to them. Thankfully, upstart provides the limit stanza that allows you to modify some of these parameters, including the maximum number of open files. To see the limits on process, grab its PID, and cat /proc/<>/limits
This will fix your woes:
limit nofile 100000 110000
Credit: http://bryanmarty.com/blog/2012/02/10/setting-nofile-limit-upstart/
I’m constantly learning new things about git and I ran across this lovely piece of love this morning:
Take a snapshot of your current working tree without removing the changes from your tree. This is handy for refactoring where you can’t quite fit what you’ve done into a commit.
Add this into ~/.gitconfig under aliases:
snapshot = !git stash save "snapshot: $(date)" && git stash apply "stash@{0}"
Running this:
$ git snapshot
Creates this stash:
stash@{0}: On feature/handy-git-tricks: snapshot: Mon Apr 8 12:39:06 BST 2013
And seemingly no changes to your working tree.
Credit: http://blog.apiaxle.com/post/handy-git-tips-to-stop-you-getting-fired/
Sometimes you just need to be dirty and run chef-client on every node attached to a Chef server.
knife ssh 'name:*' 'sudo chef-client'
Recently I ran into a problem. I had two git repositories for the same project. Both git repositories were diverged and had individual work and git trees. Quick and dirty way to get things from git B to git A and do a giant squashed commit to get it back into git A.
rsync -a -f”- .git/” -f”+ *” source/ dest/
This will copy everything BUT .git directories.
Git commit away!