Ubuntu 14.04系统上Python使用"subprocess.Popen"执行"source"命令报告错误“/bin/sh: source: not found”

使用如下的例子中的代码

import subprocess
def execShellCommand(cmd):
    print cmd
    p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
    while True:  
        buff = p.stdout.readline()  
        if buff == '' and p.poll() != None:  
            break
        print buff
    p.wait()


def main():
    execShellCommand("source ~/.profile")

if __name__ == "__main__":
    main()

运行的时候报告错误

source ~/.profile
/bin/sh: 1: source: not found

这个错误发生的原因是subprocess.Popen执行Shell命令的时候默认调用/bin/sh，而source命令/bin/bash才支持的，因此导致错误发生，修改后的脚本如下：

import subprocess
def execShellCommand(cmd):
    print cmd
    p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT,executable="/bin/bash")
    while True:  
        buff = p.stdout.readline()  
        if buff == '' and p.poll() != None:  
            break
        print buff
    p.wait()


def main():
    execShellCommand("source ~/.profile")

if __name__ == "__main__":
    main()

注意添加的executable="/bin/bash"，指明了执行脚本的执行程序是/bin/bash。

参考链接

Calling the “source” command from subprocess.Popen

OpenMediaVault 3.0.87数据分区文件系统从EXT4升级到BTRFS并启用压缩特性

自己搭建的NAS使用的是OpenMediaVault 3.0.87,默认的磁盘系统分区是EXT4数据分区格式，并且没有搭建RAID阵列，暂时不建议RAID阵列执行升级操作。

某些磁盘已经空间非常紧张了，希望能使用像微软的NTFS格式相同的磁盘数据压缩功能，但是遗憾的是EXT4数据分区格式是不支持数据压缩的。因此有必要升级到BTRFS数据分区格式。

另外，OpenMediaVault 3.0.87的Linux内核已经更新到Linux Kernel 4.9.0能够非常好的支持BTRFS数据分区格式了，因此尝试升级到BTRFS数据分区格式。

在执行如下操作之前，请确定已经启用了OpenMediaVault的SSH远程登录功能。

首先，确定数据分区的挂载位置

root@openmediavault:~# df
文件系统            1K-块       已用       可用 已用% 挂载点
udev                10240          0      10240    0% /dev
tmpfs              788476       9204     779272    2% /run
/dev/sdc1         3589076    1795968    1591076   54% /
tmpfs             1971180          0    1971180    0% /dev/shm
tmpfs                5120          0       5120    0% /run/lock
tmpfs             1971180          0    1971180    0% /sys/fs/cgroup
tmpfs             1971180          0    1971180    0% /tmp
/dev/sda1      2884137588 1282636316 1601484888   45% /media/7948f871-78ff-4448-a0e7-ad508359238e
/dev/sdb1      3845558068 2094208152 1751333532   55% /media/9b5fcef5-6c5a-4478-80a8-41ae6cb9dce3
/dev/sdd1      2884137588 2865971516   18149688  100% /media/7909fba8-cc50-430f-986f-9db4ba7caa3c

如上所示，我们看到有三个磁盘的挂载，分别挂载在/dev/sda1 ,/dev/sdb1 , /dev/sdd1。

我们接下来以/dev/sda1分区为例：

$ umount /dev/sda1

$ btrfs-convert /dev/sda1

几个小时后（3TB），会输出如下信息：

creating btrfs metadata.
creating ext2fs image file.
cleaning up system chunk.
conversion complete.

表示已经转换完成了。

注意，转换完成后磁盘的UUID会发生变化，需要重新手工修正。

$ blkid /dev/sda1

得到如下输出：

/dev/sda1: UUID="6357625f-c966-49ba-9c90-9e8f8ff50433" UUID_SUB="cd51e4cf-1b77-488a-ae29-d4669c0a4cdd" TYPE="btrfs" PARTUUID="82b68e98-9341-4095-b152-f51f00c2e577"

接下来，调整磁盘加载参数

$ cp /etc/openmediavault/config.xml /etc/openmediavault/config.xml.bak
$ sed -i 's/7948f871-78ff-4448-a0e7-ad508359238e/6357625f-c966-49ba-9c90-9e8f8ff50433/g' /etc/openmediavault/config.xml

找到

<mntent>
  <uuid>95ed6452-f93d-4092-af4a-c72e138f0072</uuid>
  <fsname>6357625f-c966-49ba-9c90-9e8f8ff50433</fsname>
  <dir>/media/6357625f-c966-49ba-9c90-9e8f8ff50433</dir>
  <type>ext4</type>
  <opts>defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl</opts>
  <freq>0</freq>
  <passno>2</passno>
  <hidden>0</hidden>
</mntent>

修改为

<mntent>
  <uuid>95ed6452-f93d-4092-af4a-c72e138f0072</uuid>
  <fsname>6357625f-c966-49ba-9c90-9e8f8ff50433</fsname>
  <dir>/media/6357625f-c966-49ba-9c90-9e8f8ff50433</dir>
  <type>btrfs</type>
  <opts>defaults,nofail,noexec,acl,compress=lzo,autodefrag,commit=0,noatime</opts>
  <freq>0</freq>
  <passno>2</passno>
  <hidden>0</hidden>
</mntent>

注意我们增加的参数，分别是修改文件系统格式从ext4修改为btrfs,同时增加了几个关键参数

compress=lzo,autodefrag,commit=0,noatime

其中的compress为压缩算法，目前我们指定lzo压缩。autodefrag为自动碎片整理，提升我们的性能。commit为数据提交的延迟，默认是30秒，适当增加时间可以提升磁盘性能，但是可能在突然断电的时候造成数据的丢失，由于我们是NAS，数据安全性第一，因此正时间被设置成0，要求文件系统在修改后立即刷新到磁盘上，放置数据丢失。另外强烈建议增加noatime参数，这个参数是要求系统不必在每次访问文件的时候都修改最后一次的访问时间，可以明显提升服务器性能，尤其是对于NAS服务器来说，除非是安全审计需要，否在完全没必要使用文件访问时间。

另外注意我们移除的参数

user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0

这几个参数是btrfs不支持的。

完成后重启系统

$ omv-mkconf fstab

$ sudo reboot

注意，上面的操作完成后，并不会真正压缩已经存在的文件，只压缩以后创建的文件

$ cd /media/6357625f-c966-49ba-9c90-9e8f8ff50433

$ btrfs filesystem defragment -r -v -clzo .

上面的整个过程执行之后，会发现磁盘占用实际上是增加了的，这个不必在意，属于btrfs的特性，到一定程度会自动回收空间的。

如果想手工回收这部分空间，执行如下命令即可:

$ cd /media/6357625f-c966-49ba-9c90-9e8f8ff50433

$ btrfs balance start -v -dusage=0 .

$ btrfs balance start -v .

整个过程非常耗时间，可以通过新开一个SHELL中执行如下命令来查看进度信息

$ cd /media/6357625f-c966-49ba-9c90-9e8f8ff50433

$ btrfs balance status .

注意

目前遇到了执行

$ cd /media/6357625f-c966-49ba-9c90-9e8f8ff50433

$ btrfs balance start -v -dusage=0 .

$ btrfs balance start -v .

之后，整个OpenMediaVault系统无响应的问题，即使强制重新开机，也会在挂载完成刚刚转换后的磁盘后系统继续宕机，这个问题还在查找原因中。

刚刚开始是怀疑btrfs-tools版本太低导致的，系统默认自带的是btrfs-tools 3.17，但是Linux内核确是Linux Kernel 4.9.0，按理说，两者版本号应该是一致的，但是标准源上只更新到了btrfs-tools 4.7.3，使用如下命令更新后，问题依旧

$ sudo apt-get install btrfs-progs

通过移除硬盘，重启系统后,查看系统日志

$ cat /var/log/syslog

看到如下内容:

