View Full Version : [Win32/C++] Output applicationi lanciate da servizio
sottovento
24-03-2011, 23:00
Gentlemen
dovrei scrivere un servizio che lancia automaticamente (e rilancia in caso di crash) delle applicazioni di tipo console, delle quali non ho il sorgente.
Vorrei salvare l'output di queste applicazioni in uno o piu' file di log, ma sembra non ci sia verso di farlo.
Ho provato a passare l'handle dei file di log alla CreateProcess via STARTUPINFO, cosi' come suggerito in 1000 siti internet, ma non sembra funzionare per niente.
Suggerimenti? Qualsiasi suggerimento che non implichi l'uso di oggetti contundenti sara' ben accetto :D
1000 siti, ma soprattutto anche msdn http://msdn.microsoft.com/en-us/library/ms682499%28v=vs.85%29.aspx
possibile che non vada?
sottovento
25-03-2011, 01:31
1000 siti, ma soprattutto anche msdn http://msdn.microsoft.com/en-us/library/ms682499%28v=vs.85%29.aspx
possibile che non vada?
Provo anche questo. E' piuttosto simile alle prove che ho fatto finora, ma magari le differenze fanno la differenza :D
Purtroppo l'esecuzione come servizio ha delle limitazioni. Cmq grazie, faccio la prova e faccio sapere....
banryu79
25-03-2011, 09:03
Purtroppo l'esecuzione come servizio ha delle limitazioni.
Forse è proprio questo il problema.
Le guide che hai letto nei 1000 siti e in MSDN magari danno per scontato il fatto che il processo padre sia un processo 'normale' e non un servizio.
Infatti dopo breve ricerca ho trovato queste due richieste di aiuto simili alla tua che mi fanno supporre quello che ho appena detto:
Redirect IO when running parent-child processes as Windows Service (http://stackoverflow.com/questions/4980717/redirect-io-when-running-parent-child-processes-as-windows-service)
Windows Server 2008 - Running parent-child process as Windows Service (http://social.msdn.microsoft.com/Forums/en/windowssdk/thread/95b01f31-413d-46a3-9ce2-0ee90c13c91c)
tomminno
25-03-2011, 10:25
Già il problema è che gli standard IO sono disponibili solo per processi che lavorano in modalità interattiva e i servizi non sono processi interattivi (si ci sono i servizi interattivi ma sono formalmente bannati e non più funzionanti da Vista in poi).
Sicuro che hai proprio bisogno di un servizio?
In tal caso dovresti provare con CreateProcessAsUser o CreateProcessWithLogon (se l'utente non ha eseguito il logon), ovviamente devi avere le credenziali di accesso dell'utente sotto cui vuoi far girare l'applicativo.
Quindi dovresti avere il tuo servizio che avvia un tuo processo con CreateProcessAsUser, il tuo processo a questo punto può avviare la console da monitorare con il redirect degli IO funzionante.
Ma a questo punto serve veramente il servizio? Le complicazioni sono veramente tante.
be' ma mica ha detto che deve passargli lo stdin del servizio, lo saprà da solo che non ce l'ha.. ma se il servizio apre un file e lo passa nella startupinfo io non ci vedo niente di male, no? cosa mi sfugge?
sottovento
25-03-2011, 14:47
be' ma mica ha detto che deve passargli lo stdin del servizio, lo saprà da solo che non ce l'ha.. ma se il servizio apre un file e lo passa nella startupinfo io non ci vedo niente di male, no? cosa mi sfugge?
Si, ho provato anche quello, senza risultati. Ammesso, ovviamente, di non aver fatto errori (anche il debug del servizio non e' proprio agevole).
banryu79
25-03-2011, 14:50
Si, ho provato anche quello, senza risultati. Ammesso, ovviamente, di non aver fatto errori (anche il debug del servizio non e' proprio agevole).
Hai già provato con la CreateProcessAsUser citata da tomminno? Avevo incrociato anche io riferimenti a questa API mentre davo la caccia a link vari tra MSDN e thread su StackOverflow che potevano avere a che fare col tuo problema...
sottovento
25-03-2011, 14:55
Già il problema è che gli standard IO sono disponibili solo per processi che lavorano in modalità interattiva e i servizi non sono processi interattivi (si ci sono i servizi interattivi ma sono formalmente bannati e non più funzionanti da Vista in poi).
Si, ne sono consapevole
Sicuro che hai proprio bisogno di un servizio?
E' una richiesta del cliente. Il servizio fa partire una serie di applicazioni che controllano il processo di produzione. Il cliente vuole cosi'. Detto servizio controlla anche che tali applicazioni girino sempre e se una e' andata in crash, la rilancia.
Alcune di queste applicazioni sono sviluppate da altre aziende che non hanno rilasciato i sorgenti, e che scrivono delle informazioni importanti sullo standard output, quindi sarebbe bello poterle salvare, in qualche modo.
Purtroppo il cliente e' fissato con il servizio e non vuole sentire alternative.
In tal caso dovresti provare con CreateProcessAsUser o CreateProcessWithLogon (se l'utente non ha eseguito il logon), ovviamente devi avere le credenziali di accesso dell'utente sotto cui vuoi far girare l'applicativo.
Quindi dovresti avere il tuo servizio che avvia un tuo processo con CreateProcessAsUser, il tuo processo a questo punto può avviare la console da monitorare con il redirect degli IO funzionante.
Ma a questo punto serve veramente il servizio? Le complicazioni sono veramente tante.
Si, lo so. Ho provato con CreateProcessWithLogon() ma devo aver fatto un po' di casino. Le complicazioni sono sicuramente tante e non mi sembra che portino dei grandi vantaggi, ma il cliente non ha intenzione di cambiare idea.
Speriamo bene...
sottovento
25-03-2011, 16:09
Si capisce che ieri ero cotto. Il suggerimento di Tuccio':
http://msdn.microsoft.com/en-us/library/ms682499%28v=vs.85%29.aspx
funziona. Basta mettere questo codice all'interno di un servizio.
Attenzione: se il programma che si va a lanciare e' scritto in Visual Studio ed utilizza le print(), non si vedra' nulla! Questo perche' CRT controlla se lo standard output e' stato rediretto e se lo e', bufferizza (i.e. non fa la flush).
C'e' un articolo su code project (http://www.codeproject.com/KB/threads/RTconsole.aspx) che mostra come superare questo problema. Ovviamente in questo caso si deve lanciare un eseguibile in piu'.
Se il programma console e' invece scritto in altro modo (per esempio, utilizza le std::cout) non ci sono problemi.
Tutto questo dimostra, ancora una volta, che e' meglio andare a casa finite le 8 ore.... :D
Grazie a tutti
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.