Forum >> Principianti >> Intercettare applicazione aperta e poi chiuderla

Pagina: 1

Buonasera, io avrei necessità di intercettare un specifica applicazione e se questa è aperta e non “ulizzata” da più di un “tot” di minuti .... la vorrei chiudere.
Che comandi posso utilizzare per verificare se è aperta e da quanto non la su usa ?
La cosa va fatta su sistema operativo Windows 10 e con Python 3.6 o successivi.

Grazie






--- Ultima modifica di trescon in data 2019-01-12 19:48:12 ---
------
Alberto
Ciao caro, usa psutil e/o subprocess e non dovresti avere grossi problemi.

Prova a scrivere qualche riga (ma proprio due ed hai finito), magari ci guardiamo insieme se hai dei dubbi.

Cya

Ciao, se uno avesse letto i link che hai mandato (letto = cercato di capire un inglese che non sai bene) e non ci avesse capito un TUBO ?

Da cosa potrei partire.

Grazie

------
Alberto
Ciao caro, prima di tutto ti do un consiglio: approfondisci l'inglese. Non solo per la sfera informatica, ma per tutto, almeno l'inglese è una lingua da cui non si può più prescindere. In ambito informatico poi... ancora di più.

Partivo da psutils perché lo trovo un ottimo progetto ed oltretutto è creato da un italiano (supportalo anche per questo. ;)), ma sono gusti personali non è obbligatorio passare da qui. In questa sezione della documentazione si affrontano i processi. Certo puoi usare tante altre librerie, anche già incluse in Python, qui è questione di gusti e di confidenza con la libreria. Nessuno ti vieta di usare os, anzi se trovi più semplice passare da quella fai pure, ma sappi che anche la documentazione ufficiale suggerisce che si tratta di una libreria superata in alcune sue parti, non a caso alcuni funzioni di os sono sostituite in favore di altre librerie, come subprocess. Tornando a noi, con psutils puoi identificare pid, nome processo, etc... e mandare i segnali per terminarli. Ovviamente devi essere in grado di farlo (avere i permessi), ma qui non conta Python o la libreria che usi, ma il sistema sul quale ti muovi, devi comprendere chi o cosa lancia i processi che intendi terminare.

Come ti dicevo con subprocess, che è una scelta più canonica se vogliamo, puoi fare tutto quello che chiedi, utilizzando semplici comandi (Popen). Si tratta di una libreria che è caldamente raccomandata, anzi capirne il suo funzionamento è vitale per il moderno programmatore Python.

Fai qualche prova, sono operazioni molto semplici da apprendere, si tratta di due o tre righe di codice in tutto, insomma cerca di buttarti, poi per altri dubbi siamo qui.

Cya
Direi psutil, non subprocess. Da quello che sembra l'OP ha bisogno di acchiappare al volo un processo che già esiste, indipendentemente dalla sua applicazione python. Subprocess ti serve per avviare (ed eventualmente terminare) processi "da dentro" la tua applicazione python.


Poi certo, se l'OP non è in grado di seguire la documentazione inglese di psutil, allora è un problema, ma temo che sia un problema che gli si ripresenterà di continuo, se vuole programmare.

https://leanpub.com/capirewxpython: Capire wxPython, il mio libro
https://pythoninwindows.blogspot.com: Python in Windows, il mio blog e le mie guide
Subprocess, potrà servire per killare l'applicativo in esecuzione. Ma di windows non ne so.
Buonasera e grazie ancora per i consigli.
Allora , specifico un po’, il processo da verificare lo avvio io (utente) su ogni singola postazionen Windows.

Si tratta del gestionale della ditta dove lavoro.

Nell’Ultimo periodo (3/4 mesi) ho dei problemi di corruzione / perdita relazioni nel database Access del gestionale; il programma apre una sessione del database per ogni pc , usando per server un pc normale(senza Windows server, che eviterebbe questi problemi).

Avendo fatto più verifiche con la software house e non avendo trovato il problema specifico (ho già ordinato del materiale per aggiornare i dispositivi più vecchi) , la software house mi ha consigliato di chiudere il gestionale quando non usato.

Dopo averlo detto a tutti in ditta, averlo ripetuto e qualcuno ancora oggi se ne scorda (addirittura in pausa preanzo mi lasciano aperta la sessione).

Ho pensato quindi di verificare se il programma è aperto , e se non è utilizzato dal più di un tot (es. 5 minuti) chiudere il processo.

Il programma si chiude per prassi con la “x” rossa della finestra di Windows.

Dite che la cosa si può fare , e che magari ci riesco pure io ?



------
Alberto
E' una roba che puoi senz'altro fare (con psultils) ma che francamente NON devi fare.


In primo luogo, killare un processo è diverso, in generale, da "chiudere un'applicazione". Chiudere un'applicazione in modo regolare vuol dire lasciare all'applicazione il tempo e il modo di fare pulizia, chiudere le connessioni aperte, insomma tutto quello che l'applicazione è predisposta a fare nel momento in cui l'utente la "chiude". Killare il processo vuol dire interrompere bruscamente tutto, e ogni possibile attività di chiusura pianificata non ha (di solito) modo di avvenire. Ora, possono esserci sicuramente applicazioni semplici per cui "chiudere" e "killare" sono equivalenti (non so... la Calcolatrice, per dire). Ma nel caso di un gestionale, killare il processo vuol dire quasi sicuramente lasciarsi dietro qualche casino. La cosa buffa è che in questo caso la software house potrebbe addirittura DARE LA COLPA A TE perché killi il processo e fai casini. Anzi, prova a chiedere alla software house se ritengono che killare il processo sia una soluzione valida al problema... lol.


