<div dir="ltr">Hey Felipe,<br><br>On Thu, Feb 18, 2016 at 5:39 PM, Felipe Sateler <<a href="mailto:fsateler@debian.org">fsateler@debian.org</a>> wrote:<br>> That mail has:<br>> 1711:Feb 10 16:44:40 SERVER systemd[1]: mnt-NFSSERVER.mount changed<br>> dead -> mounting<br>> 1817:Feb 10 16:44:43 SERVER systemd[1]: mnt-NFSSERVER.mount changed<br>> mounting -> mounted<br>> 1818:Feb 10 16:44:43 SERVER systemd[1]: Job mnt-NFSSERVER.mount/start<br>> finished, result=done<br>> 1819:Feb 10 16:44:43 SERVER systemd[1]: Mounted /mnt/NFSSERVER.<br>> 2106:Feb 10 16:44:43 SERVER systemd[1]: mnt-NFSSERVER.mount changed<br>> mounted -> dead<br>> 2107:Feb 10 16:44:43 SERVER systemd[1]: Failed to destroy cgroup<br>> /system.slice/mnt-NFSSERVER.mount: Device or resource busy<br>> 2632:Feb 10 16:44:54 SERVER systemd[1]: mnt-NFSSERVER.mount changed<br>> dead -> mounted<br>><br>> So somehow the mount finishes successfully but the mount is declared<br>> dead in rapid succession. This would suggest that systemd regards<br>> remote-fs up at the time of the mount success exit, but the mount then<br>> dies and revives some seconds later.<br><br>thanks for reading this to me! I somehow missed the mounted-dead-mounted again dance.<br><br>> Are there any possibly relevant logs during that time?<br><br>I extended a bit the grep on the logs:<div><br></div><div><div><div>1005:Feb 10 16:44:38 SERVER systemd[1]: Installed new job mnt-NFSSERVER.mount/start as 97</div><div>1707:Feb 10 16:44:40 SERVER systemd[1]: Mounting /mnt/NFSSERVER...</div><div>1709:Feb 10 16:44:40 SERVER systemd[1]: About to execute: /bin/mount -n XXX.YYY.16.226:/VOL /mnt/NFSSERVER -t nfs -o rw,intr,tcp,bg,rdirplus,noatime,_netdev</div><div>1710:Feb 10 16:44:40 SERVER systemd[1]: Forked /bin/mount as 583</div><div>1711:Feb 10 16:44:40 SERVER systemd[1]: mnt-NFSSERVER.mount changed dead -> mounting</div><div>1713:Feb 10 16:44:40 SERVER systemd[583]: Executing: /bin/mount -n XXX.YYY.16.226:/VOL /mnt/NFSSERVER -t nfs -o rw,intr,tcp,bg,rdirplus,noatime,_netdev</div><div>1767:Feb 10 16:44:43 SERVER mount[586]: mount to NFS server 'XXX.YYY.16.226' failed: No route to host, retrying</div><div>1814:Feb 10 16:44:43 SERVER systemd[1]: Child 583 (mount) died (code=exited, status=0/SUCCESS)</div><div>1815:Feb 10 16:44:43 SERVER systemd[1]: Child 583 belongs to mnt-NFSSERVER.mount</div><div>1816:Feb 10 16:44:43 SERVER systemd[1]: mnt-NFSSERVER.mount mount process exited, code=exited status=0</div><div>1817:Feb 10 16:44:43 SERVER systemd[1]: mnt-NFSSERVER.mount changed mounting -> mounted</div><div>1818:Feb 10 16:44:43 SERVER systemd[1]: Job mnt-NFSSERVER.mount/start finished, result=done</div><div>1819:Feb 10 16:44:43 SERVER systemd[1]: Mounted /mnt/NFSSERVER.</div><div>1875:Feb 10 16:44:43 SERVER mount[583]: mount.nfs: backgrounding "XXX.YYY.16.226:/VOL"</div><div>1876:Feb 10 16:44:43 SERVER mount[583]: mount.nfs: mount options: "rw,noatime,intr,tcp,bg,rdirplus,_netdev"</div><div>2106:Feb 10 16:44:43 SERVER systemd[1]: mnt-NFSSERVER.mount changed mounted -> dead</div><div>2107:Feb 10 16:44:43 SERVER systemd[1]: Failed to destroy cgroup /system.slice/mnt-NFSSERVER.mount: Device or resource busy</div><div>2632:Feb 10 16:44:54 SERVER systemd[1]: mnt-NFSSERVER.mount changed dead -> mounted</div></div><div><br></div><div>so you can see the "No route to host" error, but also note that the very same error happened for all the NFS shares, and upon inspection, all of them show the same behavior:</div><div><br></div><div><div>Feb 10 16:44:40 SERVER systemd[1]: mnt-ANOTHERSERVER.mount changed dead -> mounting</div><div>Feb 10 16:44:43 SERVER systemd[1]: mnt-ANOTHERSERVER.mount changed mounting -> mounted</div><div>Feb 10 16:44:43 SERVER systemd[1]: mnt-ANOTHERSERVER.mount changed mounted -> dead</div><div>Feb 10 16:44:44 SERVER systemd[1]: mnt-ANOTHERSERVER.mount changed dead -> mounted</div></div><div><br></div><div>but they all recover at 16:44:44 while one takes longer.</div><div><br></div><div>so is it possible that systemd consider the mount done (line 1819) above, while actually the mount process is backgrounding the mount? can we disable the backgrounding of NFS mounts? if so, how?</div><br>>> Let me know if you prefer to investigate this latest state (the<br>>> machine is still in that state and has not been touched since, and it<br>>> appears to be somehow relevant to the situation at hand) or do you<br>>> want me to start rebooting the node until we are able to replicate the<br>>> same situation as above.<br>><br>><br>> Well, lets debug the most reproducible one ;) But, the above seems to</div><div><br></div><div>makes sense :)</div><div><br>> imply that the problems do not happen always? I presume it happens<br>> frequently enough to be a problem, but does the system manage to boot<br>> successfully sometimes?</div><div><br></div><div>apologize if i didnt make it clearer before, but this error started appearing after I change the way i'm collecting these failures; I have an @reboot cronjob that previously it was:</div><div><br></div><div>1. sleep for 2m (as the initial error was about mounts timing out at 1m30s)</div><div>2. checks if the number of mounts is the correct one</div><div>2.1. if not, grab some systems log</div><div>3. reboot</div><div><br></div><div>i changed it slighly into:</div><div><br></div><div><div>1. sleep for 10s</div><div>2. checks if the number of mounts is the correct one</div><div>2.1. if not, grab some systems log</div><div>3. sleep for 2m (to have a chance to log into the system and eventually stop the reboot process)</div><div>4. reboot</div></div><div><br></div><div>now that the cronjob "do stuff" much earlier than before, this issue is triggered, and it might very well be the "<span style="font-size:12.8px">(3.) we have some @reboot cronjobs to start programs stored on some" problem mentioned in the original post</span></div><div><br>>>>>> Do you have more<br>>>>>> interfaces in these machines? Are all of them configured as auto or<br>>>>>> static?<br>>>>><br>>>>> on this particular machine there is a single eth0 interface configured as auto<br>>>><br>>>> So this is not the same setup as the previous one you posted? I'm<br>>>> getting a bit confused...<br>>><br>>> yes this has always been the same setup; my question about multiple<br>>> NICs is because we do have seen this behavior on machines with<br>>> multiple interfaces, and so we were wondering if that could make the<br>>> issue more likely to happen, but it was more of a curiosity.<br>>><br>>> the machine I am providing logs from is always the same with the same<br>>> exact configuration, unless specified (like disabling services as<br>>> requested, etc etc).<br>><br>> Well, that does not match with the info you sent in the Feb 9 mail (an<br>> inet static configuration).<br><br>gaah sorry about the confusion :( yeah, that is the exact network config: "auto eth0 \ iface eth0 inet static" so I highlighted the "auto eth0" (driven a bit by your comment about auto) and forgot to mention the second config line.<br><br>thanks!</div><div><br>-- <br>Sandro "morph" Tosi<br>My website: <a href="http://sandrotosi.me/">http://sandrotosi.me/</a><br>Me at Debian: <a href="http://wiki.debian.org/SandroTosi">http://wiki.debian.org/SandroTosi</a><br>G+: <a href="https://plus.google.com/u/0/+SandroTosi">https://plus.google.com/u/0/+SandroTosi</a><br><div><br></div></div><div><br></div></div>