Archives For ManageEngine

Quello nel titolo è un errore che potresti ritrovarti di fronte se lanci lo script di aggiornamento di ServiceDesk manualmente. Spiego meglio: lanciando con il classico doppio clic l’Update Manager potresti ritrovarti davanti al nulla più completo, una finestra che si apre solo per un secondo e che si richiude subito dopo. Per questo motivo apri un prompt dei comandi, ti sposti nella cartella di Manage Engine e quindi nella relativa scripts in bin, lanciando il UpdMgr.bat per arrivare a questo:

Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

ServiceDesk: Could not reserve enough space for object heap

Non sei tu il problema, sono io!” (cit.). Sì perché è proprio così, apparentemente la macchina non ha sufficienti risorse da riservare all’Update Manager per le sue operazioni. Per questo motivo rimani fermo al palo a meno di andare a mettere mano a quella richiesta di risorse che si trova all’interno dello script batch (C:\ManageEngine\ServiceDesk\bin\scripts\UpdMgr.bat), e più precisamente in questa istruzioni che occupa (a oggi) la penultima riga del file:

"%JAVA_HOME%\bin\java" -Xmx2512m %JAVA_OPTS% -Dtier-type=BE -Djava.library.path=.\lib\native -Dtier-id=BE1 com.adventnet.tools.update.installer.UpdateManager -u conf %*

Da quanto imparato e provato sul campo, ti basterà andare a variare la memoria richiesta per l’ambiente virtuale (JVM), portando quel -Xmx2512m a –Xmx512m, trasformando quindi l’istruzione in qualcosa di molto simile (se non identico) a questo:

"%JAVA_HOME%\bin\java" -Xmx512m %JAVA_OPTS% -Dtier-type=BE -Djava.library.path=.\lib\native -Dtier-id=BE1 com.adventnet.tools.update.installer.UpdateManager -u conf %*

Come discusso su stackoverflow.com/questions/4401396/could-not-reserve-enough-space-for-object-heap, il parametro -XX:MaxHeapSize=512m può essere accorciato nel più conciso -Xmx512m, all’interno del quale tu puoi tranquillamente variare il valore dei megabyte messi a disposizione della JVM, per evitare di ottenere l’errore riportato in apertura articolo. Io mi sono fermato a 512 MB messi a disposizione del processo, e sono più che sufficienti per eseguire l’Update Manager, ho poi modificato nuovamente il batch e riportato il valore al suo stato originale (nel frattempo ci sarà modo di riavviare la macchina e scaricarla un po’).

Buon lavoro.

×

Pillole

Le pillole sono articoli di veloce lettura dedicati a notizie, script o qualsiasi altra cosa possa essere "divorata e messa in pratica" con poco. Uno spazio del blog riservato ai post "a bruciapelo"!
Condividi l'articolo con i tuoi contatti:

ServiceDesk Plus è solito forzare un backup completo dei dati dell’applicazione (database e allegati delle mail ricevute) ogni volta che si installa una major-version del software. Nonostante questa sia un’operazione assolutamente lecita e ragionevole (nonché caldamente consigliata anche dal sottoscritto), in alcuni casi potrebbe rivelarsi deleteria e ripetitiva, soprattutto se l’applicazione è ospitata su macchina virtuale (con snapshot appena eseguita) o nel caso in cui tu abbia deciso di lanciare un backup manuale subito prima dell’upgrade.

HDD - Hard Disk, Spazio disco

Per questo motivo esiste un piccolo trucco, previsto dagli sviluppatori, che ti permette di saltare questo passaggio obbligatorio. Ti basterà andare a ritoccare il file UpdateManager.bat che trovi nella cartella C:\ManageEngine\ServiceDesk\bin (ammesso che tu abbia scelto la root di C: per ospitare il software) con un editor di testo qualsiasi (il mio consiglio è sempre quello: Notepad++ o Atom) e riportare in coda il parametro -DSkipBackUp=true, ottenendo così un risultato molto simile (se non identico) al seguente:

@echo off
call RunAsAdmin.exe scripts\UpdMgr.bat -DSkipBackUp=true

Salva il file batch e lancia ora l’Update Manager, dandogli in pasto il Service Pack che ti permetterà di aggiornare il tuo software. Dovresti arrivare a una schermata come questa, che ti permetterà di proseguire ignorando il backup precedentemente obbligatorio:

ServiceDesk: bloccare il backup forzato durante un aggiornamento 1

Fatto ciò, puoi in qualsiasi momento andare a eliminare quel parametro dal file batch, per evitare che in futuro tu vada a saltare a piè pari una fase importante di qualsivoglia upgrade, il backup dei tuoi preziosi –e mai troppo messi al sicuro– dati.

Buon lavoro!


fonte: pitstop.manageengine.com/portal/community/topic/upgrade-to-9400-without-no-backup

×

Pillole

Le pillole sono articoli di veloce lettura dedicati a notizie, script o qualsiasi altra cosa possa essere "divorata e messa in pratica" con poco. Uno spazio del blog riservato ai post "a bruciapelo"!
Condividi l'articolo con i tuoi contatti:

ServiceDesk Plus, come tanti altri software (Microsoft Windows ne è un esempio comune e pratico), permette di effettuare rollback di versione nel caso in cui qualcosa vada storto o non convinca gli utilizzatori post-upgrade. L’operazione viene permessa tramite la finestra dell’Update Manager, la medesima che utilizzi per installare un Service Pack di programma, basta dare un’occhiata alla parte bassa della finestra, solitamente “lasciata lì e ignorata”:

ServiceDesk: recuperare lo spazio disco occupato dagli aggiornamenti

Selezionando un SP e facendo clic su Uninstall… potrai tornare indietro alla versione interessata, e fin qui tutto bene (dirai). Se la tua intenzione è invece quella di fare pulizia perché gli aggiornamenti funzionano correttamente, sappi che puoi recuperare lo spazio occupato da quelle patch in qualsiasi momento, semplicemente andando a cancellare i file che si trovano nella cartella ManageEngine\ServiceDesk\Patch (all’interno del disco fisso di installazione del programma). Puoi fare pulizia completa, ciò non impatterà ServiceDesk Plus, che non dovrà neanche essere fermato:

ServiceDesk: recuperare lo spazio disco occupato dagli aggiornamenti 1

La questione è stata discussa più volte all’interno del forum della Community, ti basta una ricerca per arrivare a molteplici risultati simili a questo (vecchissimo, ma ancora valido): pitstop.manageengine.com/portal/community/topic/safe-to-delete-servicedesk-patch-folder-18-10-2012.

Buon lavoro.

×

Pillole

Le pillole sono articoli di veloce lettura dedicati a notizie, script o qualsiasi altra cosa possa essere "divorata e messa in pratica" con poco. Uno spazio del blog riservato ai post "a bruciapelo"!
Condividi l'articolo con i tuoi contatti:

Ciao. Ti sei ritrovato davanti all’errore “psql: FATAL: no pg_hba.conf entry for host “::1”, user “postgres”, database “servicedesk”,SSL off” mentre cercavi di collegarti via prompt al database del tuo ServiceDesk Plus? Anche io. Poi ho scoperto che si tratta di un errore riconosciuto da documentazione ufficiale, e che ti basta modificare un file di configurazione per poter tornare sulla retta via.

ServiceDesk: Error While connecting postgresDB

Di come collegarti via prompt al database del tuo software di supporto te ne avevo già parlato qui:

ServiceDesk: jespa.log sempre più grande?

Per risolvere il problema che ho riportato in apertura “pillola” devi invece ritoccare il file pg_hba.conf che trovi sotto ManageEngine\ServiceDesk\pgsql\data, andando a togliere il cancelletto di commento in corrispondenza dei valori specificati sotto la riga # IPv6 local connections.