Seconda cosa, tu NON ti fai dire dalla software house che la soluzione è "chiudere il programma". Se ti dicono così, la risposta DEVE essere: "la soluzione è licenziarvi tutti e rivolgerci a una ditta seria". Ma siamo matti? Un gestionale corrompe dati e la soluzione è "chiudere e riavviare"???? Questo è un BACO gravissimo e va risolto, e magari anche alla svelta. Spostare la responsabilità sugli utenti NON è una soluzione, è pura e semplice cialtroneria. Va bene che siamo in Italia e la cultura informatica è pari a zero, ma insomma: questo è un po' tanto anche per gli standard italiani.


Terza cosa, se proprio è utile chiudere di tanto in tanto l'applicazione (e talvolta davvero può essere utile, va a sapere), allora NON deve essere l'utente a garantire che questo avvenga, né tantomeno un killa-processi fatto in casa così alla buona. Deve essere l'applicazione stessa, d'amore e d'accordo con l'amministratore della vostra rete. L'applicazione può prevedere che dopo un po' di tempo di inattività chiude la connessione al database, per esempio. Meglio ancora, l'applicazione dovrebbe contenere un callback che reagisce all'evento di chiusura del sistema operativo, e in questo callback le connessioni vengono chiuse e l'applicazione si chiude correttamente. L'amministratore del sistema deve poi imporre una policy di rete per cui a una certa ora i pc vengono automaticamente spenti, e questo risolve il problema. Tutto questo dovrebbe essere normale amministrazione sia per la software house, sia per il tuo amministratore di rete. Se non lo è... beh, la soluzione è ancora licenziare tutti e rivolgervi a persone serie, guarda un po'.


Quarta cosa, NON può essere vitale che l'utente si ricordi di chiudere il gestionale. "In pausa pranzo si scordano di fare logout, pensa tu!!", ma siamo matti? E' del tutto normale che in pausa pranzo uno si scorda di fare logout. Ci mancherebbe solo. In pausa pranzo uno si ricorda di pranzare, e di rilassarsi un po'. Se è una questione di sicurezza, allora in primo luogo l'interfaccia deve rendere MOLTO semplice ed evidente e immediato fare il logout: un bel pulsantone sempre visibile in alto a sinistra, o qualcosa del genere. Solo a questo punto puoi cominciare a dire agli utenti di farci attenzione. Altrimenti, banalmente deve essere l'applicazione a fare logout dopo un tot di inattività. Contemporaneamente, dovrebbe essere una policy imposta a livello di rete che windows si blocchi dopo un tot di inattività.





Davvero, stai cercando la soluzione più sbagliata al tuo problema. E nel contempo ti stai sbattendo per salvare la software house dai suoi errori. Chiediti se sei pagato per questo, o se dovrebbe essere la software house a muovere il c*, e fammi sapere a che conclusione arrivi...

https://leanpub.com/capirewxpython: Capire wxPython, il mio libro
https://pythoninwindows.blogspot.com: Python in Windows, il mio blog e le mie guide
Grazie Ric Pol, allora non lo farò; il problema è che ho continue corruzzione del dbase e sono costretto a volte 1 volte ogno 3 mesi, a volte 6/7 volte al giorno a fare uscire tutti gli utenti e a lanciare la correzzione/ripristino del dbase.

La cosa richiede di per se 5 minuti, ma a volte non risolve e mi devo rivolgere alla software house x ripristinare le le relazioni tra tabelle (quindi vul dire bloccho per anche piu' di qualche ora).

Il bello è che ne la rete , ne i pc , ne il software ha subito modifiche negli ultimi 6 anni; i problrmi li ho da circa un anno.

Comunque chiudo e lascio stare , visto che farei piu' danni che benefici (a volte pensando di fare bene ....)




Grazie a tutti

------
Alberto
Il bello è che ne la rete , ne i pc , ne il software ha subito modifiche negli ultimi 6 anni; i problrmi li ho da circa un anno.
Questo potrebbe essere più brutto che bello, mi da l'impressione di un qualcosa abbandonato al proprio destino. Comunque sono d'accordo al 1000% con RicPol è un problema che non DEVI assolutamente risolvere tu, è un lavoro che spetta alla software house che vi fornisce il prodotto e/o l'assistenza.

Ho purtroppo sperimentato sulla mia pelle in passato l'inefficienza di un'azienda alla quale ponevo una pezza io e che poi dopo l'ennesimo problema attribuì a me le sue responsabilità, cosa che anche volendo non avrei potuto fare. Ma sapete, a chi è digiuno di informatica ed ha (giustamente) in testa la sua attività e non questi futili problemi tecnici, vuole solo che ci sia efficienza e non considera proprio queste attività Sarà sempre predisposto a credere la grossa realtà, piuttosto che al piccolo smanettone. Lezione che ho registrato e capito, mi costò davvero un sacco di mal di pancia.

Cya



Pagina: 1



Esegui il login per scrivere una risposta.