ldv_ changed the topic of #strace to: https://strace.io | https://strace.io/logs/ | strace 4.21 is out | strace-devel@lists.strace.io for dev discussions
eSyr-ng__ has joined #strace
jrtc27_ has joined #strace
jrtc27 has quit [*.net *.split]
eSyr-ng has quit [*.net *.split]
jrtc27_ is now known as jrtc27
<github-strace> [strace] ldv-alt merged ldv/next into master: https://github.com/strace/strace/compare/a2e4217c95f6...4eeba4e60fde
strace-logger_ has joined #strace
strace-logger has quit [Remote host closed the connection]
<github-strace> [strace] ldv-alt merged ldv/next into master: https://github.com/strace/strace/compare/4eeba4e60fde...3b01ac5cd316
pombreda has quit [Ping timeout: 255 seconds]
pombreda has joined #strace
lineprinter[m] has quit [Ping timeout: 248 seconds]
wladmis has quit [Ping timeout: 264 seconds]
wladmis has joined #strace
<Smit-Tay> I would have a list of processes - probably no more than 2 or 3 per machine. I would want to monitor things like memory allocation, disk and network IO, etc.. (General performance counter info)
lineprinter[m] has joined #strace
<Smit-Tay> The idea being, to detect / mitigate imminent problems.
<Smit-Tay> Of course, in a perfect world, server processes would be well behaved, and never fail. But, of course, reality is a very different experience
emachado has joined #strace
emachado has joined #strace
emachado has quit [Changing host]
wladmis has quit [Remote host closed the connection]
wladmis has joined #strace
<eSyr-ng_> Smit-Tay: mmmm, i think strace would be a bad fit for that. I think there are flourishing some "container monitoring solutions" (for some rason, sysdig comes to mind, but it's kinda different), but if you want to do it from scratch, you can…
<eSyr-ng_> … start with perf profile, /proc and cgroups counters, that sort of thing. Most of that is implemented as a munin module, for example, and usually needs only minimal tuning.
<eSyr-ng_> Smit-Tay: for local heartbeat/monitoring, i would look for supervise (https://cr.yp.to/daemontools/supervise.html), but systemd is actively promoted these days for all kinds of daemon supervising.
<Smit-Tay> Interesting
<Smit-Tay> It looks like supervisor is really only to ensure that a daemon is always running. I'm really trying to find a way to detect when a daemon is about to fail.
<eSyr-ng_> yes, the provision is usually done by various monitoring techniques, from gneric monitoring solutions, to custom tracing/profiling scripts.
<github-strace> [strace] ldv-alt merged ldv/next into master: https://github.com/strace/strace/compare/3b01ac5cd316...9630646cfad1
ldv_ changed the topic of #strace to: https://strace.io | https://strace.io/logs/ | strace 4.22 is out | strace-devel@lists.strace.io for dev discussions
<ldv_> SteveMcIntyre: http://www.einval.com/debian/strace/build-logs/arm64/2018-04-05-040229-log-amdahl-SUCCESS.txt doesn't look like a successuful build despite of its name
<ldv_> SteveMcIntyre: strace 4.22 addresses three Debian bug reports, according to NEWS
<SteveMcIntyre> ldv_: ack, will look
<ldv_> SteveMcIntyre: you might want to relax the check by configuring with --enable-mpers=check
<SteveMcIntyre> ack
<eSyr-ng_> (there's a patch that enables mpers on aarch64, but it's not upstreamed yet)
pombreda has quit [Ping timeout: 265 seconds]
pombreda has joined #strace
<SteveMcIntyre> curious how configure can be failing there without my script picking it up
emachado has quit [Quit: Leaving]
<ldv_> I doubt that configure can fail to set a non-zero exit code
<SteveMcIntyre> yeah
<SteveMcIntyre> it's exiting fine, my parsing elsewhere is off
<SteveMcIntyre> fixing that
<eSyr-ng_> ldv_: do you have an idea why ppc64el mpers has failed?
<ldv_> I suppose gcc-multilib is not installed
<ldv_> according to debian/control, gcc-multilib is installed for ppc64
<ldv_> so maybe ppc64el is not quite the same as ppc64
<eSyr-ng_> probably, it has something with the fact that LE introduced after the move to 64 bits.
<SteveMcIntyre> nod, ppc64 and ppc64el are quite different
xse has quit [Quit: Leaving]
xse has joined #strace