J'ai hérité du code:
Exception :Cannot run program "/bin/chmod": java.io.IOException: error=24, Too many open files Message: Cannot run program "/bin/chmod": java.io.IOException: error=24, Too many open files
4 Réponses :
Il semble peu probable que le processus complète sans fermer les fichiers. Cela pourrait-il se passer dans un très grand nombre de fils? Ou peut-être que certains d'entre eux ne sont pas réellement complétants (c'est-à-dire qu'il est suspendu à Waitfer dans certains cas)?
Sinon, je pense que vous serez coincé avec l'augmentation de la limite des fichiers ouverts. En supposant qu'il s'agisse d'un système de type UNIX, la commande "ulimit" est probablement ce que vous recherchez.
Si vous utilisez Java 6, vous pouvez également essayer les nouvelles setters (pour lire, écrire, exécuter) sur l'objet de fichier. Pourrait être plus lent, mais cela devrait fonctionner.
Je présume que vous exécutez ces commandes chmod dans une boucle - sinon je ne vois pas pourquoi vous obtiendriez autant d'exceptions. Il est possible que vous frappiez une impasse parce que vous ne lisez pas la sortie des processus engendrés. C'est certainement utilisé pour me mordre dans le pré- Changez votre code de code sur le motif ci-dessus: (crédit: Ce site ) et voir Si cela aide la situation. ProcessBuilder , runtime.exeec () jours.
Essayé cela, les mêmes exceptions se produisent
Je pense que j'ai résolu votre réponse à ma réponse dans quelques minutes - en attendant des tests pour vérifier
Ok cueilli le vôtre comme réponse qu'il en avait besoin dans la solution, vérifiez que mon message inclut les lignes supplémentaires nécessaires.
Merci pour les gars de l'aide, cela devrait trier une charge d'étrangeté qui se passe ailleurs à cause de cela.
Utilisation de votre exemple (Vinay) et les fermetures de flux: P>
try{
fw.close();
ProcessBuilder pb = new ProcessBuilder("/bin/chmod", "777", path);
pb.redirectErrorStream(true); // merge stdout, stderr of process
p = pb.start();
InputStreamReader isr = new InputStreamReader(p.getInputStream());
BufferedReader br = new BufferedReader(isr);
String lineRead;
while ((lineRead = br.readLine()) != null) {
// swallow the line, or print it out - System.out.println(lineRead);
}
} catch (Exception ioe) {
Logger.logException(Logger.WARN, ioe.getMessage(), ioe);
} finally {
try {
p.waitFor();//here as there is some snipped code that was causing a different
// exception which stopped it from getting processed
//missing these was causing the mass amounts of open 'files'
p.getInputStream().close();
p.getOutputStream().close();
p.getErrorStream().close();
} catch (Exception ioe) {
Logger.logException(Logger.WARN, ioe.getMessage(), ioe);
}
}
Remarque: N'a toujours pas de sens pourquoi avoir la waitfor et la fermeture des flux d'entrée ne feraient pas bien, mais je suppose que c'est Java ...
Bonne prise, Jim, mais je vois toujours un problème dans votre enfin . Je pense que vous devez avoir chacun des appels dans leur propre Catch , sinon si une exception se produit lors du fait de p.getinputtream.close () Vous échouerez de fermer les autres. Le problème peut sembler avoir disparu maintenant, mais pourrait revenir plus tard.
Avez-vous vraiment besoin de fermer à la fois les flux d'entrée et d'erreur même s'ils sont fusionnés avec redirecterrororstream ? Et avez-vous vraiment besoin de fermer le flux de sortie même si vous ne l'avez jamais utilisé?
Vous auriez besoin de tester les deux et de savoir. Ce post est vraiment vieux, je ne pense pas que le code est même en vie.
Quel est votre système d'exploitation cible (et version). Voir ceci: UNIX.DERKEILER.COM/NEWSGROUPS/COMP .unix.Solaris / 2007-02 / ...
Debian, il semble être éliminé d'uname. sera la dernière stable.