La situazione che dovresti trovare è teoricamente questa:

# IPv6 local connections:
#host all all ::1/128 trust

Tu dovrai trasformarla in questa:

# IPv6 local connections:
host all all ::1/128 trust

Salva il file e riprova a connetterti al database, non dovresti ora riscontrare ostacoli.

È tutto spiegato qui: kbase.servicedeskplusmsp.com/troubleshooting/2014/02/28/error-while-connecting-postgresdb.

Buon lavoro!

×

Pillole

Le pillole sono articoli di veloce lettura dedicati a notizie, script o qualsiasi altra cosa possa essere "divorata e messa in pratica" con poco. Uno spazio del blog riservato ai post "a bruciapelo"!
Condividi l'articolo con i tuoi contatti:

Avevamo già parlato di ServiceDesk Plus e tuning qualche tempo fa, quando la piattaforma principale girava su MySQL (se la usavi già da qualche tempo), ormai andato completamente fuori supporto secondo lo sviluppatore del software (è stato richiesto il passaggio a PostgreSQL per continuare a ottenere supporto):

Pulizia e Tuning di ServiceDesk Plus (MySQL)

Cosa cambia dal punto di vista del tuning dell’installazione con PgSQL?

Tuning di ServiceDesk Plus (PostgreSQL)

Nulla a livello di Wrapper Java, almeno rispetto alla precedente volta quando si parlava di modifica per macchine con almeno (o più) di 4 GB di RAM, che è poi lo stesso concetto di base che riguarda l’ulteriore modifica del file di configurazione del Postgres suggerito sempre all’interno della community del prodotto (ServiceDesk, nda).

Ferma il servizio di ServiceDesk prima di continuare ed effettua un backup dei tuoi attuali dati (consigliato uno Snaphost della macchina, se virtuale).

Ti ripropongo ora il passaggio relativo al Wrapper del precedente articolo:

Il file di configurazione del Wrapper Java è quello che trovi in C:\ManageEngine\ServiceDesk\server\default\conf\wrapper.conf, da ritoccare sui due valori suggeriti:

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=128

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=256

a (nel caso della mia macchina con più di 4GB di RAM, occhio quindi alla tua):

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=256

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=1024

[…]

Ciò che stavolta cambia è il file di configurazione relativo al database. Sto parlando del postgres_ext.conf che dovresti poter trovare già nella cartella ManageEngine\ServiceDesk\pgsql\data. Probabilmente al suo interno potresti già trovare qualche specifica, per esempio:

wal_level = archive
archive_command = 'IF EXIST archive.bat (archive.bat "%p" "%f")'
archive_mode = on

Ciò che tu devi fare, è semplicemente dare un colpo di invio e aggiungerne qualcuna in più, per includere nuovi parametri entro i quali Postgres può continuare a riservare memoria per sé. Sto parlando di questi:

shared_buffers = 512MB
maintenance_work_mem = 100MB
effective_cache_size = 512MB
work_mem = 12MB

che, rispettivamente:

  • shared_buffers: corrisponde generalmente al 25% della memoria di sistema. Su Windows, 512 MB può essere il valore massimo.
  • maintenance_work_mem: corrisponde circa il 5% della memoria di sistema, ma senza superare mai i 512 MB.
  • effective cache size: si aggira approssimativamente sul 50% della memoria fisica disponibile, ho personalmente continuato a indicare 512 MB anche se avrei potuto tenerlo più alto.
  • work_mem: riporta un valore ragionevole che si attesta tipicamente tra i 4 e i 64 MB.

Il riferimento sulla community di ManageEngine, seppur riferito a SupportCenter, è questo: pitstop.manageengine.com/portal/community/topic/supportcenterplus-optimize-postgresql

Puoi riavviare ora il servizio di ServiceDesk per verificare se la modifica alla configurazione appena operata ha portato i benefici sperati (risposta positiva nel mio caso).


Condividi l'articolo con i tuoi contatti: