Tempo limite do waitforexit do processo do powershell
Processo de espera.
Neste artigo.
Descrição.
O cmdlet Wait-Process aguarda que um ou mais processos em execução sejam interrompidos antes de aceitar a entrada. No console do Windows PowerShell, esse cmdlet suprime o prompt de comando até que os processos sejam interrompidos. Você pode especificar um processo pelo nome do processo ou ID do processo (PID) ou canalizar um objeto de processo para Wait-Process.
O Wait-Process funciona apenas em processos em execução no computador local.
Exemplo 1: Pare um processo e aguarde.
Este exemplo interrompe o processo do Bloco de Notas e aguarda que o processo seja interrompido antes de continuar com o próximo comando.
O primeiro comando usa o cmdlet Get-Process para obter o ID do processo do Bloco de Notas. Ele armazena o ID na variável $ nid.
O segundo comando usa o cmdlet Stop-Process para interromper o processo com o ID armazenado em $ nid.
O terceiro comando usa o Wait-Process para aguardar até que o processo do Notepad seja interrompido. Ele usa o parâmetro Id do Wait-Process para identificar o processo.
Exemplo 2: especificando um processo.
Esses comandos mostram três métodos diferentes de especificação de um processo para Wait-Process. O primeiro comando obtém o processo do Bloco de Notas e o armazena na variável $ p.
O segundo comando usa o parâmetro Id, o terceiro comando usa o parâmetro Name e o quarto comando usa o parâmetro InputObject.
Esses comandos têm os mesmos resultados e podem ser usados de forma intercambiável.
Exemplo 3: Aguarde os processos por um tempo especificado.
Esse comando aguarda 30 segundos para que os processos do Outlook e do Winword parem. Se ambos os processos não forem interrompidos, o cmdlet exibirá um erro de não finalização e o prompt de comando.
Parâmetros obrigatórios.
Especifica os IDs do processo dos processos. Para especificar vários IDs, use vírgulas para separar os IDs. Para localizar o PID de um processo, digite Get-Process.
Como iniciar um processo e esperar para completar? #PowerShell.
Como iniciar um processo e esperar que ele seja concluído? #PowerShell.
Um dos novos Cmdlets apresentados com o PowerShell v2 é chamado Start-Process. Ele inicia um processo no computador local e, opcionalmente, aguarda a conclusão se você usar o parâmetro de Comutação Wait do Cmdlet. Start-Process é implementado usando o método Start da classe System. Diagnostics. Process do NET Framework.
A primeira versão do Windows PowerShell não veio com um cmdlet como Start-Process. A função abaixo, também chamada de Start-Process, aguarda a conclusão do processo por padrão. Além disso, a função aguardará que todos os processos filho do processo sejam concluídos se você usar o parâmetro de opção WaitForChildProcesses. Além disso, a função não esperará infinitamente, pois suporta um parâmetro Timeout. Por padrão, ele aguardará 600 segundos para que um processo (e processos filho) seja concluído. Como o Start-Process de Posh v2, a função usa a classe System. Diagnostics. Process NET Framework.
Então, por que esperar por processos filhos? Se for importante aguardar a conclusão do processo, talvez esperar que seus processos filhos concluam também. Por exemplo, o instalador do Oracle chama o Java e termina enquanto o Java Runtime ainda está ocupado instalando o software.
Além disso, considero um tempo limite como obrigatório para evitar uma espera infinita devido a um processo de suspensão (ou processo filho).
BTW, é claro que você pode usar a função no PowerShell v2 também. Lembre-se de que a função tem duas vantagens: aguardar processos filhos e tempo limite!
Tempo limite do waitforexit do processo do Powershell
Eu tenho uma ferramenta que pode demorar muito tempo para executar, mais do que o tempo limite padrão do Powershell para iniciar o processo de 600 segundos. Então, estou tentando encontrar uma maneira de aumentar esse tempo limite. Se meu código de teste for executado assim sem um tempo limite especificado:
Em seguida, o script aguarda corretamente que o comando seja executado e saia:
PS U: \ Meus documentos \ Desenvolvimento \ PowerShell & gt; \ ping_test. ps1.
No entanto, se eu tentar adicionar um tempo limite ao comando:
O processo de ping ainda é iniciado, mas imediatamente retorna ao script do powershell e eu recebo esta saída:
Tempo limite do waitforexit do processo do Powershell
Eu estou tentando iniciar um processo e pegue o StandardOutput e StandardError usando EventHandlers e BeginOutputReadLine. Eu posso iniciar o processo, mas recebo.
Exceção chamando & quot; BeginOutputReadLine & quot; com & quot; 0 & quot; argumento (s): & quot; Não é possível misturar operação síncrona e assíncrona no fluxo do processo. & quot;
Aqui está a minha função de lançamento:
Estou violando o modelo de segmentação Powershell? Obrigado!
Eu estou tentando iniciar um processo e pegue o StandardOutput e StandardError usando EventHandlers e BeginOutputReadLine. Eu posso iniciar o processo, mas recebo.
Exceção chamando & quot; BeginOutputReadLine & quot; com & quot; 0 & quot; argumento (s): & quot; Não é possível misturar operação síncrona e assíncrona no fluxo do processo. & quot;
A mensagem de erro está dizendo o que você está fazendo errado.
Você não pode atribuir funções a um processo síncrono. As funções não são delegadas, portanto, não funcionarão. Você precisa usar um modelo de evento ou usar a variação do asynch.
Use isso como um modelo:
Marcado como Resposta Oliver Lipkau Moderator quarta-feira, 12 de outubro de 2011 2:32.
Todas as respostas.
Eu acredito que você tenha alguns erros no seu código. Eu sou a pessoa mais humilde que você já conheceu.
Eu estou tentando iniciar um processo e pegue o StandardOutput e StandardError usando EventHandlers e BeginOutputReadLine. Eu posso iniciar o processo, mas recebo.
Exceção chamando & quot; BeginOutputReadLine & quot; com & quot; 0 & quot; argumento (s): & quot; Não é possível misturar operação síncrona e assíncrona no fluxo do processo. & quot;
A mensagem de erro está dizendo o que você está fazendo errado.
Você não pode atribuir funções a um processo síncrono. As funções não são delegadas, portanto, não funcionarão. Você precisa usar um modelo de evento ou usar a variação do asynch.
Use isso como um modelo:
Marcado como Resposta Oliver Lipkau Moderator quarta-feira, 12 de outubro de 2011 2:32.
Ok, eu não entendi a implementação do BeginOutputReadline. Eu pensei que isso funcionaria com o. WaitForExit - olhando para ele agora, vejo por que isso não acontece.
Em VB. NET, eu sei como 1) gerar threads para lidar com isso e eu sei que você pode colocar o processo em um loop 2) até que seja concluído como uma forma de lidar com isso.
Eu não quero fazer # 2. Existe uma maneira multithreaded ou assíncrona para ler a saída de um determinado processo como o processo está gerando?
Ok, eu não entendi a implementação do BeginOutputReadline. Eu pensei que isso funcionaria com o. WaitForExit - olhando para ele agora, vejo por que isso não acontece.
Em VB. NET, eu sei como 1) gerar threads para lidar com isso e eu sei que você pode colocar o processo em um loop 2) até que seja concluído como uma forma de lidar com isso.
Eu não quero fazer # 2. Existe uma maneira multithreaded ou assíncrona para ler a saída de um determinado processo como o processo está gerando?
Na verdade, a menos que você queira criar um delegado de evento. Mas então este é o PowerShell, não é VB. NET.
Você pode começar aqui e ver se o evento que você está procurando pode ser "viciado"
help Register-ObjectEvent - full.
A resposta marcada não resolve o problema com o qual o OP está lutando - isto é, redirecionando StdErr e StdOut e sofre com o bug de conflito discutido aqui:
& quot; Uma condição de deadlock pode resultar se o processo pai chama p. WaitForExit antes de p. StandardOutput. ReadToEnd e o processo filho grava texto suficiente para preencher o fluxo redirecionado. O processo pai aguardaria indefinidamente que o processo filho fosse encerrado. O processo filho esperaria indefinidamente que o pai lesse o fluxo StandardOutput completo. & Quot;
Eu também estou tentando a melhor resposta para fazer este trabalho no Powershell, mas todos os exemplos de código que estou executando em que usam System. Diagnostics. Process no powersehll estão replicando o deadlock nesta implementação ou não estão redirecionando stderr e stdout.
A solução que estou usando usa o cmdlet Start-Process da seguinte maneira:
Não é uma ótima solução, pois só redirecionará stdout e stderr para um arquivo de texto. mas funcionará o tempo todo e redirecionará stdout e stderr.
Se formos usar saída redirecionada, não usaremos espera. Esse foi o design de CreateProcess desde o NT4.
O uso de arquivos para capturar a saída funcionará porque um fluxo é anexado e envia uma leitura constante para o fluxo de saída. O fluxo de saída nunca é suspenso. Yu não pode fazer isso em um loop de código. O córrego corre o contexto do sistema do pecado eu acredito e começarei sempre a possibilidade de ler. A espera está no seu thread, então você não pode fazer uma leitura manual. É um impasse como afirmado.
O uso da leitura do console é geralmente porque estamos procurando por um prompt. Nesse caso, nunca esperamos a conclusão. O código ZTHe provavelmente será enviado para 'quit' e nós iremos verificar o processo e girá-lo até que ele seja desligado.
A questão aqui é que nós não podemos gerar um thead. Em VB ou C #, C nós apenas usamos threads separe para IO e um para espera. Melhor ainda, eu usaria um semáforo como ele pode capturar dinamicamente um desligamento inesperado.
Talvez a próxima versão do PowerSHell tenha boas possibilidades de multithreading.
Essa é apenas mais uma lição de que o Powershell é uma linguagem de script, não uma linguagem de programação e, por mais poderosa que seja, existem armadilhas.
O código de exemplo da Microsoft simplesmente não é abrangente o suficiente para um hacker Powerhell perceber que eles não podem chegar lá a partir daqui. Isso é o que me pegou e acredito no OP também, porque houve uma certa expectativa de que BeginOutputReadline implementou a mágica para fazer com que funcionasse threads que teriam resolvido o problema de bloqueio. Não, então acabamos aqui.
E uma ligeira correcção ao meu código - deixei de fora o sinalizador - wait que é necessário para o resto do código funcionar:
Essa é apenas mais uma lição de que o Powershell é uma linguagem de script, não uma linguagem de programação e, por mais poderosa que seja, existem armadilhas.
O código de exemplo da Microsoft simplesmente não é abrangente o suficiente para um hacker Powerhell perceber que eles não podem chegar lá a partir daqui. Isso é o que me pegou e acredito no OP também, porque houve uma certa expectativa de que BeginOutputReadline implementou a mágica para fazer com que funcionasse threads que teriam resolvido o problema de bloqueio. Não, então acabamos aqui.
E uma ligeira correcção ao meu código - deixei de fora o sinalizador - wait que é necessário para o resto do código funcionar:
Certo. O PowerShell é propositadamente limitado para torná-lo mais seguro para a população em geral e para reduzir os problemas que ocorrem com as linguagens compiladas.
Sim - o sinalizador de espera ajudaria, pois o arquivo pode não ter terminado o spool antes de o programa ser encerrado.
O Start-Process é um wrapper fraco na API do processo, mas protege os desavisados dos deadlocks porque você não pode redirecionar a entrada, exceto de um arquivo.
Você não precisa de esperar para redirecionar. Você precisa esperar pelos arquivos e como uma maneira fácil de detectar a terminação. Usando a API, isso tem que ser feito pesquisando o objeto do processo ou extraindo a saída e aguardando que o processo envie sua mensagem de término, em seguida, girando no status.
Isso é tudo demais para os administradores de scripts e, como você apontou, os deixará sem problemas.
Processo de espera.
Neste artigo.
Descrição.
O cmdlet Wait-Process aguarda que um ou mais processos em execução sejam interrompidos antes de aceitar a entrada. No console do Windows PowerShell, esse cmdlet suprime o prompt de comando até que os processos sejam interrompidos. Você pode especificar um processo pelo nome do processo ou ID do processo (PID) ou canalizar um objeto de processo para Wait-Process.
O Wait-Process funciona apenas em processos em execução no computador local.
Exemplo 1: Pare um processo e aguarde.
Este exemplo interrompe o processo do Bloco de Notas e aguarda que o processo seja interrompido antes de continuar com o próximo comando.
O primeiro comando usa o cmdlet Get-Process para obter o ID do processo do Bloco de Notas. Ele armazena o ID na variável $ nid.
O segundo comando usa o cmdlet Stop-Process para interromper o processo com o ID armazenado em $ nid.
O terceiro comando usa o Wait-Process para aguardar até que o processo do Notepad seja interrompido. Ele usa o parâmetro Id do Wait-Process para identificar o processo.
Exemplo 2: especificando um processo.
Esses comandos mostram três métodos diferentes de especificação de um processo para Wait-Process. O primeiro comando obtém o processo do Bloco de Notas e o armazena na variável $ p.
O segundo comando usa o parâmetro Id, o terceiro comando usa o parâmetro Name e o quarto comando usa o parâmetro InputObject.
Esses comandos têm os mesmos resultados e podem ser usados de forma intercambiável.
Exemplo 3: Aguarde os processos por um tempo especificado.
Esse comando aguarda 30 segundos para que os processos do Outlook e do Winword parem. Se ambos os processos não forem interrompidos, o cmdlet exibirá um erro de não finalização e o prompt de comando.
Parâmetros obrigatórios.
Especifica os IDs do processo dos processos. Para especificar vários IDs, use vírgulas para separar os IDs. Para localizar o PID de um processo, digite Get-Process.
Eu estou tentando iniciar um processo e pegue o StandardOutput e StandardError usando EventHandlers e BeginOutputReadLine. Eu posso iniciar o processo, mas recebo.
Exceção chamando & quot; BeginOutputReadLine & quot; com & quot; 0 & quot; argumento (s): & quot; Não é possível misturar operação síncrona e assíncrona no fluxo do processo. & quot;
Aqui está a minha função de lançamento:
Estou violando o modelo de segmentação Powershell? Obrigado!
Eu estou tentando iniciar um processo e pegue o StandardOutput e StandardError usando EventHandlers e BeginOutputReadLine. Eu posso iniciar o processo, mas recebo.
Exceção chamando & quot; BeginOutputReadLine & quot; com & quot; 0 & quot; argumento (s): & quot; Não é possível misturar operação síncrona e assíncrona no fluxo do processo. & quot;
A mensagem de erro está dizendo o que você está fazendo errado.
Você não pode atribuir funções a um processo síncrono. As funções não são delegadas, portanto, não funcionarão. Você precisa usar um modelo de evento ou usar a variação do asynch.
Use isso como um modelo:
Marcado como Resposta Oliver Lipkau Moderator quarta-feira, 12 de outubro de 2011 2:32.
Todas as respostas.
Eu acredito que você tenha alguns erros no seu código. Eu sou a pessoa mais humilde que você já conheceu.
Eu estou tentando iniciar um processo e pegue o StandardOutput e StandardError usando EventHandlers e BeginOutputReadLine. Eu posso iniciar o processo, mas recebo.
Exceção chamando & quot; BeginOutputReadLine & quot; com & quot; 0 & quot; argumento (s): & quot; Não é possível misturar operação síncrona e assíncrona no fluxo do processo. & quot;
A mensagem de erro está dizendo o que você está fazendo errado.
Você não pode atribuir funções a um processo síncrono. As funções não são delegadas, portanto, não funcionarão. Você precisa usar um modelo de evento ou usar a variação do asynch.
Use isso como um modelo:
Marcado como Resposta Oliver Lipkau Moderator quarta-feira, 12 de outubro de 2011 2:32.
Ok, eu não entendi a implementação do BeginOutputReadline. Eu pensei que isso funcionaria com o. WaitForExit - olhando para ele agora, vejo por que isso não acontece.
Em VB. NET, eu sei como 1) gerar threads para lidar com isso e eu sei que você pode colocar o processo em um loop 2) até que seja concluído como uma forma de lidar com isso.
Eu não quero fazer # 2. Existe uma maneira multithreaded ou assíncrona para ler a saída de um determinado processo como o processo está gerando?
Ok, eu não entendi a implementação do BeginOutputReadline. Eu pensei que isso funcionaria com o. WaitForExit - olhando para ele agora, vejo por que isso não acontece.
Em VB. NET, eu sei como 1) gerar threads para lidar com isso e eu sei que você pode colocar o processo em um loop 2) até que seja concluído como uma forma de lidar com isso.
Eu não quero fazer # 2. Existe uma maneira multithreaded ou assíncrona para ler a saída de um determinado processo como o processo está gerando?
Na verdade, a menos que você queira criar um delegado de evento. Mas então este é o PowerShell, não é VB. NET.
Você pode começar aqui e ver se o evento que você está procurando pode ser "viciado"
help Register-ObjectEvent - full.
A resposta marcada não resolve o problema com o qual o OP está lutando - isto é, redirecionando StdErr e StdOut e sofre com o bug de conflito discutido aqui:
& quot; Uma condição de deadlock pode resultar se o processo pai chama p. WaitForExit antes de p. StandardOutput. ReadToEnd e o processo filho grava texto suficiente para preencher o fluxo redirecionado. O processo pai aguardaria indefinidamente que o processo filho fosse encerrado. O processo filho esperaria indefinidamente que o pai lesse o fluxo StandardOutput completo. & Quot;
Eu também estou tentando a melhor resposta para fazer este trabalho no Powershell, mas todos os exemplos de código que estou executando em que usam System. Diagnostics. Process no powersehll estão replicando o deadlock nesta implementação ou não estão redirecionando stderr e stdout.
A solução que estou usando usa o cmdlet Start-Process da seguinte maneira:
Não é uma ótima solução, pois só redirecionará stdout e stderr para um arquivo de texto. mas funcionará o tempo todo e redirecionará stdout e stderr.
Se formos usar saída redirecionada, não usaremos espera. Esse foi o design de CreateProcess desde o NT4.
O uso de arquivos para capturar a saída funcionará porque um fluxo é anexado e envia uma leitura constante para o fluxo de saída. O fluxo de saída nunca é suspenso. Yu não pode fazer isso em um loop de código. O córrego corre o contexto do sistema do pecado eu acredito e começarei sempre a possibilidade de ler. A espera está no seu thread, então você não pode fazer uma leitura manual. É um impasse como afirmado.
O uso da leitura do console é geralmente porque estamos procurando por um prompt. Nesse caso, nunca esperamos a conclusão. O código ZTHe provavelmente será enviado para 'quit' e nós iremos verificar o processo e girá-lo até que ele seja desligado.
A questão aqui é que nós não podemos gerar um thead. Em VB ou C #, C nós apenas usamos threads separe para IO e um para espera. Melhor ainda, eu usaria um semáforo como ele pode capturar dinamicamente um desligamento inesperado.
Talvez a próxima versão do PowerSHell tenha boas possibilidades de multithreading.
Essa é apenas mais uma lição de que o Powershell é uma linguagem de script, não uma linguagem de programação e, por mais poderosa que seja, existem armadilhas.
O código de exemplo da Microsoft simplesmente não é abrangente o suficiente para um hacker Powerhell perceber que eles não podem chegar lá a partir daqui. Isso é o que me pegou e acredito no OP também, porque houve uma certa expectativa de que BeginOutputReadline implementou a mágica para fazer com que funcionasse threads que teriam resolvido o problema de bloqueio. Não, então acabamos aqui.
E uma ligeira correcção ao meu código - deixei de fora o sinalizador - wait que é necessário para o resto do código funcionar:
Essa é apenas mais uma lição de que o Powershell é uma linguagem de script, não uma linguagem de programação e, por mais poderosa que seja, existem armadilhas.
O código de exemplo da Microsoft simplesmente não é abrangente o suficiente para um hacker Powerhell perceber que eles não podem chegar lá a partir daqui. Isso é o que me pegou e acredito no OP também, porque houve uma certa expectativa de que BeginOutputReadline implementou a mágica para fazer com que funcionasse threads que teriam resolvido o problema de bloqueio. Não, então acabamos aqui.
E uma ligeira correcção ao meu código - deixei de fora o sinalizador - wait que é necessário para o resto do código funcionar:
Certo. O PowerShell é propositadamente limitado para torná-lo mais seguro para a população em geral e para reduzir os problemas que ocorrem com as linguagens compiladas.
Sim - o sinalizador de espera ajudaria, pois o arquivo pode não ter terminado o spool antes de o programa ser encerrado.
O Start-Process é um wrapper fraco na API do processo, mas protege os desavisados dos deadlocks porque você não pode redirecionar a entrada, exceto de um arquivo.
Você não precisa de esperar para redirecionar. Você precisa esperar pelos arquivos e como uma maneira fácil de detectar a terminação. Usando a API, isso tem que ser feito pesquisando o objeto do processo ou extraindo a saída e aguardando que o processo envie sua mensagem de término, em seguida, girando no status.
Isso é tudo demais para os administradores de scripts e, como você apontou, os deixará sem problemas.
Processo de espera.
Neste artigo.
Descrição.
O cmdlet Wait-Process aguarda que um ou mais processos em execução sejam interrompidos antes de aceitar a entrada. No console do Windows PowerShell, esse cmdlet suprime o prompt de comando até que os processos sejam interrompidos. Você pode especificar um processo pelo nome do processo ou ID do processo (PID) ou canalizar um objeto de processo para Wait-Process.
O Wait-Process funciona apenas em processos em execução no computador local.
Exemplo 1: Pare um processo e aguarde.
Este exemplo interrompe o processo do Bloco de Notas e aguarda que o processo seja interrompido antes de continuar com o próximo comando.
O primeiro comando usa o cmdlet Get-Process para obter o ID do processo do Bloco de Notas. Ele armazena o ID na variável $ nid.
O segundo comando usa o cmdlet Stop-Process para interromper o processo com o ID armazenado em $ nid.
O terceiro comando usa o Wait-Process para aguardar até que o processo do Notepad seja interrompido. Ele usa o parâmetro Id do Wait-Process para identificar o processo.
Exemplo 2: especificando um processo.
Esses comandos mostram três métodos diferentes de especificação de um processo para Wait-Process. O primeiro comando obtém o processo do Bloco de Notas e o armazena na variável $ p.
O segundo comando usa o parâmetro Id, o terceiro comando usa o parâmetro Name e o quarto comando usa o parâmetro InputObject.
Esses comandos têm os mesmos resultados e podem ser usados de forma intercambiável.
Exemplo 3: Aguarde os processos por um tempo especificado.
Esse comando aguarda 30 segundos para que os processos do Outlook e do Winword parem. Se ambos os processos não forem interrompidos, o cmdlet exibirá um erro de não finalização e o prompt de comando.
Parâmetros obrigatórios.
Especifica os IDs do processo dos processos. Para especificar vários IDs, use vírgulas para separar os IDs. Para localizar o PID de um processo, digite Get-Process.
Комментарии
Отправить комментарий