Che cosa significa "nessuna serratura disponibile"?

Sto provando a impegnarmi su un server SVN. Sul server il repository di sovversione è montato NFS. Quando faccio un commit, ottengo questo messaggio di errore:

svn: Can't get exclusive lock on file '/svn/repo/db/transactions/7802-2.txn/rev-lock': No locks available 

Questo funzionava, e non ci sono stati aggiornamenti / modifiche software su niente. Tuttavia il server NFS si è arrestato in precedenza, quindi potrebbe essere "corrotto" (se è anche qui applicabile)

  • Come configurare un server NFS che memorizza una condivisione di networking?
  • È ansible visualizzare il contenuto di un supporto NFS sottostante senza smontare il contenuto NFS?
  • Auto-assembly di una condivisione di Windows su login Linux AD
  • Rsize predefinito e wsize per nfs v3
  • Le migliori pratiche per la migrazione a nuove SAN
  • Come faccio a smontare forzatamente quando ho maniglie di file nfs stanti?
  • Come si installa una condivisione NFS in Windows 7?
  • VMware ESXi: process di pausa di VM (per consentire l'avvio di archiviazione NFS), eventuali effetti collaterali sui database, AD, casi speciali?
  • 5 Solutions collect form web for “Che cosa significa "nessuna serratura disponibile"?”

    Qui ci sono poche possibilità:

    1. L'account utente che esegue l'aggiornamento SVN potrebbe non avere l'authorization di aggiornamento nella directory del repository
    2. Il file system NFS in cui è memorizzato il repository può essere pieno
    3. Il daemon di block (lockd) potrebbe non essere in esecuzione sul server NFS.

    UPDATE: dopo l'aggiornamento alla domanda, sospetto # 3. Assicurarsi che il lockd sia impostato per avviarsi quando il server NFS viene riavviato.

    Assicurarsi che il server NFS supporti le serrature; potrebbe essere necessario triggersre processi aggiuntivi sul server NFS per eseguirlo; vedere rpc.lockd (8) e rpc.statd (8) .

    Inoltre, se il server NFS è stato riavviato di recente, potrebbe essere necessario un assembly NFS stazionario o addirittura parziale. Provare a smontare e rimontare anche il supporto NFS.

    EDIT: in base all'altra domanda , sembra che il lockd non sia stato avviato dopo che il server NFS è stato recuperato.

    Ci sono una serie di alternative citate in questa ricerca di Google per i termini che hai citato in precedenza .

    Alcune delle opzioni elencate sono: dischi completi, problemi di autorizzazioni, "appesi" o "bloccati" i processi svnserve e le operazioni di suspended … Potrebbe essere necessario provare una serie di questi diversi problemi per vedere cosa esattamente il problema è nel tuo caso.

    Sembra che utilizzi la back-end SVN bsddb? Puoi provare a migrare il repository al back-end di fsfs (l'impostazione predefinita da diversi anni). Ha, nella mia esperienza e da quello di molti altri che conosco, dimostrato più affidabile di bsddb. Anche se si desidera ricercare come interagisce con NFS – non l'ho usata in NFS.

    Un'altra opzione che si desidera considerare è allontanarsi dall'utilizzo di SVN su NFS e invece eseguirlo su SSH su un server con archivio SVN localmente memorizzato. Questo è il modo in cui facciamo tutti i nostri lavori SVN, con il back-end di fsfs e non ricordo l'ultima volta che avevamo problemi di repository SVN.

    Sean

    se si utilizza SVN con NFS su debian

    eseguire questo:

     /etc/init.d/portmap restart 

    Ho avuto problemi simili qui, la mia a causa dei montanti NFS del vagabondo. Andando da ciò che Tel Janin ha detto sopra, ho riavviato rpcbind con sudo service rpcbind restart sul mio ospite OS. Questo ha appeso il mio vm. Ho riavviato quello, che mi ha dato un errore NFS crittico failed to start with result 'dependency' è failed to start with result 'dependency' . Ha funzionato però e sono ora un felice camper.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.