19:38:30 <sumpfralle2> #startmeeting
19:38:30 <MeetBot> Meeting started Wed Feb 19 19:38:30 2020 UTC.  The chair is sumpfralle2. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:38:30 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:38:48 <sumpfralle2> It is Wednesday evening: time for our weekly IRC meeting!
19:57:17 <TheSnide> hi all
19:59:19 <sumpfralle2> Hi!
19:59:27 <sumpfralle2> How was your munin week?
19:59:46 <TheSnide> _very_ quiet
20:00:06 * TheSnide still waits for the time where he can put some time on it
20:00:29 <sumpfralle2> Another winter will be there :)
20:01:26 <sumpfralle2> I would be happy, if you could take a look at https://github.com/munin-monitoring/munin/pull/1282 - it is short and should be easy to review :)
20:03:00 <sumpfralle2> I do not trust my perl enough - but I assume, that perl is quite tolerant anyway, thus that code should have no chance to disturb the rest of the program in any cose?
20:07:08 <TheSnide> if you want to avoid breaking at all costs, you should wrap that in an eval{}. It's the perl equiv of a try-catch
20:08:42 <TheSnide> the "This can be indicated by the socket path starting with a null byte" ... i don't really understand
20:08:56 <sumpfralle2> eval: I will do so
20:10:02 <sumpfralle2> null byte: I have seen this substitution in a python-based example implementation for sd_notify. Then I looked up some man page about sockets and found the reference to namespaces.
20:10:11 <sumpfralle2> You are right: I will improve this comment.
20:10:48 <TheSnide> also : why didn't you use IO::Socket ?
20:11:06 <TheSnide> https://metacpan.org/pod/IO::Socket
20:11:50 <sumpfralle2> Is it better/different?
20:12:12 <sumpfralle2> I will switch, if "Socket" is assumed to be less fashionable today.
20:12:45 <TheSnide> it is "object oriented"
20:12:53 <sumpfralle2> null byte: it is an "abstract address" for a socket (see "man 7 unix")
20:13:02 <sumpfralle2> hu - modern!
20:13:11 <TheSnide> ... not that I care, but I do like the "automatic garbage & closing" that comes with it when it goes out of scope
20:13:15 <sumpfralle2> I will switch ..
20:13:24 <sumpfralle2> sounds good
20:13:33 <TheSnide> I'm just checking if it doesn't add a new dep.
20:14:09 <sumpfralle2> I think, IO::Socket is part of perl's core?
20:14:14 <sumpfralle2> (if that is the proper name)
20:14:59 <TheSnide> https://perldoc.perl.org/5.30.0/IO/Socket.html means it is indeed PerlCore
20:15:11 <TheSnide> i was like, 95% sure.
20:15:38 <sumpfralle2> (I have to admin, that I looked it up before)
20:15:44 <TheSnide> ;)
20:15:59 <sumpfralle2> good - thanks for your comments!
20:16:54 <sumpfralle2> I was happy, that Net::Server allows to override configuration file settings (e.g. "background 1") in munin-node.conf with an argument during object initialization. It does not really feel ok, but it is useful.
20:17:28 <sumpfralle2> (the override of "background" was necessary for the usage of "sd_notify")
20:18:57 <TheSnide> yup
20:19:07 <TheSnide> what's the use of sd_notify btw?
20:19:33 <TheSnide> aha "Notify service manager about start-up completion"
20:20:05 <sumpfralle2> At the moment "Net::Server" manages the "go into background" operation. It does this, *before* the munin-node process is ready to accept requests (no plugins parsed, ...).
20:20:43 <TheSnide> aha. It's because Munin listens on the port and only then reads the config from the plugins
20:20:43 <sumpfralle2> That was the basic problem. Now we stick to the foreground, but inform systemd/start-stop-daemon exactly, when we are ready.
20:20:55 <sumpfralle2> yes
20:21:13 <TheSnide> so before systemd was looking at the port opening
20:21:14 <TheSnide> ?
20:22:08 <sumpfralle2> With regard to systemd I am not completely sure. Since we did not configure socket activation in Debian for munin-node, I guess, that there was the same timing issue as with sysvinit.
20:22:28 <sumpfralle2> Previously systemd just started it and counted this as a success ("simple").
20:22:53 <sumpfralle2> Now the type is "notify": background it; assume it is ready when the signal arrives.
20:23:04 <TheSnide> hmmm... looking at the code, it seems that we could setup the whole stuff, and only then call Node::Server->run()
20:23:46 <sumpfralle2> I think, the problem was a bit deeper, since Net::Server::Fork did the backgrounding even before the "prepare_loop" hook (or similar).
20:24:16 <sumpfralle2> Thus we had no real chance to be ready *after* going into the background (this would be the alternative, I guess).
20:24:34 <sumpfralle2> s/after/before/
20:24:37 <TheSnide> wondering about https://metacpan.org/pod/Systemd::Daemon
20:24:47 <TheSnide> > The module is in experimental state
20:24:48 <TheSnide> well...
20:25:09 <sumpfralle2> I took a look: it is not packaged for Debian. Otherwise I would have used it.
20:25:17 <sumpfralle2> (of course, I could have packaged it ...)
20:26:12 <sumpfralle2> It has some dependency on "XS" (the author himself complained about this in a blog - almost regretting to have written the module).
20:26:37 <sumpfralle2> (I do not know this XS - it just sounded like it is not desirable)
20:28:36 <TheSnide> nah, let's leave it like that.
20:29:02 <TheSnide> If it was me, i'd inverse the flow to avoid the "else" fountain
20:29:06 <sumpfralle2> yes, our specific implementation is sufficient and trivial.
20:29:27 <TheSnide> if (! socket() ) {
20:29:29 <sumpfralle2> inverse: using "return" after every action?
20:29:32 <TheSnide> error
20:29:35 <TheSnide> return
20:29:35 <TheSnide> }
20:29:39 <TheSnide> yep
20:30:00 <TheSnide> since, you don't do anything actually, you just try to do things, and the condition fails
20:30:00 <sumpfralle2> I prefer conditionals over mutiple return statements. Taste! :)
20:30:03 <TheSnide> ;)
20:30:48 <TheSnide> i think that error+return is very like thowing an exception in other languages
20:31:27 <TheSnide> but, i agree, it's just a matter of taste.
20:31:28 <sumpfralle2> Yes, a "raise" would feel different for me.
20:31:48 <sumpfralle2> If there would be just a widely used style guide for Perl :)
20:31:51 <sumpfralle2> "Modern Perl"?
20:32:23 <TheSnide> well... my style is very C-like.
20:33:01 <TheSnide> i'm mostly writing Perl as "C with arrays, maps & regex" :))
20:34:26 <sumpfralle2> Do you follow the perl6 development?
20:37:06 <sumpfralle2> I was just wondering, whether beautiful things like exception handling (similar to python) or "contexts" ("with" in python) would be introduced (probably similar things already work - they just do not look obvious to me and my basic skills). Anyway this would be probably a little bit overwhelming exchange :)
20:38:13 <sumpfralle2> In other news: lemontree123 seems to clean up the issue tracker of munin-node-win32 quite well. A good start ...
20:40:26 <sumpfralle2> Let's call this the end of the meeting.
20:40:32 <sumpfralle2> #endmeeting