Dotaz: Zamrzání při nedostupných mountech

[Ondra]

Ahoj všem,

Mám na serveru připojené dva vzdálené filesystémy (CIFS a SSHFS) a na nich jsou soubory, které jsou čteny jedním démonem.

Občas se ale musí server odpojit od sítě (neřešte proč ) a pak nastává problém, že všechny programy, které z mountpointů čtou nebo se do nich snaží přistoupit prostě zamrznou. Zatuhne prostě celý proces a nejde s tím nic dělat než ručně sestřelit (někdy nejde ani to).

Nelze někde nastavit nějaký timeout, po kterém by se share prostě prohlásil za nedostupný a sám se odpojil? Ten výše zmiňovaný démon se s tím vyrovná - prostě ten soubor nenajde a bude to periodicky zkoušet. Bohužel v případě jeho kompletního zatuhnutí to nejde. On zatuhne i bash, když do složky snažím přistoupit...

Na připojení používám autofs, takže to by problém nebyl. Jen s tím odpojení nedostupného...

Díky

Odpovědi

[petr_p]

CIFS standardně má zapnutý parametr připojení soft, takže proces po vypršení časového limitu dostane chybový kód (přečtěte si mount.cifs(8)).

Co ale může být problém, a je to záležitost individuální potřeby, je velikost časové limitu. Na současných jádrech by měl být 60 sekund.

[ondro]

je to presne tak. Tiez som riesil podobny problem na starsom systeme este bez CIFS.

Upresním, že ten časový limit je 60 sekund ale len pri prvom pokuse o pripojenie k nedostupnemu mountu. Pri druhom pokuse je to uz len polovica 30s. Je to poriadne obmedzujúce, ze sa to neda nastavit ale je to tak.

Jedina moznost ako z toho vonku je pockat na kym system vrati chybu a potom to odmountovat s parametrom -l (umount -l nazov_mount_pointu)

[petr_p]

Nebo si upravit jádro. fs/cifs/connect.c:

static bool
server_unresponsive(struct TCP_Server_Info *server)
{
  /*
   * We need to wait 2 echo intervals to make sure we handle such
   * situations right:
   * 1s  client sends a normal SMB request
   * 2s  client gets a response
   * 30s echo workqueue job pops, and decides we got a response recently
   *     and don't need to send another
   * ...
   * 65s kernel_recvmsg times out, and we see that we haven't gotten
   *     a response in >60s.
   */
  if (server->tcpStatus == CifsGood &&
      time_after(jiffies, server->lstrp + 2 * SMB_ECHO_INTERVAL)) {
    cifs_dbg(VFS, "Server %s has not responded in %d seconds. Reconnecting...\n",
       server->hostname, (2 * SMB_ECHO_INTERVAL) / HZ);
    cifs_reconnect(server);
    wake_up(&server->response_q);
    return true;
  }

  return false;
}

a SMB_ECHO_INTERVAL je definováno v cifsglob.h:

/* SMB echo "timeout" -- FIXME: tunable? */
#define SMB_ECHO_INTERVAL (60 * HZ)

[Milan Uhrák]

odpojovat FS, na němž jsou otevřené soubory je dost drsný, ale chápu, že to jinak nejde..

Možná by stačilo ověřit pingem, (každých 15sek např.) dostupnost serveru, a v případě, že není dostupný, tak volbou force a lazy ( umount -fl ) ten mountpoint zavřít.

[Josef Kufner]

Prostě ty filesystémy odpoj před odpojením serveru.

[Ondra]

No to asi bohužel nejde. Server pracuje bez uživatelské interakce, .. jen je třeba ho prostě někdy odpojit (řeší se na switchi) a po připojení by měl zase pokračovat.

Pokud ale aplikace zatuhnou, tak už se nevzpamatuje a někdo to musí chodit ručně opravit.

[Josef Kufner]

Pokud mu zůstane stejná IP adresa, měl by to po chvilce rozdýchat.