Years ago, I had a problem keeping a long-running rsync process alive longer than ~2 hours between two ReadyNAS boxes. Many suggested fixes were offered by peers, and I did a lot of my own research. It didn’t appear to be a problem with the ssh tunnel, since I could keep ssh open and idle for a whole day. I even upgraded the NAS boxes to DiskStations improve the situation a bit, as the faster CPUs were able to do more of the CPU-bound work in the ~2 hours of life the process had. Still, I kept hitting the limits of my setup, and I had to prune out old backup directories more often than I liked.
I recently came across a stackoverflow post where someone casually mentioned to check logrotate. I dismissed this, of course – logrotate was working fine on my rsync logs in /var/log.
But I kept revisiting it. Why did they suggest looking at logrotate? On a whim, I tried moving the rsync logging out of /var/log. That alone fixed the problem. My rsync process now runs until it’s done! Somehow, logrotate was configured on my DiskStation to kill off rsync periodically so that it could perform its log-rotating duties. It’d be a rabbit hole to explore exactly why or how this happened – I’m just happy that it’s working now 🙂
If you’re having trouble with long-running rsync processes, definitely give this a try.
My Samsung TV is two years too old to receive automation commands over the LAN. Otherwise, my entire home theater experience is automated in openHAB, including my Yamaha receiver, my Tivo, and my Roku.
I was lamenting this to Noah Ternullo, and he said I could wire up an IR blaster. “Yeah,” I thought, “but that’s going to be really annoying.” It turned out to be really easy.
I already had this IR LED board from a previous project that used an Arduino, but I wanted it to work on a Raspberry Pi instead. I followed this writeup on how to configure LIRC on a Raspberry Pi to work with an IR LED driven by a GPIO pin. I gave my LED board 5V and GND and fed a control pin to it. Then I found a contributed lircd.conf for a very similar remote to my Samsung TV remote.
It uses the powerful exec binding to invoke a command from my openHAB server to the Pi. Now I have a power toggle for the TV. I put the private SSH key in /root/.ssh/ on the openHAB server and put the public key in /home/pi/.ssh/authorized_keys on the Pi to facilitate a passwordless connection.If you do this sort of thing yourself, remember that this is just a toggle. openHAB doesn’t really know if the TV’s on or off. In my case, I infer the TV’s state from the state of virtual buttons that I use to start or stop my media experience.
The minimum specs they announced for Android One are surprisingly good. I think this effort will do for phones what the Raspberry Pi did for embedded systems: In the blink of an eye, the mobile industry will have to deliver much more capability for much less cost, or they’ll lose business to the low-cost offerings. This has already happened in the embedded system industry, in that any “PC board” that costs more than the Pi must set itself apart somehow, either in terms of performance or capability.
They’ve also done a great service for developers. While it’s always been possible to start developing Android apps using just the emulators (as I did in early 2009), some things are easier to test on real hardware. Well, the cost of real hardware just dropped from $350 (Nexus line) to $105.
I try to figure things out. Sometimes this leads to a thought. Sometimes I write it down.
Bad Behavior has blocked 318 access attempts in the last 7 days.