No HDMI sound output after some time with the monitor turned off

Comment diagnostiquer un tomcat KO en analysant les thread dumps:

• prendre 3 thread dumps à 10s d'intervalle (kill -3 <pid> ou jstack -l <pid>)
• vérifier la présence de deadlocks
• comparer ensuite les 3 thread dumps avec un diff, meld ou autre et chercher les threads applicatif (type: http-nio-8080-exec-*) restés dans le même état sur les 3 thread dumps
• identifier la root cause du thread bloqué en regardant le code si nécessaire

lien origine: http://www.tomcatexpert.com/blog/2013/03/28/hanging-thread%E2%80%943-steps-troubleshooting-tomcat

Résolution de l'année: arrêter d'utiliser netstat!

'ss' appartient au paquet iproute2 dont voici une grosse doc: https://jeekajoo.eu/links/?g3Er4g

iproute2 remplace net-tools (ifconfig, route, netstat, arp...) qui est déprécié depuis 2009: https://lists.debian.org/debian-devel/2009/03/msg00780.html

Hum, mais pourquoi je n'ai pas fait la recherche "adb remote control" plus tôt sur un moteur de recherche web ?!

L'outil présenté dans cet article est codé en java et s'appuie sur adb pour faire des screenshots réguliers de l'écran et les afficher.
On peut également envoyer des signaux curseurs/clavier vers le téléphone pour le contrôler. J'ai cependant remarqué que l'ordre des touches tapées n'était pas garanti.

La fenêtre peut être agrandie pour voir l'écran dans sa résolution native. Bref, même si ça semble archaïque, ça juste-marche et je n'ai pas trouvé mieux et surtout aussi standard.

Cela va me permettre de mieux assister mon père avec son ordiphone android (et par ailleurs éviter des prises de tête vu qu'il n'est pas à l'aise avec l'outil informatique et que je ne suis pas toujours patient).
Schématiquement ça va donner ça: SSH -> VNC (via une redirection du port local) -> java 'remote-control' -> ADB via USB -> screenshot local -> ADB via USB -> affichage screenshot dans le logiciel 'remote-control'

5 prérequis:
0) ADB installé
1) ordiphone branché en USB et visible par ADB ('adb devices' pour checker la présence)
2) mode développeur activé
3) debogging usb activé, possible que si 1)
4) autorisation de la machine locale (cocher la case pour toujours accepter). A la première tentative de connexion de ADB en USB, un popup va apparaitre pour cela.

Je n'ai pas testé avec OpenJDK, mais juste avec le java 8 de Oracle car il était déja installé sur ma machine. Des retours sont les bienvenus à ce sujet.

"""
RequestBin gives you a URL that will collect requests made to it and let you inspect them in a human-friendly way.
Use RequestBin to see what your HTTP client is sending or to inspect and debug webhook requests.
"""

On oublie trop souvent 'sysdig' et tout ce qu'il permet de faire..
C'est un mélange de strace, lsof et tcpdump.

Voici quelques exemples d'utilisation.

https://jeekajoo.eu/links/?searchtags=syscall

EDIT: si vous souhaitez jouer avec csysdig (sysdig en ncurse), utilisez les derniers paquets http://www.sysdig.org/wiki/latest-packages/ . Si vous êtes confrontés à "error mapping the ring buffer for device /dev/sysdig0", faites
"""
rmmod sysdig-probe
modprobe sysdig-probe
"""
source: https://github.com/draios/sysdig/issues/295

Analyser les appels systèmes d'un programme pour trouver la cause d'un problème (ou à des fins de compréhension / reverse-engineering), avec strace donc.

et sinon, pensez à utiliser sysdig, son clone sous hormones: https://jeekajoo.eu/links/?Z0A7gg

quelques pistes pour tenter d'identifier la cause de problèmes de mise en veille (suspend)

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1358921
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1292627

"Think of it as strace + tcpdump + lsof + awesome sauce."
indispensable pour tout sysadmin qui se respecte.

Une fois sysdig installé, vous pouvez faire ce petit test avec la commande cat:

• sudo sysdig proc.name=cat
• lancez une commande cat dans un autre terminal pour voir ce que le système fait :)