我有一个基于python的守护进程,通过HTTP为一些命令行工具提供类似REST的接口.该工具的一般性质是接受请求,执行一些命令行操作,将pickle数据结构存储到磁盘,并将一些数据返回给调用者.在守护程序启动时产生了一个辅助线程,它定期查看磁盘上的pickle数据,并根据数据中的内容进行一些清理.
如果pickle数据所在的磁盘恰好是Linux机器上的本地磁盘,则可以正常工作.如果你切换到安装了NFS的磁盘,守护进程就可以正常启动,但是随着时间的推移,NFS挂载的共享"消失",并且守护进程无法通过类似的调用来判断它在磁盘上的位置os.getcwd().您将开始看到它记录错误,如:
2011-07-13 09:19:36,238 INFO Retrieved submit directory '/tech/condor_logs/submit'
2011-07-13 09:19:36,239 DEBUG CondorAgent.post_submit.do_submit(): handler.path: /condor/submit?queue=Q2%40scheduler
2011-07-13 09:19:36,239 DEBUG CondorAgent.post_submit.do_submit(): submitting from temporary submission directory '/tech/condor_logs/submit/tmpoF8YXk'
2011-07-13 09:19:36,240 ERROR Caught un-handled exception: [Errno 2] No such file or directory
2011-07-13 09:19:36,241 INFO submitter - - [13/Jul/2011 09:19:36] "POST /condor/submit?queue=Q2%40scheduler HTTP/1.1" 500 -
未处理的异常解析为守护程序无法再查看磁盘.此时任何试图找出守护程序当前工作目录的尝试os.getcwd()都将失败.即使尝试更改为NFS挂载的根目录/tech也会失败.一直logger.logging.*以来,这些方法都很乐意将日志和调试消息写入位于NFS安装的共享位置的日志文件中/tech/condor_logs/logs/CondorAgentLog.
磁盘绝对是可用的.还有其他基于C++的守护进程,在基于python的守护进程时,在此共享上具有更高的频率读取和写入.
我陷入了调试这个问题的僵局.既然它适用于本地磁盘,代码的一般结构一定要好,对吧？有一些关于NFS挂载的共享和我的代码是不兼容的,但我不知道它可能是什么.
在处理长时间运行的Python守护程序时,是否必须实现特殊注意事项,这些守护程序将经常读取和写入安装在NFS上的文件共享？
如果有人想看到代码处理HTTP请求并将pickle对象写入磁盘的部分在github 这里.通过读取pickle对象,子线程用来定期清理磁盘中的东西的部分就在这里.
好吧,我对这些东西感到非常困惑,所以真正的描述性答案会受到赞赏,特别是如果它们使整个装置不那么神奇且更具可预测性.
我正在尝试使用nfs安装我的Drobo-FS NAS以获得比使用cif更好的性能.
drobo正在运行一些精简的linux发行版.
在客户端计算机上的/ etc/fstab内部(Ubuntu,IP:192.168.1.150)
# Mount Drobo
192.168.1.100:/mnt/DroboFS/Shares/public /media/drobonfs nfs rw,soft,proto=tcp,users 0 0
我已经在drobo上安装了unssd并通过ssh访问.这是服务器计算机上的导出文件(Drobo-FS,IP 192.168.1.100):
# Allow access for client machine
/mnt/DroboFS/Shares 192.168.1.150(rw,no_root_squash)
挂载工作正常,但挂载的文件全部由root拥有,大多数文件权限设置为744.客户端上挂载中显示的文件权限与服务器上的实际权限相匹配.例如:
client$ sudo chmod 123 /media/drobonfs/somefile
client$ ls -l /media/drobonfs/somefile
---x-w--wx 1 root root 0 2012-01-04 14:15 /media/drobonfs/somefile
drobo$ ls -l /mnt/DroboFS/Shares/public/somefile
---x-w--wx 1 root root 0 Jan 4 14:15 /mnt/DroboFS/Shares/public/somefile
在每个命令前写sudo是一个拖累,我想了解发生了什么,所以如何将所有者/组设置为我的帐户而不是根目录,将其挂载到客户端计算机上？
通常在NFS客户端上,如何通过使用Bash Shell脚本来检测服务器端的Mounted-Point或DEAD？
通常我这样做:
if ls '/var/data' 2>&1 | grep 'Stale file handle';
then
echo "failing";
else
echo "ok";
fi
但问题是,当特别是NFS服务器完全死机或停止时,即使是ls命令,在客户端进入该目录也会被绞死或死亡.手段,上面的脚本不再可用.
有没有办法再次检测到这个？
我的一个客户发现他需要包含'crossmnt'以及他的NFS导出选项.我将把选项写入我们的软件中,这样他就不必进行黑客攻击并且可以使用crossmnt作为一个真正的选项.
这是我可以在我们的文档中使用的crossmnt的正确解释吗？
Crossmnt允许NFS客户端遍历导出根目录下的目录.例如:etc/exports:
/exports *(fsid=0,ro,root_squash,sync)
/exports/doc *(ro,root_squash,bind=/usr/share/doc)
使用crossmnt,客户端可以看到/ exports/doc的内容作为/ exports的子文件夹,而没有crossmnt,doc似乎是一个空文件夹.
该视频用于举例:https: //www.youtube.com/watch？v = 9cJciX8dB8
听起来不错吗？谢谢.
我正在使用vagrant-winnfsd插件在Windows 8.1主机上添加Vagrant的NFS支持.我正在运行Ubuntu 14.04客户端.
我正在使用此设置来运行Rails应用程序.除了Rails/Carrierwave尝试从tmp目录中删除生成此错误的文件时,一切都运行良好:
Errno::EIO (Input/output error @ dir_s_rmdir - /vagrant/myproject/public/uploads/tmp/1421108602-18479-5242):
这是我的Vagrant文件的相关部分:
config.vm.network "private_network", type: "dhcp"
config.vm.synced_folder ".", "/vagrant", type: "nfs"
关于如何解决这个问题的任何想法？
我在AWS实例上构建了一个中间层基础设施,包括3个主服务器(运行zookeeper,mesos-master,marathon和haproxy)和N个从属服务器(运行mesos-slave和docker).
如果我在不同的奴隶上运行相同的容器马拉松下载每个奴隶相同的图像.我想共享一个单独的nfs导出(比如在master1上)并将其挂载到每个slave上,以便为图像提供唯一的存储空间.
我在EC2实例上使用Ubuntu,因此默认使用的存储驱动程序是device-mapper.我设置奴隶来挂载/ var/lib/docker/devicemapper和/ var/lib/docker/graph,但它最终出现了这个错误:"陈旧的NFS文件句柄"
我想了解的是:
我正在从底部为Beagle Bone板构建一个Linux系统.我编译了vanilla内核并构建了一个基本的根文件系统busybox.系统使用U-boot启动,而rootfs它位于Linux PC上并通过NFS导出:
/path/to/rootfs 10.42.0.17(rw,wdelay,no_root_squash,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
U-boot bootargs是:
bootargs console=ttyO0,115200n8 root=/dev/nfs rw nfsroot=${serverip}:/path/to/rootfs,v3,tcp ip=dhcp
我在尝试su为非root用户工作时遇到了问题.为了解决这个问题,互联网上的人们建议设置二进制suid位busybox.这样做之后:
$ sudo chmod u+s busybox
并验证:
$ ls -la
...
-rwsr-xr-x 1 myuser myuser 1882976 Jan 13 21:47 busybox
...
$ stat -c "%a %n" busybox
4755 busybox
有些不对劲.内核正在启动并显示所有常用消息,但最后会卡住,并且不会login显示任何行.以下是启动顺序的最后几行:
[ 3.776185] IP-Config: Complete:
[ 3.779656] device=eth0, hwaddr=c8:a0:30:c5:80:e9, ipaddr=10.42.0.17, mask=255.255.255.0, gw=10.42.0.1
[ 3.789877] host=10.42.0.17, domain=, nis-domain=(none)
[ 3.795822] bootserver=10.42.0.1, rootserver=10.42.0.1, rootpath=
[ 3.802492] nameserver0=10.42.0.1 …我有一个具有文件夹权限的NFS服务器,如下所示.有50个客户端需要在同一网络中连接到此服务器.我想知道查找命令的是什么,从服务器访问此服务器的客户端.
NFS服务器配置文件如下所示.
[root@server ~]# cat /etc/exports
/home/guests *(rw,sync)
/india *(rw,sync)
以下是共享文件夹列表
[root@server ~]# showmount -e
Export list for server.sanith.com:
/india *
/home/guests *
出于测试目的,我现在已将一个客户端连接到服务器.以下输出来自"client2"机器.
[root@client2 ~]# showmount -e 192.168.1.10
Export list for 192.168.1.10:
/india *
/home/guests *
[root@client2 ~]# mount -t nfs 192.168.1.10:/india /test
[root@client2 ~]# mount
/dev/sda2 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
/dev/sda1 on /boot …我有docker-compose.yml文件
volumes:
nfs:
driver: local
driver_opts:
type: nfs
o: addr=192.168.100.1,rw
device: ":/mnt/storage"
我的容器已装入卷,有选项:
type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.100.1,mountvers=3,mountproto=tcp,local_lock=none,addr=192.168.100.1)
使用local_lock = none,我无法将此选项更改为local_lock =所有 我尝试过:
volumes:
nfs:
driver: local
driver_opts:
type: nfs
o: addr=192.168.100.1,rw,local_lock=all
device: ":/mnt/storage"
和
volumes:
nfs:
driver: local
driver_opts:
type: nfs
o: addr=192.168.100.1,rw
device: ":/mnt/storage"
local_lock: all
但没有变化
现在我们需要从AWS迁移到私有数据中心.我们需要找出潜在的替代存储而不是AWS S3.目前S3以下列方式使用:
天真的实现可以将这些数据存储在:
您会为这种情况推荐什么解决方案？