Hi,
love working with longhorn 0.4.1 and CoreOS.
Just a small thing someone might know the answer to.
When a device is mounted I see several messages in syslog:
systemd[8137]: Failed to stat device node file /dev/longhorn/pvc-ef9f95a2-5711-11e9-84eb-00505698590a: Permission denied
Is this something to be worried about?
/hw
Is there anything wrong with the volume itself, e.g. can it be read/write/snapshot/backup as normal? If so, you probably don’t need to worry about that. It’s maybe happened when the volume is attaching or detaching.
I found that part of the code in a deprecated repo though: https://github.com/coreos/systemd-deprecated/blob/master/src/core/device.c#L798
If possible, can you show me the permission of other blk devices vs Longhorn? e.g. /dev/sda vs /dev/longhorn/xxxx . And ps aux|grep systemd.
Hi,
In my tests using minio as S3 backup it seems that backup and read/write is OK. (have’nt tried restore yet, but should work)
/dev/sda:
brw-rw----. 1 root disk 8, 0 Apr 4 12:07 /dev/sda
/dev/longhorn:
brw-------. 1 root root 8, 16 Apr 5 07:22 /dev/longhorn/pvc-dc484b1d-5772-11e9-84eb-00505698590a
ps aux|grep systemd:
root 1 0.0 0.0 225416 10052 ? Ss Apr04 0:06 /usr/lib/systemd/systemd --switched-root --system --deserialize 15
root 609 0.0 0.2 112380 40620 ? Ss Apr04 0:00 /usr/lib/systemd/systemd-journald
root 643 0.0 0.0 73672 8076 ? Ss Apr04 0:00 /usr/lib/systemd/systemd-udevd
systemd+ 646 0.0 0.0 59888 6576 ? Ss Apr04 0:00 /usr/lib/systemd/systemd-networkd
systemd+ 713 0.0 0.0 60192 6084 ? Ss Apr04 0:02 /usr/lib/systemd/systemd-resolved
systemd+ 718 0.0 0.0 139316 3136 ? Ssl Apr04 0:00 /usr/lib/systemd/systemd-timesyncd
root 742 0.0 0.0 58064 6696 ? Ss Apr04 0:00 /usr/lib/systemd/systemd-logind
message+ 754 0.0 0.0 64992 5012 ? Ssl Apr04 0:01 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
root 5179 0.0 0.0 6848 892 pts/0 S+ 07:37 0:00 grep --colour=auto systemd
root 7477 3.7 0.8 927280 133720 ? Ssl Apr04 42:53 kubelet --cluster-domain=cluster.local --hostname-override=docker05 --address=0.0.0.0 --anonymous-auth=false --cgroups-per-qos=True --cni-conf-dir=/etc/cni/net.d --read-only-port=0 --v=2 --kubeconfig=/etc/kubernetes/ssl/kubecfg-kube-node.yaml --allow-privileged=true --network-plugin=cni --volume-plugin-dir=/var/lib/kubelet/volumeplugins --cloud-provider= --cluster-dns=10.43.0.10 --pod-infra-container-image=rancher/pause:3.1 --authentication-token-webhook=true --cni-bin-dir=/opt/cni/bin --resolv-conf=/etc/resolv.conf --streaming-connection-idle-timeout=30m --client-ca-file=/etc/kubernetes/ssl/kube-ca.pem --root-dir=/opt/rke/var/lib/kubelet --enforce-node-allocatable= --event-qps=0 --make-iptables-util-chains=true --fail-swap-on=false --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --cgroup-driver=cgroupfs --resolv-conf=/run/systemd/resolve/resolv.conf
core 8215 0.0 0.0 68160 8176 ? Ss 07:13 0:00 /usr/lib/systemd/systemd --user
Thanks for the information, I can see what’s wrong now, though probably not going have much impact on available of the device, since we don’t depend on systemd to do anything about the device.
The reason is systemd doesn’t always use root user to operate. As you can see, /dev/sda is in group disk with rw set for the group permission. We will check more on what could be the impact and what we can do to get the permission right.
I’ve filed https://github.com/rancher/longhorn/issues/463 to track this.
Thx for following up.
Great job, BTW 
/hw