From e561ac24633542f0e2a2d0ea2b95056212f3d528 Mon Sep 17 00:00:00 2001 From: Didier Raboud Date: Sun, 21 Oct 2018 17:48:31 +0200 Subject: [PATCH] Add 20181017 meeting log --- .../debian-ctte.2018-10-17-19.00.log.txt | 233 ++++++++++++++++++ .../20181017/debian-ctte.2018-10-17-19.00.txt | 100 ++++++++ 2 files changed, 333 insertions(+) create mode 100644 meetings/20181017/debian-ctte.2018-10-17-19.00.log.txt create mode 100644 meetings/20181017/debian-ctte.2018-10-17-19.00.txt diff --git a/meetings/20181017/debian-ctte.2018-10-17-19.00.log.txt b/meetings/20181017/debian-ctte.2018-10-17-19.00.log.txt new file mode 100644 index 0000000..511e4d7 --- /dev/null +++ b/meetings/20181017/debian-ctte.2018-10-17-19.00.log.txt @@ -0,0 +1,233 @@ +19:00:24 #startmeeting +19:00:24 Meeting started Wed Oct 17 19:00:24 2018 UTC. The chair is marga. Information about MeetBot at http://wiki.debian.org/MeetBot. +19:00:24 Useful Commands: #action #agreed #help #info #idea #link #topic. +19:00:41 #topic roll call +19:00:57 I'm likely to drop in ½ hour; I can only chair for that part. +19:01:01 Didier Raboud +19:01:02 Philip Hands +19:01:08 Gunnar Wolf +19:01:09 * marga Margarita Manterola +19:01:10 Simon McVittie +19:01:17 Niko Tyni +19:01:20 David Bremner +19:02:11 Tollef Fog Heen +19:02:16 (distracted too) +19:02:56 #topic Review of previous meeting AIs +19:03:32 I think Simon did the summing up really nicely. +19:03:41 https://lists.debian.org/debian-ctte/2018/10/msg00015.html +19:04:30 (crazy how fast months go; I haven't dared to open my TC folder yet :-( +19:05:00 Mithrandir, you were supposed to send the vote for the other issue, right? +19:05:31 yes, I still have that outstanding +19:05:43 will do ASAP +19:05:45 Is there anything in the way? +19:05:50 time on my side +19:06:11 Absolute time? Negative time? ;-) +19:06:16 free time. +19:06:16 Ok, would you rather someone else took over? +19:06:37 give me a week, if I fail to do something within then, I'm fine with somebody taking over. +19:06:41 sounds ok? +19:06:54 Mithrandir: BTW were you taking my (and possibly Ian's) ramblings into account re the vote? (I think there was some merit in there) +19:07:01 fil: yes. +19:07:09 Mithrandir: I'd add a bit to it - If in a week you cannot do this, please bring it up explicitly on the rest of us! +19:07:20 gwolf: sounds good +19:07:42 (so somebody can raise their hand - I guess we'd all prefer if Somebody Else™ did it) +19:08:21 well, I seem to have touched it last, so I could give it a go +19:08:38 #action Mithrandir should raise the vote in the upcoming week. If that doesn't happen, fil can take over +19:08:45 Cool +19:08:48 Sounds good? +19:08:53 fine +19:09:32 yup +19:11:31 #topic #904302 Whether vendor-specific patch series should be permitted in the archive +19:12:14 is there anything more we need to discuss on that? +19:12:16 not #topiced +19:12:42 (I just assumed marga lost connectivity, and can't chair myself) +19:13:05 Also, I'm totally useless on all these issues, I really haven't caught up :-( +19:13:09 Right... Never mind, then :-] +19:13:27 I... Think we should be ready to vote on this one as well +19:13:44 this is the one we just talked about that I'm going to write up the actual vote text for. +19:13:51 I mean, there were some more rounds of argument, but... +19:13:56 Right +19:14:12 So next topic? +19:14:12 Ok, we can skip the next topic I think? +19:14:13 (oh, yes, sorry - ape brain multitasking here) +19:14:38 #topic #904558 What should happen when maintscripts fail to restart a service +19:15:31 So, this one is still very much under discussion... +19:15:54 I think smcv's summary is a good writeup. +19:16:06 Agreed +19:16:17 But the question is how we move forward +19:17:05 Ian and Wouter proposed an interface based on policy-rc.d where sysadmins can arrange for service restart failures to be ignored or not +19:17:09 My impression was that there was some rough agreement that in general we want to recommend maintainers not to fail their maintscripts unless they think it's worth the breakage +19:17:14 Right. The discussion in the last few weeks *did* illustrate very big expectative differences in very different use cases :-/ +19:17:56 Right, they proposed doing some changes which might be interesting to have. But I don't think we can rul such solutions should be implemented... +19:18:41 The fact that most things used to quietly ignore restart failures under sysvinit seemed like a rather important point that was mentioned recently +19:18:54 marga: I tend to side with your interpretation and motivation, but I didn't feel there was a "rough agreement" towards that end +19:19:09 fil: did actually most things do that? I haven't seen numbers one way or the other. +19:19:33 I am wary of solutions involving policy-rc.d, because you have a problem, and you think "I know, I'll solve it with policy-rc.d", and now you have an unpackaged file in /usr/sbin that may or may not get overwritten by debootstrap, and two problems +19:19:51 smcv: yeah, I agree +19:19:59 or at least that's been my experience in Debian derivatives with non-trivial policy-rc.d +19:20:08 Also, policy-rc.d is vastly unknownk +19:20:27 fil, yes, I was also surprised that that was the case. +19:20:34 SteamOS is meant to have a policy-rc.d that suppresses restarts when we are upgrading during shutdown because $reasons +19:20:48 it turns out that it does not, in practice, exist, because it gets overwritten by debootstrap +19:21:06 Mithrandir: well, that was Michael Biebl's assertion (which seemed plausible, but I've not checked) +19:21:32 * gwolf prefers not to even try to wrap brain around smcv's last idea. Sounds too perferse and obscure :-P +19:21:35 re ignored restart failures: it partly depends how carefully the daemon was written +19:22:22 there is a Right Way, that nobody implements, where you only double-fork after you have read all configuration, done everything that could fail (except the things that you can only do after double-forking), etc. +19:22:23 OdyX: I agree that this would require pushing policy-rc.d closer to the consciousness of developers -- And users. +19:23:02 There was a mention of 'the daemon was running before the upgrade and it's not running after the upgrade, so we know it's a problem', but I don't know most maintscripts actually know that much. Most only know that it failed to restart not that it was running before... Am I wrong there? +19:23:36 initscripts often implement restart as stop; start +19:23:41 marga: That would be easy to solve, even if it brought up a mass instant-buggy - `status` before `restart` +19:23:53 * bremner tries to catch up +19:24:08 aka `systemctl try-restart` +19:24:18 gwolf, sure, I understand it's possible, I'm asking whether maintscripts actually check. +19:24:23 I'm not sure whether there was a traditional sysvinit equivalent of try-restart +19:24:54 smcv: I would really not like tech-ctte to mandate systemd interfaces... +19:25:00 Agreed +19:25:05 on the other hand, the good argument for /usr/sbin/policy-rc.d is that executables should not be in /etc, but it really feels ugly (.d for a binary, managed through alternatives, really?) +19:25:09 So, the thing is, what do we want to mandate on? +19:25:25 gwolf: no, of course not, I'm just saying there is prior art for "restart this, but only if it's running" +19:25:32 right +19:25:48 I wonder whether deb-systemd-invoke uses it +19:25:56 /usr/share/debhelper/autoscripts/postinst-init-restart doesn't +19:26:21 I expect most packages use dh_installinit, and will keep using it for the near future +19:26:26 neither does /usr/share/debhelper/autoscripts/postinst-systemd-restart +19:27:41 so, indeed, most of the time the maintscript that responds to a restart failure doesn't even know whether it's a regression +19:27:49 Right +19:28:17 So, we were asked to provide at least a recommendation. Do you think we could recommend something? +19:28:56 I think we can also encourage people to develop better methods for both informing the user and handling errors, but we can't really rule about non-existant things... +19:29:11 I thought the original question was about whether a sensible policy could exist +19:29:44 so, no, would be an (unhelpful) answer +19:30:07 This has proven to be thorny enough. Again, the use cases are distant enough... That shoehorning a set of users into a given behavior can be seen as bad no matter what +19:30:44 We can recommend without shoehorning +19:31:02 that makes a policy-rd.d route somewhat "the least worst" idea: a middle ground. +19:31:59 Yes. But not in a way that makes it mandatory (or we will just have most daemons buggy because they don't check for status beforehand) +19:32:14 How would that look like as a ruling? +19:32:43 I think if we are going for wouter's policy-rc.d route, then it would have to be something like +19:33:07 we could block the tech-ctte bug on a policy-rc.d wishlist bug +19:33:18 if invoke-rc.d exits with nonzero status when restarting a service, this should make the maintainer script fail +19:33:39 oh, that's more sensible than my idea. +19:34:05 (sysadmins are reminded that policy-rc.d can give invoke-rc.d error-handling behaviour that results in it recovering from failures and exiting 0) +19:34:36 ... but there are a couple of reasons I find that unsatisfying +19:34:56 ignorant question, is invoke-rc.d used by non-sysvinit things? +19:35:11 no, good point +19:35:15 smcv: I would add to this that restarting a service SHOULD follow querying for its status +19:35:19 How would this look like in a real life use case? +19:35:27 s/invoke-rc.d/invoke-rc.d or deb-systemd-invoke/ +19:35:30 (and, of course, not restart non-running stuff) +19:35:51 Say, a service fails to start because the config is now outdated and fails to parse? +19:35:56 (or an actual ruling would have to have some words about possible alternative implementations but we would all know that it meant invoke-rc.d and deb-systemd-invoke) +19:36:27 for context, pure systemd services don't use invoke-rc.d, they use deb-systemd-invoke +19:36:40 but both invoke-rc.d and deb-systemd-invoke call out to policy-rc.d +19:36:48 I don't know whether deb-systemd-invoke implements the 106 thing +19:37:04 it does not +19:37:21 I fear we are going too much into implementations details... Is that something we want to / should do? +19:37:50 perhaps not, but now we know that wouter's plan doesn't work as stated +19:38:03 / can do? (re: $6.3.5) +19:38:35 bremner: invoke-rc.d and policy-rc.d is also randomly-ish used by things like ifup scripts and so on +19:38:53 Mithrandir: that's documented as unsupported, more or less? +19:39:10 OdyX: Re 6.3.5, we can sketch it in text without describing the tooling? +19:39:24 That would free us from invoke-rc.d and deb-systemd-invoke +19:39:56 I think the constitutional meta discussion happened before didn't it? +19:39:59 so, what, we'd say "Someone™ should implement an interface for sysadmins to decide what happens on this class of failure?" +19:40:31 Yeah, exactly, I think we need to refrain from describing the exact implementation and instead focus on what are the results we want +19:40:36 bremner: yes, (IIRC I brought it up last meeting) but I think it's sensible to be reminded of +19:41:21 marga: you wanted a description of what happens in real world use cases, do you still? +19:41:51 Not sure, I guess it depends on how we plan to move forward +19:42:05 I mostly want to move forward and not keep stalling +19:42:07 so what wouter and ian were advocating in recent discussion was +19:42:20 your daemon fails to restart because its config is outdated or whatever +19:42:56 in a system with no special configuration, invoke-rc.d fails, the maintscript fails, the package fails to configure, dpkg fails, apt fails +19:44:02 in a system that has been preconfigured by marga's sysadmin team, the restart fails, the failure is caught, magic happens, invoke-rc.d does not fail, everything continues as though it was all OK +19:44:38 that (global failure) seems like a poor default to me -- even more so if the scripts are not checking whether the daemon was able to run before we started +19:44:44 (implementation detail: the magic that would happen, according to wouter's plan, is that you install a policy-rc.d that tells invoke-rc.d "on failure, just stop it") +19:44:52 How far away are we from making this possible? It wasn't clear to me from the discussion if this was actually something already implemented or something that needed more work. +19:46:02 for invoke-rc.d, afaics it can happen already, *if* you drop in a suitable policy-rc.d +19:46:08 I haven't read the thread (booo), but as framed, it feels weird to use the dpkg -> apt pipeline to signal for $any service restart failure. +19:46:33 it's about unconfigured packages? +19:46:37 for systemd-only services, afaics it can't, because deb-systemd-invoke doesn't implement that particular little-known corner of the policy-rc.d API +19:46:40 (sorry if that's rehash) +19:47:30 OdyX: we could state the default in terms of "package fails to configure" +19:47:43 hmm, wait, I'm not actually even sure whether 106 does what wouter said it does +19:48:23 OdyX, I agree with you, but some people don't and they insist on using the output of maintscripts as a signal of failures +19:49:10 Alright, we are at 50 minutes past the hour and it doesn't seem we are getting anywhere... We should stop discussing the issue and instead decide how we want to reach consensus... +19:49:34 on the other hand, if SSH failed to restart and died, having apt in a weird state is the least of my concerns +19:49:48 I think we need to reach for ietf consensus, ie what are you willing to live with, more than what's a perfect solution. +19:50:14 Well, we are already living with "each maintainer decides whatever they want" +19:50:31 is there some way to make the default something like "carry blithely on unless the maintainer has somehow tagged their package as being too important to fail" ? and then let the local admin override that (to be more or less fragile) it they feel the need +19:50:59 marga: Right. Some lines ago, there was mention (by whom? Don't remember - again, multitasking here :-P) of "depends on the nature of your service"... +19:51:14 fil: for the maintainer part, dh_installinit --error-handler=function +19:51:15 So, yes, this could be _legitimately_ left as part of the maintainer's decision grounds +19:51:30 There's likely value in having two classes of services, yes. +19:51:37 gwolf: I think it's important that we give advice about what the default should be +19:51:49 since else we have the current situation where it's half and half (or thereabouts) +19:51:58 fil: not implemented by dh_installsystemd but I think it's a reasonable feature request, unless we come to the conclusion that there is only one legitimate value for the error handler, in which case there's no point in implementing it +19:52:01 Mithrandir: that feels strange if the default is not possible with current tooling +19:52:15 *shrug*, maybe that's the least of our problems +19:52:19 for the "sysadmin can override to be more or less fragile", no that's not currently possible +19:52:25 Mithrandir: the default should be, the new package works like a charm and never fails in any way :-] +19:52:51 gwolf: not what we're talking about though. :-) +19:52:56 yup, sadly +19:52:56 I would prefer the signalling mechanism to not be policy-rc.d +19:53:21 what cross-init alternatives are there? +19:53:23 I also think policy-rc.d is too obscure to most people +19:53:43 this is not the init's problem +19:54:02 both invoke-rc.d and systemctl will give you an exit status and let you do what you want with it +19:54:47 this is entirely an issue for dh_install{init,systemd} (and their open-coded equivalents, for people who like artisanal handcrafted maintainer scripts) +19:55:05 We're left 5 minutes. Could anyone wrap these arguments up in a mail? +19:55:28 unless we want to mandate that invoke-rc.d and dh-systemd-invoke gain new error handling behaviour +19:56:02 OdyX: Right. I hope to be more useful next meeting (that means, no, I'm not volunteering to wrap up), as I am too attention-dilluted right now :-( +19:56:24 I'll volunteer for trying to move the discussion forward, but I feel like we didn't make much progress today :-/ +19:56:35 I feel like we are running in circles +19:56:37 I volunteer to reply to wouter re the policy-rc.d thing, since I've done the research now +19:56:49 Ok, thanks :) +19:57:06 if we want a summary of this meeting's discussion I'd prefer that to be not me +19:57:11 #action smcv to clarify what can be done through policy-rc.d to the mailing list +19:57:25 #action marga to try to summarize the discussion and move the discussion forward +19:57:29 Does that seem fair? +19:57:32 great +19:57:41 Cool +19:57:41 #topic Recruiting efforts +19:58:00 We are in mid-October and I think we need to start recruiting again +19:58:24 It's just OdyX that leaves us after December, right? +19:58:31 and Mithrandir IIRC +19:58:36 Ah, yes... +19:58:44 fair enough -- I'll fire up the randomizer :-) +19:58:49 So sad, time goes so quickly +19:59:00 Yep. Two members go. +19:59:03 Yes, fil, please fire the randomizer. +19:59:03 time flies when we're having fun. +19:59:12 I need to nominate some folks, I think I have a small list somewhere. +19:59:26 Alright, I'll action you two +19:59:46 #action fil will do a few rounds of the random emailer to try to get nominations +19:59:48 Just FTR - We *can* operate with a shortage in membership. We are supposed to have between 4 and 8 members. So, yes, we should act on it. But it's not like we are time-stressed to get new bl00d. +19:59:55 #action Mithrandir will nominate people +20:00:15 And maybe I should email d-d-a? +20:00:43 Yes, to seek self-nominations +20:00:44 gwolf, true, but we don't want to be understaffed. A plurality of opinions is good. +20:00:49 Alright, then. +20:00:52 gwolf: true. But the TC loses two every year, it goes quick +20:01:06 #action marga to email d-d-a to encourage self-nominations. +20:01:09 Right to both of you - We are not _constitutionally_ stressed yet. +20:01:37 10 mails sent +20:01:43 Awesome :) +20:01:48 Efficient! +20:01:51 #topic Any other business +20:01:59 * fil has a little script +20:02:02 I have to go. I'm late to have lunch with my kids +20:02:20 So... I'll leave the AOB (including the new bug) to you. +20:02:30 I wanted to ask whether we should meet more often now that we have open issues and apparently more controversial than initially expected? +20:03:11 As long as the calendar is kept up-to-date, I'll try. +20:03:22 But not more than every 3 weeks +20:03:23 Would it make sense to schedule an "extraordinary meeting" in 2 weeks instead of next month? +20:03:32 or that, yes. +20:03:47 or just chat in IRC a bit more? +20:04:06 it's probably important to have fixed meeting times. +20:04:12 I feel like having the actual meeting deadline / time helps. +20:04:18 from a transparency point of view, alaso +20:04:20 also +20:04:25 yup +20:05:14 fair enough +20:05:23 Anyway, we are over time. I'll send this to the mailing list as well. +20:05:32 I can make a meeting in two weeks. +20:05:49 Let's end here and leave people free to go. Thanks everyone for attending! +20:05:56 #endmeeting \ No newline at end of file diff --git a/meetings/20181017/debian-ctte.2018-10-17-19.00.txt b/meetings/20181017/debian-ctte.2018-10-17-19.00.txt new file mode 100644 index 0000000..177d8fe --- /dev/null +++ b/meetings/20181017/debian-ctte.2018-10-17-19.00.txt @@ -0,0 +1,100 @@ +==================== +#debian-ctte Meeting +==================== + + +Meeting started by marga at 19:00:24 UTC. The full logs are available at +http://meetbot.debian.net/debian-ctte/2018/debian-ctte.2018-10-17-19.00.log.html +. + + + +Meeting summary +--------------- +* roll call (marga, 19:00:41) + +* Review of previous meeting AIs (marga, 19:02:56) + * LINK: https://lists.debian.org/debian-ctte/2018/10/msg00015.html + (smcv, 19:03:41) + * ACTION: Mithrandir should raise the vote in the upcoming week. If + that doesn't happen, fil can take over (marga, 19:08:38) + +* #904558 What should happen when maintscripts fail to restart a service + (marga, 19:14:38) + * ACTION: smcv to clarify what can be done through policy-rc.d to the + mailing list (marga, 19:57:11) + * ACTION: marga to try to summarize the discussion and move the + discussion forward (marga, 19:57:25) + +* Recruiting efforts (marga, 19:57:41) + * ACTION: fil will do a few rounds of the random emailer to try to get + nominations (marga, 19:59:46) + * ACTION: Mithrandir will nominate people (marga, 19:59:55) + * ACTION: marga to email d-d-a to encourage self-nominations. (marga, + 20:01:06) + +* Any other business (marga, 20:01:51) + +Meeting ended at 20:05:56 UTC. + + + + +Action Items +------------ +* Mithrandir should raise the vote in the upcoming week. If that doesn't + happen, fil can take over +* smcv to clarify what can be done through policy-rc.d to the mailing + list +* marga to try to summarize the discussion and move the discussion + forward +* fil will do a few rounds of the random emailer to try to get + nominations +* Mithrandir will nominate people +* marga to email d-d-a to encourage self-nominations. + + + + +Action Items, by person +----------------------- +* fil + * Mithrandir should raise the vote in the upcoming week. If that + doesn't happen, fil can take over + * fil will do a few rounds of the random emailer to try to get + nominations +* marga + * marga to try to summarize the discussion and move the discussion + forward + * marga to email d-d-a to encourage self-nominations. +* Mithrandir + * Mithrandir should raise the vote in the upcoming week. If that + doesn't happen, fil can take over + * Mithrandir will nominate people +* smcv + * smcv to clarify what can be done through policy-rc.d to the mailing + list +* **UNASSIGNED** + * (none) + + + + +People Present (lines said) +--------------------------- +* marga (66) +* smcv (50) +* gwolf (37) +* Mithrandir (23) +* OdyX (23) +* bremner (18) +* fil (13) +* MeetBot (2) +* ntyni (1) + + + + +Generated by `MeetBot`_ 0.1.4 + +.. _`MeetBot`: http://wiki.debian.org/MeetBot -- 2.39.2