gpsd stdout stderr silently killed by SELinux on Centos 7

Setting up gpsd with a new gps device, I usually run gpsd in the foreground with debug output so I can see if the gps is detected.

It looks like something like this:

[root@octobox3 gpsd]# gpsd -D99 -n -N /dev/ttyS0
gpsd:INFO: launching (Version 3.11~dev)
gpsd:IO: opening IPv4 socket
gpsd:SPIN: passivesock_af() -> 3
gpsd:IO: opening IPv6 socket
gpsd:SPIN: passivesock_af() -> 4
gpsd:INFO: listening on port gpsd
gpsd:PROG: NTPD shmat(0,0,0) succeeded, segment 0
gpsd:PROG: NTPD shmat(32769,0,0) succeeded, segment 1
gpsd:PROG: NTPD shmat(65538,0,0) succeeded, segment 2
gpsd:PROG: NTPD shmat(98307,0,0) succeeded, segment 3
gpsd:PROG: successfully connected to the DBUS system bus
gpsd:PROG: shmat() succeeded, segment 131076
gpsd:PROG: shared-segment creation succeeded,
gpsd:INFO: stashing device /dev/ttyS0 at slot 0
gpsd:INFO: opening GPS data source type 2 at '/dev/ttyS0'
gpsd:INFO: speed 115200, 8N1
gpsd:IO: => GPS: $PASHQ,RID*28\x0d\x0a
gpsd:IO: => GPS: @F0.3=1*67\x0d\x0a
gpsd:IO: => GPS: @F0.3=1*67\x0d\x0a
gpsd:IO: => GPS: @F2.2=1*64\x0d\x0a
gpsd:IO: => GPS: @F2.2=1*64\x0d\x0a
gpsd:IO: => GPS: GPS:GPGGA 1\x0d\x0a
gpsd:PROG: writing oncore control type Cj
gpsd:IO: => GPS: @@Cj)\x0d\x0aRID*28\x0d\x0a
gpsd:SPIN: open(/dev/ttyS0) -> 6 in gpsd_serial_open()
gpsd:PROG: Probing "Garmin USB binary" driver...
gpsd:PROG: Probe not found "Garmin USB binary" driver...
gpsd:PROG: Probing "GeoStar" driver...

So when I installed gpsd from EPEL on a Centos 7 box the other day I was surprised that running gpsd would not produce any output. even "gpsd -V" would not show the version number. I strace'd the gpsd -V run and could see that the write() to STDOUT (file descriptor 1) was actually going to device 1,3

fstat(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x7fff7e13b4b0) = -1 ENOTTY (Inappropriate ioctl for device)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa1e9502000
write(1, "gpsd: 3.11~dev (revision 3.10-5."..., 55) = 55
exit_group(0)                           = ?
+++ exited with 0 +++
[root@octobox3 gpsd]#

 Device 1,3 is /dev/null

[root@octobox3 gpsd]# ls -l /dev/null
crw-rw-rw-. 1 root root 1, 3 Dec 22 00:20 /dev/null

I searched /var/log and poked around in systemd (disabling gpsd, gpsdctl etc), journalctl etc. I ended up rebuilding the RPM and installing it... same problem. I built from the source tarball and ran the resulting executable... now it works!

So, I copied it to /usr/sbin over top of the existing /usr/sbin/gpsd. Didn't work again! After a few more cp+mv tests and rebuilds and it finally occurred to me. That the "copy" to /usr/sbin/gpsd resulted in the same permissions and SELinux contexts/attributes being applied to the file.

At this point I was convinced the problem was due to the SELinux context of the gpsd executable installed by the EPEL rpm. Googling this new info led me to this blog post.

In that post Dan Walsh explains the whole situation, including the fact that the tty restrictions are usually set by default to NOT produce an AVC message so you see nothing in the logs (and have no idea what's going on if you've never seen this before).

He also gives a solution:

setsebool allow_daemons_use_tty on

That will temporarily allow any daemon that is normally restricted from accessing STDOUT etc to actually use STDOUT. It won't survive a reboot in case I forget to set if back off, which is preferred in this case.

msys2 upgrade without pacman errors

Upgrade Your msys2 Installation

Without pacman Errors

EDIT 9/11/2014: A new installer/zip of msys2 was released on 9/10/2014 and at least for now, the following procedure is not really necessary for new installs. Base files are all up to date upon a fresh install. The procedure below describes upgrading an old installation or a new install where the current repo packages are newer than the ones in the installer or installation zipfile.

I recently became obsessed with achieving a clean upgrade and reinstallation of all packages on  a fresh install of msys2. I finally figured out a sequence of pkg upgrades that has no pacman execution errors.

I used 64bit msys2 available here: http://sourceforge.net/projects/msys2/

or here:http://msys2.github.io/

strace'ing Abe block explorer

          Well there's your problem ---->

Centos 6 python-crypto version and Abe Blockchain Explorer

Trying to make Abe blockchain explorer work on Centos 6 for Litecoin and I kept running into Merkle hash errors:

MerkleRootMismatch: Block header Merkle root does not match its
transactions. block hash=5c64e0d3548c8dd2b850798d77c18070a3032505ce601
fa3685d329ff0bdebf4

Bluetooth module working with Custom Android DRO Shield

I posted long ago about a Custom Arduino shield for use with TouchDRO from www.yuristoys.com. I explained how I had preferred to use RS232 wired output, but I had broken out the connections for hooking up a Bluetooth module.

Yuri was kind enough to add a direct USB connection method to his TouchDRO app, and it worked for me with a USB OTG cable and USB-Serial dongle hanging from my Nexus 7. I was pretty happy but I didn't actually have my scales mounted to my machine so this was just all sitting on my desk looking pretty.

Reading Yuriy's posts comments, I saw the light and became convinced that Bluetooth was the way I needed to go. I ordered the Bluetooth module Yuriy used here on Amazon

mining rig rack power upgrade

I recently got in enough parts to build 2 small 3x 7870 rigs (actually one card is a 7950). I needed at least 1 more power outlet because my first rig (5x 7970) was pulling 1200W on a nearby outlet, but I wanted to get a dedicated one for the first rig also.

My "rig rack" (built from the corner posts of an old server cabinet) had room for quite a few more motherboards so I decide to do a full bore power upgrade for future mining rigs.

Multi GPU Machines and PCIE In-Band vs. Out-of-Band Presence Detection

TLDR: 
To improve PCIE bus initialization during boot when trying to run x16 GPUs via various PCIE risers, short pin A1 to B17 on ALL PCIE x1 risers (in the unlikely event you are using x4/x8 to x16 risers, look up the proper x4/x8 PRSNT#2 pin and short that one to A1 instead).

I guess I should preface everything below by saying, I'd be happy to hear how PCIE bus initialization really works (in relation to the problem described below) from someone who knows PCIE buses.

Full Story

Last night I had a problem getting multiple Radeon 7970 GPUs running in a single motherboard, 4 cards good --> 5 cards pure chaos, lspci showing 3 cards only, swapping slots, risers, cards all showed that everything was good, just not in any combination over 4 and in fact, some combinations of 4 no good. (Maybe even some with 3).

7970 GPUs