| === halvors1 is now known as halvors | ||
| zopa | Hello | 00:53 |
|---|---|---|
| zopa | Hello. I have a Ubuntu package that relies heavily on mysql-server. I released a small update and during dist-upgrade mysql-server-5.7 is installed at the same time as my package. My package fails because it can't connect to the mysql server during the upgrade process. I have to wait for mysql-server to finish installing and upgrading then run apt-get dist-upgrade again. | 00:53 |
| zopa | My only thought is I have mysql-server set as a recommend, not required.... | 00:54 |
| zopa | but this is the first time I've ever seen this. | 00:54 |
| zopa | log -https://pastebin.ubuntu.com/p/dddYrX2pxP/ | 01:01 |
| sarnold | zopa: are you the author of this package? | 01:03 |
| zopa | I'm one of the maintainers, yes | 01:03 |
| zopa | I've not ran into this problem before, and it seems to be tied to mysql-server stopping during upgrade and my package upgrading at the same time | 01:05 |
| zopa | my scripts are https://github.com/bluecherrydvr/bluecherry-apps/tree/master/debian | 01:05 |
| zopa | s/my scripts/the build scripts | 01:05 |
| zopa | I will return in a few minutes | 01:05 |
| sarnold | zopa: I'm not sure there's anything that can be done at the debian packaging level to address this. The pre-depends field is close, but "even if the depended-on package(s) are only in the “Unpacked” or the “Half-Configured” state, provided that they have been configured correctly at some point in the past" | 01:11 |
| sarnold | zopa: https://www.debian.org/doc/debian-policy/ch-relationships.html | 01:11 |
| sarnold | zopa: I was hoping that would require the pre-depended package to be fully installed, but no luck :( | 01:12 |
| zopa | sarnold: okay, I was afraid of that :( | 01:24 |
| TJ- | zopa: the mechanism for that is deb-triggers, where you could declare an 'interest' in a file path created by mysql when it is running. E.g. /run/mysql.pid maybe | 02:21 |
| zopa | hrm... | 02:24 |
| zopa | I don't reallly understand, do you happen to have a link for more information on deb-triggers or a proper way to detect this? | 02:27 |
| TJ- | zopa: https://sources.debian.org/src/dpkg/1.20.9/doc/triggers.txt/ | 02:32 |
| sarnold | I can't make heads or tails of that :) | 02:36 |
| sarnold | but it's used to rebuild manpages, it should be good so long as you don't wind up with looping triggers | 02:37 |
| TJ- | I'd think you're add a debian/yourpackage.trigger with "interest /run/mysqld/mysqld.pid" and in your .postinst script factor your mysql-dependent code into a function. Conditionally call that in your "configure" stanza, and add a "trigger" stanza that calls the function unconditionally. Make your function set a tell-tale so it is idempotent | 02:40 |
| TJ- | I got the pid path from the mysql systemd service file | 02:40 |
| TJ- | trigger file spec http://manpages.ubuntu.com/manpages/focal/en/man5/deb-triggers.5.html | 02:44 |
| zopa | okay thank you | 02:48 |
| unixbsd | there is a bug in live-boot, ubuntu/debian cannot mount a UFS2 once initrd image launched. the ufs2 mount is looking for a modules, but live-boot hasnt it into the modules. Please fix the bug, kindly. | 05:21 |
| unixbsd | Apparently, this ufs handling capability comes at a later stage of the booting process. | 05:27 |
| === Guest5369 is now known as _hc | ||
| === alan_g_ is now known as alan_g | ||
| === RzR is now known as rZr | ||
| Laney | @pilot in | 15:17 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Hirsute | If you can't send messages here, authenticate to NickServ first | Patch Pilots: Laney | ||
| Laney | @pilot out | 15:17 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: Open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Hirsute | If you can't send messages here, authenticate to NickServ first | Patch Pilots: | ||
| Laney | just testing! | 15:17 |
| teward | vorlon: slightly confused, is the core issue in that devel thread network-online.target or that it needs to restart services that need it at net failures/reconnects? | 19:30 |
| vorlon | teward: the core issue is network-online.target, xnox is practicing his sealioning | 19:31 |
| teward | ok well i think quoting from freedesktop is relevant: > network-online.target is a target that actively waits until the nework is "up", where the definition of "up" is defined by the network management software. | 19:31 |
| teward | so however networkd/networkmanager/etc report "up" needs standardized I think | 19:32 |
| vorlon | yes, which is what I am proposing | 19:32 |
| teward | ok thats what i wasnt clear about, thanks. | 19:32 |
| teward | vorlon: I'm assuming that the standard would need defined at the systemd network for "what defines 'up' which all network management utilities should compare on"? | 19:33 |
| vorlon | sorry, I can't parse that | 19:34 |
| teward | yeah neither can I on my phone 1 moment | 19:34 |
| teward | will retype | 19:34 |
| teward | so the core problem is the target doesn't have a 'standard' for how network management tools should define "online", then? | 19:37 |
| vorlon | yes | 19:37 |
| teward | and if that is the case, then should that standard be defined as part of systemd's specs/rules | 19:37 |
| vorlon | I think so, yes | 19:37 |
| vorlon | so, we should try to get a standard accepted upstream by systemd | 19:38 |
| vorlon | but barring that, we should still solve the problem in Ubuntu | 19:38 |
| vorlon | (like, if systemd upstream wants a different standard, we should consider following that rather than using our own definition; but if systemd doesn't want to standardize, Ubuntu still should) | 19:38 |
| teward | vorlon: i think if we can agree on a distropatch mechanism we can force something like NM does for wifi with its connection checks. | 19:48 |
| teward | which, right now, I believe defaults to http://connectivity-check.ubuntu.com/ - its primary goal is for portal checking (captive portal and such) but you could use a similar mechanism to make sure you get a response that is 200 or 204 or such. | 19:50 |
| teward | primary problem being that that URL is designed for captive portal and NM uses X-NetworkManager-Status headers from the response to determine if it's online | 19:50 |
| teward | but you could probably use a similar detection mechanism to *force* it to verify we're online. Would require systemd-networkd and network manager and such to be configured accordingly | 19:50 |
| teward | (and in NM, you can disable the check which would break this) | 19:51 |
| rbasak | teward: Internet connectivity is somewhat separate | 19:51 |
| teward | rbasak: i think then we have to define "what do we define as 'online'?" which goes back to defining a standard | 19:52 |
| teward | rbasak: default behavior I THINK would be we could ping the gateway to ID an interface that is online, but again some networks disallow that as well. THe core problem then, as observed is, "what defines online?" | 19:52 |
| teward | hammer down a check mechanism for *that definition* | 19:52 |
| teward | and then move from that | 19:52 |
| teward | rbasak: key problem is, nothing reports the same way :p | 19:53 |
| teward | and I can think of a hundred network configuration ways you could break any check we could write :P | 19:53 |
| teward | (external from the system in question using network-online.target I mean) | 19:53 |
| rbasak | From my perspective, the problem we need to solve is what to tell users when their service fails to start because some network-level ordering thing mismatched their expectations. | 19:53 |
| rbasak | Because they come and tell us that our packaging is missing After=network-online.target. | 19:53 |
| teward | rbasak: TBH I'm going to go right back to the 'nginx' case where the request was to change its unit like that. | 19:54 |
| teward | and that "we can't reliably define what 'online' is and that's entirely dependent on your systems' net manager' | 19:54 |
| teward | which is why we rejected that request | 19:54 |
| teward | if we're going to consider proposing a way to determine 'online' then we have to make it a sane default that we could expect would be anywhere. | 19:54 |
| teward | the remaining other option is to reject the request for any such case about "missing this target" with the aforementioned statement. | 19:55 |
| teward | because, really, we can't ID how each network management utility is going to report "online" or not | 19:55 |
| rbasak | Some users expect that if they configure a service that introduces a dependency on network availability, that the packaging already ships After=network-online.target. That's what it comes down to. | 19:55 |
| rbasak | Should they be expected to also adjust the systemd service unit when they configure their service to depend on the network, or not? | 19:55 |
| rbasak | Eg. user configures ssh to bind to a specific address | 19:56 |
| teward | i think that brings another discussion because a lot of those services use network.target not network-online.target | 19:56 |
| teward | (read: nginx, apache, etc.) | 19:56 |
| rbasak | Or in the nfs-utils case, DNS is required for that service to work. | 19:56 |
| teward | rbasak: you mean *functioning* DNS | 19:56 |
| teward | not just "DNS is configured"? | 19:56 |
| rbasak | Right | 19:56 |
| rbasak | But it's the _user_ that configured their service like that; it wasn't from default packaging. | 19:57 |
| rbasak | You end up with circular/contradictory requests too. | 19:57 |
| rbasak | One user has bind configured to use mysql so needs mysql started before "DNS". | 19:57 |
| teward | rbasak: then I think going back to the way we argued nginx might be suitable: "You're looking for a non-default configuration that we can't reliably support for all cases" | 19:57 |
| teward | i hate being the negative person in this case | 19:57 |
| rbasak | Another user has mysql configured to bind to a particular address so needs "network" before mysql | 19:57 |
| rbasak | etc | 19:57 |
| rbasak | Right so my view is that configuring a service also requires other adjustments, and that's part of being a sysadmin (on server) | 19:58 |
| teward | but from my perspective I'd rather be told that "You're doing a nonstandard setup so you are going to have problems, but these are user-configuration problems and things you need to research how to resolve, it's not going to be standard in the packaging." | 19:58 |
| rbasak | eg. use a non-standard path for your data directory: also adjust AppArmor. Configure a service to need network: also adjust systemd. etc. | 19:58 |
| teward | rbasak: then we probably should have a canned response for any of these cases. | 20:01 |
| teward | Namely: | 20:01 |
| teward | "This is a special configuration that is non-standard. Your custom use cases will NOT line up with the way the original packaging was built/designed, and we are not going to adjust the packaging in this way to adapt for your configuration cases because you happened to require this behavior and loading chain of conditions. For SystemD units, adjust your units accordingly on your end with overrides." | 20:02 |
| teward | or something along those lines | 20:02 |
| teward | their next question is "how do i do that"... or in the case of 50 disgruntled Ask Ubuntu users who met my boot this morning, whine, complain, rant, and be disruptive :P | 20:02 |
| teward | it *sounds* like many of these are requiring DNS to be up and functional | 20:03 |
| teward | therefore we could do a DNS lookup for some 'safe' URL i.e. connectivity-check.ubuntu.com. if your DNS is up, then resolved returns a response. otherwise, you're broken. | 20:03 |
| teward | (again, Network Manager at work xD) | 20:04 |
| teward | but same point there, DNS or otherwise, if we build some type of standard then *everything* (nmtray, network-manager, networkd, ${insert-alternative-mechanism-here}, etc.) has to obey and implement the checks. | 20:04 |
| teward | (back in a bit, chiropractor) | 20:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!