Aug 21 23:08:45 openmediavault kernel: [   11.572669] CPU: 1 PID: 501 Comm: mount Not tainted 4.9.0-0.bpo.3-amd64 #1 Debian 4.9.30-2+deb9u2~bpo8+1
Aug 21 23:08:45 openmediavault kernel: [   11.572805] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Q1900-ITX, BIOS C1.80 12/17/2015
Aug 21 23:08:45 openmediavault kernel: [   11.572944] task: ffff8fc0799a6dc0 task.stack: ffffa84ec0ae4000
Aug 21 23:08:45 openmediavault kernel: [   11.573033] RIP: 0010:[<ffffffffc0344fcb>]  [<ffffffffc0344fcb>] qgroup_fix_relocated_data_extents+0x2b/0x2c0 [btrfs]
Aug 21 23:08:45 openmediavault kernel: [   11.573234] RSP: 0018:ffffa84ec0ae79f0  EFLAGS: 00010246
Aug 21 23:08:45 openmediavault kernel: [   11.573315] RAX: ffff8fc0741b6800 RBX: ffff8fc077d26770 RCX: 000000000000128b
Aug 21 23:08:45 openmediavault kernel: [   11.573421] RDX: ffff8fc079343810 RSI: ffff8fc074741800 RDI: ffff8fc079343780
Aug 21 23:08:45 openmediavault kernel: [   11.573527] RBP: ffff8fc074ec2800 R08: ffff8fc07405c000 R09: ffff8fc079343780
Aug 21 23:08:45 openmediavault kernel: [   11.573633] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa84ec0ae7a88
Aug 21 23:08:45 openmediavault kernel: [   11.573740] R13: ffff8fc074741800 R14: 0000000000000000 R15: ffff8fc079343780
Aug 21 23:08:45 openmediavault kernel: [   11.573847] FS:  00007f8570bbe840(0000) GS:ffff8fc07fc80000(0000) knlGS:0000000000000000
Aug 21 23:08:45 openmediavault kernel: [   11.573967] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 21 23:08:45 openmediavault kernel: [   11.574054] CR2: fffffffffffffe10 CR3: 00000001367e6000 CR4: 00000000001006e0
Aug 21 23:08:45 openmediavault kernel: [   11.574160] Stack:
Aug 21 23:08:45 openmediavault kernel: [   11.574196]  ffffffffc02ed592 ffff8fc079343780 0000000000000801 ffff8fc0741b6800
Aug 21 23:08:45 openmediavault kernel: [   11.574335]  ffff8fc079343780 0000000000000801 ffffffffc02efffd ffff8fc0799a6dc0
Aug 21 23:08:45 openmediavault kernel: [   11.574478]  0000000000000000 a11cd9e1ac42d412 ffff8fc077d26770 ffff8fc074ec2800
Aug 21 23:08:45 openmediavault kernel: [   11.574616] Call Trace:
Aug 21 23:08:45 openmediavault kernel: [   11.579190]  [<ffffffffc02ed592>] ? join_transaction.isra.14+0x22/0x3f0 [btrfs]
Aug 21 23:08:45 openmediavault kernel: [   11.583819]  [<ffffffffc02efffd>] ? start_transaction+0x9d/0x4a0 [btrfs]
Aug 21 23:08:45 openmediavault kernel: [   11.588451]  [<ffffffffc0349638>] ? btrfs_recover_relocation+0x2e8/0x420 [btrfs]
Aug 21 23:08:45 openmediavault kernel: [   11.593105]  [<ffffffffc02ec94d>] ? open_ctree+0x223d/0x2760 [btrfs]
Aug 21 23:08:45 openmediavault kernel: [   11.597702]  [<ffffffff8ed35c49>] ? snprintf+0x49/0x60
Aug 21 23:08:45 openmediavault kernel: [   11.602250]  [<ffffffffc02bfe1d>] ? btrfs_mount+0xd3d/0xe80 [btrfs]
Aug 21 23:08:45 openmediavault kernel: [   11.606742]  [<ffffffff8eba538d>] ? pcpu_alloc+0x34d/0x650
Aug 21 23:08:45 openmediavault kernel: [   11.611187]  [<ffffffff8ec077a6>] ? mount_fs+0x36/0x170
Aug 21 23:08:45 openmediavault kernel: [   11.615562]  [<ffffffff8ec247c4>] ? vfs_kern_mount+0x64/0x100
Aug 21 23:08:45 openmediavault kernel: [   11.619940]  [<ffffffffc02bf29c>] ? btrfs_mount+0x1bc/0xe80 [btrfs]
Aug 21 23:08:45 openmediavault kernel: [   11.624250]  [<ffffffff8eba538d>] ? pcpu_alloc+0x34d/0x650
Aug 21 23:08:45 openmediavault kernel: [   11.628596]  [<ffffffff8ec077a6>] ? mount_fs+0x36/0x170
Aug 21 23:08:45 openmediavault kernel: [   11.632988]  [<ffffffff8ec247c4>] ? vfs_kern_mount+0x64/0x100
Aug 21 23:08:45 openmediavault kernel: [   11.637301]  [<ffffffff8ec26dad>] ? do_mount+0x1dd/0xc70
Aug 21 23:08:45 openmediavault kernel: [   11.641568]  [<ffffffff8ec27b24>] ? SyS_mount+0x84/0xc0
Aug 21 23:08:45 openmediavault kernel: [   11.645762]  [<ffffffff8f0077bb>] ? system_call_fast_compare_end+0xc/0x9b
Aug 21 23:08:45 openmediavault kernel: [   11.649937] Code: 0f 1f 44 00 00 41 57 41 56 41 55 41 54 55 53 48 83 ec 50 4c 8b 76 10 65 48 8b 04 25 28 00 00 00 48 89 44 24 48 31 c0 48 8b 46 08 <49> 8b ae 10 fe ff ff 48 8b 98 f0 01 00 00 31 c0 48 8b 53 20 83 
Aug 21 23:08:45 openmediavault kernel: [   11.659055] RIP  [<ffffffffc0344fcb>] qgroup_fix_relocated_data_extents+0x2b/0x2c0 [btrfs]
Aug 21 23:08:45 openmediavault kernel: [   11.663502]  RSP <ffffa84ec0ae79f0>
Aug 21 23:08:45 openmediavault kernel: [   11.667815] CR2: fffffffffffffe10
Aug 21 23:08:45 openmediavault kernel: [   11.671992] ---[ end trace 5342438d9209c318 ]---
Aug 21 23:08:45 openmediavault systemd[1]: media-6357625f\x2dc966\x2d49ba\x2d9c90\x2d9e8f8ff50433.mount mount process exited, code=killed status=9

根据Re: mount troubles after crash里面的回复，这个是Linux Kernel 4.9.0已知的BUG,在Linux Kernel 4.10-rcs之后的版本被修复。因此涉及到了Linux Kernel的升级操作。

目前看来要么自己编译内核，要么等待Debian Jessie的back-backports更新Linux内核了，希望整个修复已经合并到Linux Kernel 4.9.44版本中了吧。

或者关闭btrfs的磁盘配额(btrfs-quota）功能(崩溃的原因就是磁盘配额部分的BUG),也可以解决这个问题。

$ sudo btrfs quota disable /media/`whoami`/6357625f-c966-49ba-9c90-9e8f8ff50433

注意，上面的命令是在Ubuntu 16.04 Linux Kernel 4.4.0-92系统上执行的（硬盘被单独拿出来，然后挂载到Ubuntu 16.04 Linux Kernel 4.4.0-92的机器上），貌似由于这个版本的内核不支持btrfs的磁盘配额。因此，没有这个问题。

目前测试来看，上面的办法（关闭磁盘配额）并不能解决问题，看来只有升级到Linux Kernel 4.10，或者把补丁重新应用到Linux Kernel 4.9这一条路了。

手工升级到 Linux Kernel 4.13.0-rc5-amd64,则执行如下操作：

$ sudo cp /etc/apt/preferences.d/openmediavault-kernel-backports.pref /etc/apt/preferences.d/openmediavault-kernel-backports.pref.bak

$ sudo vi /etc/apt/preferences.d/openmediavault-kernel-backports.pref

把里面的如下内容

Package: linux-base
Pin: release a=jessie-backports
Pin-Priority: 500

Package: linux-headers-*
Pin: release a=jessie-backports
Pin-Priority: 500

Package: linux-image-*
Pin: release a=jessie-backports
Pin-Priority: 500

替换为：

Package: linux-base
Pin: release o=Debian,a=experimental
Pin-Priority: 102

Package: linux-headers-*
Pin: release o=Debian,a=experimental
Pin-Priority: 102

Package: linux-image-*
Pin: release o=Debian,a=experimental
Pin-Priority: 102

然后执行如下命令

#国内用户建议使用这个地址 deb http://mirrors.163.com/debian/ experimental main

$ sudo echo "deb http://deb.debian.org/debian experimental main" >> /etc/apt/sources.list

$ sudo apt-get update

$ sudo apt-get -t experimental install search linux-image-4.1

#目前最新的就是 linux-image-4.13.0-rc5-amd64 
$ sudo apt-get -t experimental install linux-image-4.13.0-rc5-amd64 

#使用完成后，建议移除我们刚刚的修改，这样可以避免误安装其他东西，导致系统异常。
$ sudo rm -rf  /etc/apt/preferences.d/openmediavault-kernel-backports.pref 
$ sudo mv  /etc/apt/preferences.d/openmediavault-kernel-backports.pref.bak  /etc/apt/preferences.d/openmediavault-kernel-backports.pref 
$ sudo sed -i '/deb\ http:\/\/deb.debian.org\/debian\ experimental\ main/d' /etc/apt/sources.list

$ sudo reboot

注意，这个源，可以替换成Debian 9的backport的源，貌似可以安装 linux-image-4.12版本的内核，内核部分不必追求最新，一般追求最稳定，能解决问题即可。

貌似linux-image-4.13.0-RC5版本内核依旧存在BUG，如下所示:

Aug 23 22:20:13 openmediavault kernel: [  153.478300] kernel BUG at /build/linux-yioSfB/linux-4.13~rc5/fs/btrfs/relocation.c:4667!
Aug 23 22:20:13 openmediavault kernel: [  153.478481] invalid opcode: 0000 [#1] SMP
Aug 23 22:20:13 openmediavault kernel: [  153.478553] Modules linked in: cpufreq_conservative cpufreq_powersave cpufreq_userspace nfsd auth_rpcgss nfs_acl nfs lockd grace fscache sunrpc quota_v2 quota_tree snd_hda_codec_hdmi snd_hda_codec_realtek hci_uart snd_hda_codec_generic snd_soc_rt5670 snd_soc_rt5645 btbcm snd_soc_rt5640 btqca snd_soc_rl6231 snd_intel_sst_acpi btintel snd_intel_sst_core bluetooth snd_soc_sst_atom_hifi2_platform snd_soc_sst_match drbg snd_soc_core iTCO_wdt ppdev iTCO_vendor_support ansi_cprng parport_pc parport i915 ecdh_generic snd_compress evdev snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep snd_pcm drm_kms_helper dw_dmac snd_timer battery drm snd video i2c_algo_bit dw_dmac_core shpchp lpc_ich rfkill soundcore mfd_core intel_rapl intel_soc_dts_thermal intel_soc_dts_iosf intel_powerclamp coretemp kvm_intel kvm
Aug 23 22:20:13 openmediavault kernel: [  153.479699]  irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel cryptd intel_cstate pcspkr button loop fuse autofs4 ext4 crc16 mbcache jbd2 fscrypto btrfs xor raid6_pq dm_mod md_mod sg sd_mod hid_generic usbhid ata_generic crc32c_intel i2c_i801 ahci r8169 mii libahci ata_piix xhci_pci libata xhci_hcd usbcore scsi_mod usb_common fan thermal i2c_hid hid sdhci_acpi sdhci i2c_designware_platform i2c_designware_core mmc_core
Aug 23 22:20:13 openmediavault kernel: [  153.480340] CPU: 0 PID: 112 Comm: kworker/u8:3 Tainted: G        W       4.13.0-rc5-amd64 #1 Debian 4.13~rc5-1~exp1
Aug 23 22:20:13 openmediavault kernel: [  153.480504] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Q1900-ITX, BIOS C2.10 11/30/2016
Aug 23 22:20:13 openmediavault kernel: [  153.480710] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
Aug 23 22:20:13 openmediavault kernel: [  153.480822] task: ffff8b09b5308380 task.stack: ffff993500afc000
Aug 23 22:20:13 openmediavault kernel: [  153.480965] RIP: 0010:btrfs_reloc_cow_block+0x1f8/0x370 [btrfs]
Aug 23 22:20:13 openmediavault kernel: [  153.481062] RSP: 0018:ffff993500aff9e0 EFLAGS: 00010246
Aug 23 22:20:13 openmediavault kernel: [  153.481150] RAX: ffff8b09b9d8c000 RBX: ffff8b09b6f19800 RCX: ffff8b08b62e05b8
Aug 23 22:20:13 openmediavault kernel: [  153.481265] RDX: ffff8b09b60c87a8 RSI: ffff8b09b6f19800 RDI: ffff8b09b8a33e88
Aug 23 22:20:13 openmediavault kernel: [  153.481379] RBP: ffff8b09b7efb000 R08: ffff993500affa70 R09: 0000000000001000
Aug 23 22:20:13 openmediavault kernel: [  153.481494] R10: fffffffffffffff7 R11: ffff8b09b8e94358 R12: ffff8b09b8a33e88
Aug 23 22:20:13 openmediavault kernel: [  153.481608] R13: 0000000000000000 R14: ffff8b08b62e05b8 R15: ffff8b09b9d8c000
Aug 23 22:20:13 openmediavault kernel: [  153.481724] FS:  0000000000000000(0000) GS:ffff8b09bfc00000(0000) knlGS:0000000000000000
Aug 23 22:20:13 openmediavault kernel: [  153.481854] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 23 22:20:13 openmediavault kernel: [  153.481948] CR2: 00007f9964755000 CR3: 0000000129809000 CR4: 00000000001006f0
Aug 23 22:20:13 openmediavault kernel: [  153.482063] Call Trace:
Aug 23 22:20:13 openmediavault kernel: [  153.482150]  ? update_ref_for_cow+0x254/0x350 [btrfs]
Aug 23 22:20:13 openmediavault kernel: [  153.482274]  ? __btrfs_cow_block+0x35d/0x5c0 [btrfs]
Aug 23 22:20:13 openmediavault kernel: [  153.482395]  ? btrfs_cow_block+0xcb/0x1b0 [btrfs]
Aug 23 22:20:13 openmediavault kernel: [  153.487038]  ? btrfs_search_slot+0x1fd/0x9e0 [btrfs]
Aug 23 22:20:13 openmediavault kernel: [  153.491662]  ? btrfs_lookup_file_extent+0x4a/0x70 [btrfs]
Aug 23 22:20:13 openmediavault kernel: [  153.496270]  ? __btrfs_drop_extents+0x156/0xe10 [btrfs]
Aug 23 22:20:13 openmediavault kernel: [  153.500816]  ? kmem_cache_alloc+0xbb/0x5a0
Aug 23 22:20:13 openmediavault kernel: [  153.505321]  ? __schedule+0x3d0/0x860
Aug 23 22:20:13 openmediavault kernel: [  153.509822]  ? insert_reserved_file_extent.constprop.65+0x97/0x2f0 [btrfs]
Aug 23 22:20:13 openmediavault kernel: [  153.514424]  ? btrfs_finish_ordered_io+0x33b/0x790 [btrfs]
Aug 23 22:20:13 openmediavault kernel: [  153.519029]  ? dequeue_task_fair+0x58/0x640
Aug 23 22:20:13 openmediavault kernel: [  153.523595]  ? __switch_to+0x234/0x430
Aug 23 22:20:13 openmediavault kernel: [  153.528159]  ? btrfs_scrubparity_helper+0xcf/0x300 [btrfs]
Aug 23 22:20:13 openmediavault kernel: [  153.532691]  ? __schedule+0x3d0/0x860
Aug 23 22:20:13 openmediavault kernel: [  153.537179]  ? process_one_work+0x181/0x370
Aug 23 22:20:13 openmediavault kernel: [  153.541641]  ? worker_thread+0x4d/0x3a0
Aug 23 22:20:13 openmediavault kernel: [  153.546128]  ? kthread+0xfc/0x130
Aug 23 22:20:13 openmediavault kernel: [  153.550568]  ? process_one_work+0x370/0x370
Aug 23 22:20:13 openmediavault kernel: [  153.554980]  ? kthread_create_on_node+0x70/0x70
Aug 23 22:20:13 openmediavault kernel: [  153.559390]  ? ret_from_fork+0x25/0x30
Aug 23 22:20:13 openmediavault kernel: [  153.563694] Code: 5e 41 5f e9 8b ad ff ff f6 85 b1 05 00 00 01 0f 84 ab fe ff ff c7 04 24 01 00 00 00 e9 d8 fe ff ff 49 83 fa f7 0f 85 42 fe ff ff <0f> 0b 41 0f b6 cf 4d 8d 7a 30 4c 89 44 24 20 48 89 c8 48 89 4c 
Aug 23 22:20:13 openmediavault kernel: [  153.572587] RIP: btrfs_reloc_cow_block+0x1f8/0x370 [btrfs] RSP: ffff993500aff9e0
Aug 23 22:20:13 openmediavault kernel: [  153.576943] ---[ end trace bc1f498ba941cbb6 ]---

执行如下命令，修复一下文件系统：

$ sudo umount /dev/sda1

# sudo btrfsck --repair --init-csum-tree --init-extent-tree /dev/sda1 太慢了，如果没有严重问题，只执行修复即可
$ sudo btrfsck --repair /dev/sda1

貌似不管用，估计还要继续升级内核，btrfs还是不够成熟啊！

参考OpenMdeiaValut 3.0.86上编译Linux Kernel 4.13-rc6编译安装最新的内核，貌似可以解决上面的问题。

参考链接

机器人程序设计之如何正确入门ROS

当前大家学习ROS还是以自学为主，所以会走很多的弯路，目前所谓的大神们也都是这样过来的。基本上早期开发机器人大家都是各干各的，甚至是防着彼此，生怕别人把我们的代码、设计抄袭过去，这样其实大家就是在重复地造轮子，进行一些底层的无聊工作。

继续阅读机器人程序设计之如何正确入门ROS

OpenMediaVault从2.x（最新版本）升级到3.0.87后无法登录

最近把存储服务器上的OpenMediaVault从2.1版本升级到最新的3.0.87版本之后，无法正常登录。

OpenMediaVault系统升级，参考OpenMediaVault系统升级。
继续阅读OpenMediaVault从2.x（最新版本）升级到3.0.87后无法登录

Ubuntu 14.04.5系统上OpenPTrack V1版本安装配置(Kinect V2)

目前在研究视觉跟踪人的事情，找到的比较好的参考项目就是OpenPTrack了，截至目前（2017.8.14）OpenPTrack的V2版本还没有释放出代码，因此我们只能依旧在V1版本上进行测试，这个版本目前只能在Ubuntu 14.04.5系统上运行，其他系统上（比如Ubuntu 16.04）问题比较多，还是建议在Ubuntu 14.04.5系统上进行安装。

1.从GitHub上获取项目代码
$ sudo apt-get install git -y
$ cd ~
$ git clone https://github.com/OpenPTrack/open_ptrack.git
2.安装ROS
$ cd open_ptrack/scripts
$ chmod +x *.sh
$ ./ros_install.sh

$ source /opt/ros/indigo/setup.bash
$ ./ros_configure.sh
3.安装OpenPTrack
$ ./openptrack_install.sh
4.链接OpenPTrack目录
$ ln -s  ~/workspace/ros/catkin/src/open_ptrack ~/open_ptrack
5.Kinect V2驱动程序安装
$ sudo apt-get install nvidia-375-dev
$ sudo apt-get install ocl-icd-opencl-dev

$ cd ~/workspace/ros/catkin/src
$ source ~/.profile 
$ roscd open_ptrack/../scripts
$ chmod +x kinect2_install.sh
$ ./kinect2_install.sh

重启系统，然后执行如下命令：

$ cd ~/workspace/ros/catkin/devel/lib/kinect2_bridge
$ sudo ./kinect2_bridge
6.完整的自动化安装脚本
import subprocess
def execBashShellCommand(cmd):
    print cmd
    p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT,executable="/bin/bash")
    while True:  
        buff = p.stdout.readline()  
        if buff == '' and p.poll() != None:  
            break
        print buff
    p.wait()


def main():
    execBashShellCommand("rm -rf ~/workspace")
    execBashShellCommand("rm -rf ~/.ros")
    execBashShellCommand("rm -rf ~/.rviz")
    execBashShellCommand("rm -rf ~/open_ptrack")

    execBashShellCommand("sudo apt-get install git -y")
    execBashShellCommand("cd ~ && git clone https://github.com/OpenPTrack/open_ptrack.git")

    execBashShellCommand("sed -i '/source ~\/workspace\/ros\/rosbuild\/setup.bash/d' ~/.bashrc")
    execBashShellCommand("sed -i '/export KINECT_DRIVER=openni/d' ~/.bashrc")
    execBashShellCommand("sed -i '/export LC_ALL=C/d' ~/.bashrc")

    execBashShellCommand("cd ~/open_ptrack/scripts && chmod +x *.sh && ./ros_install.sh")
    execBashShellCommand("cd ~/open_ptrack/scripts && source /opt/ros/indigo/setup.bash ; ./ros_configure.sh")
    execBashShellCommand("cd ~/open_ptrack/scripts && ./openptrack_install.sh")

    execBashShellCommand("ln -s  ~/workspace/ros/catkin/src/open_ptrack ~/open_ptrack")

    execBashShellCommand("source ~/workspace/ros/rosbuild/setup.bash ; source ~/.profile ; export KINECT_DRIVER=openni && export LC_ALL=C && cd ~/workspace/ros/catkin && catkin_make --pkg calibration_msgs && catkin_make --pkg opt_msgs && catkin_make --force-cmake")

    execBashShellCommand("sudo apt-get -y install nvidia-375-dev")
    execBashShellCommand("sudo apt-get -y install ocl-icd-opencl-dev")

    execBashShellCommand("source ~/workspace/ros/rosbuild/setup.bash ; source ~/.profile ; export KINECT_DRIVER=openni && export LC_ALL=C && cd ~/workspace/ros/catkin/src && roscd open_ptrack/../scripts && chmod +x kinect2_install.sh && ./kinect2_install.sh")

    execBashShellCommand("cd ~/workspace/ros/catkin/devel/lib/kinect2_bridge && sudo ./kinect2_bridge")

if __name__ == "__main__":
    main()
7.测试系统

可能需要重新插拔一下Kinect的USB数据线，然后执行如下命令

$ roslaunch kinect2_bridge kinect2_bridge.launch

执行之后，等待十几秒，然后Ctrl+C中断执行。
执行完成后，执行

$ roslaunch tracking detection_and_tracking_kinect2.launch

之后，会弹出三个界面出来。

参考链接

OpenPTrack Installation Guide

ROS下使用roslaunch命令时使用gdb/pdb调试

最近在使用OpenPTrack来进行人的跟踪测试，可是运行程序的时候总是崩溃。
OpenPTrack是通过roslaunch命令来运行程序的。
网上搜索了一下，可以找到对应的launch文件,在其中的node节点中增加如下语句即可

launch-prefix="xterm -e gdb -ex run --args "

我们以

$ roslaunch tracking detection_and_tracking_kinect2.launch

这条命令为例，detection_and_tracking_kinect2.launch文件的原始内容如下：

<launch>
  <arg name="camera_name"             default="kinect2_head" />

  <!-- Start the Kinect -->
  <include file="$(find kinect2_bridge)/launch/kinect2_bridge_ir.launch"/> 

   <!-- Launch ground based people detection node -->
   <node pkg="detection" type="ground_based_people_detector" name="ground_based_people_detector" output="screen" required="true">
    <rosparam command="load" file="$(find detection)/conf/ground_based_people_detector_kinect2.yaml" /> 
    <param name="classifier_file" value="$(find detection)/data/HogSvmPCL.yaml"/>
    <!--param name="camera_info_topic" value="/$(arg camera_name)/depth_lowres/camera_info"/-->
    <param name="camera_info_topic" value="/$(arg camera_name)/ir_rect/camera_info"/>
    <param name="output_topic" value="/detector/detections"/>
    <!--param name="pointcloud_topic" value="/$(arg camera_name)/depth_lowres/points"/-->
    <param name="pointcloud_topic" value="/$(arg camera_name)/depth_ir/points"/>
    <param name="rate" value="60.0"/>  
  </node>

</launch>

增加调试命令之后的样子如下：

<launch>
  <arg name="camera_name"             default="kinect2_head" />

  <!-- Start the Kinect -->
  <include file="$(find kinect2_bridge)/launch/kinect2_bridge_ir.launch"/> 

   <!-- Launch ground based people detection node -->
   <node pkg="detection" type="ground_based_people_detector" name="ground_based_people_detector" output="screen" required="true" launch-prefix="xterm -e gdb -ex run --args ">
    <rosparam command="load" file="$(find detection)/conf/ground_based_people_detector_kinect2.yaml" /> 
    <param name="classifier_file" value="$(find detection)/data/HogSvmPCL.yaml"/>
    <!--param name="camera_info_topic" value="/$(arg camera_name)/depth_lowres/camera_info"/-->
    <param name="camera_info_topic" value="/$(arg camera_name)/ir_rect/camera_info"/>
    <param name="output_topic" value="/detector/detections"/>
    <!--param name="pointcloud_topic" value="/$(arg camera_name)/depth_lowres/points"/-->
    <param name="pointcloud_topic" value="/$(arg camera_name)/depth_ir/points"/>
    <param name="rate" value="60.0"/>  
  </node>

</launch>

(注意代码添加位置)这样在执行原来例子的时候，就会先打开一个新的Shell界面，被调试的程序就在这个Shell中被执行了。

如果被调式的是Python脚本，则需要修改调试器为pdb,如下：

launch-prefix="xterm -e python -m pdb "

参考链接

Ubuntu 16.04系统Microsoft Common Objects in Context(COCO)数据集在Python环境中的使用

Microsoft Common Objects in Context(简写COCO)数据集是微软团队提供的一个可以用来进行图像识别，分割，注解等开发工作的数据集。

其官方说明网址：http://mscoco.org/。

继续阅读Ubuntu 16.04系统Microsoft Common Objects in Context(COCO)数据集在Python环境中的使用

PSV神秘海域如何调整为中文语言

最近淘宝了一个PSV版本的神秘海域,卖家说是繁体跟英文双语言的,结果插卡后一直是英文，始终找不到中文语言的选项。

网上搜索了以下，才发现是跟机器语言绑定的，如果要使用繁体中文版本，必须把机器的语言从简体中文调整到繁体中文才行。

也就是，在PSV设置里将系统语言设置为繁体中文,再进入游戏里就可以了。

参考链接

psv神秘海域怎么调中文

Caffe训练过程中的train，val，test的区别

val是validation的简称。
training dataset和validation dataset都是在训练的时候起作用。
而因为validation的数据集和training没有交集，所以这部分数据对最终训练出的模型没有贡献。
validation的主要作用是来验证是否过拟合、以及用来调节训练参数等。

比如训练0-10000次迭代过程中，train和validation的loss都是不断降低，
但是从10000-20000过程中train loss不断降低，validation的loss不降反升。
那么就证明继续训练下去，模型只是对training dataset这部分拟合的特别好，但是泛化能力很差。
所以与其选取20000次的结果，不如选择10000次的结果。
这个过程的名字叫做Early Stop，validation数据在此过程中必不可少。

如果跑caffe自带的训练demo，你会用到train_val.prototxt，这里面的val其实就是validation。
而网络输入的TEST层，其实就是validation，而不是test。你可以通过观察validation的loss和train的loss定下你需要的模型。

但是为什么现在很多人都不用validation了呢？
我的理解是现在模型中防止过拟合的机制已经比较完善了，Dropout\BN等做的很好了。
而且很多时候大家都用原来的模型进行fine tune，也比从头开始更难过拟合。
所以大家一般都定一个训练迭代次数，直接取最后的模型来测试。

引用链接