=== Eleventh_Doctor is now known as Pharaoh_Atem
=== ackkk is now known as ackk
=== lan3y is now known as Laney
=== lionel_ is now known as lionel
[09:39] <cpaelzer> Is there a process in place to whitelist ppa's and/or proposed builds while the maintenance is going on?
[09:43] <hloeung> cpaelzer: speak to wgrant and/or cjwatson
[10:15] <rbasak> I filed https://bugs.launchpad.net/bugs/1579695 a while ago, but I think there might be a similar/duplicate bug on this too. Does anyone know anything about it?
[10:15] <ubottu> Launchpad bug 1579695 in systemd (Ubuntu) "apport hook does not show the status of failed services" [Undecided,New]
[10:15] <rbasak> We're looking at trying to make the UX better for the gazillion MySQL/MariaDB maintainer script failures we get reported.
[10:17] <rbasak> We also noticed that "systemctl start <service>" doesn't seem to complain on service start failure and exits zero.
[10:18] <rbasak> On otto_'s 17.04 system at least.
[10:18] <rbasak> Which surprises me.
[10:20] <xnox> lolz
[10:21] <xnox> rbasak, you do know, that I am a PostgreSQL person =) and come from an ex-PortgreSQL consultancy =)
[10:21] <xnox> most of my MySQL experience is from .... migration to PostgreSQL =)
[10:21] <xnox> for all the things
[10:21] <rbasak> Don't worry about the MySQL-specific bits :)
[10:21] <otto_> here: https://paste.debian.net/1003968/
[10:22] <otto_> I mangled the cups service to start my custom failing script test.sh
[10:22] <rbasak> If you fancy fixing bug 1579695 then that's definitely nothing to do with MySQL specifically :)
[10:22] <ubottu> bug 1579695 in systemd (Ubuntu) "apport hook does not show the status of failed services" [Undecided,New] https://launchpad.net/bugs/1579695
[10:22] <otto_> service fails to start now bud systemctl start does not complain anything
[10:24] <xnox> otto_, you seem to be mistaken, in thinking that `systemctl start` reports success of starting the service. It reports the sucess of talking to private systemd socket, and submitting a job to systemd. Such that e.g. systemctl list-jobs -> shows that mysql is starting, and later fails to start.
[10:24]  * xnox welcomes otto_ to my world
[10:25] <xnox> you can catch list-jobs stuff, if you crank systemd debugging and watch journal.
[10:25] <xnox> or like have a /bin/sleep infinity as an ExecStartPre= and check systemctl list-jobs
[10:25] <rbasak> How does invoke-rc.d detect service start failure?
[10:25] <xnox> rbasak, good question.
[10:25] <xnox> rbasak, note that we do not use invoke-rc.d in package maintainer scripts.
[10:26] <xnox> rbasak, is mysql stuff native units or init.d scripts autogenerated into systemd units and then managed by systemd?
[10:26] <xnox> i believe invoke-rc.d invokes systemctl, and tells lies.
[10:27] <xnox> so systemctl start does report some failures - e.g. if that new unit does not exist, or is conflicting, or doesn't mean start conditions -> all that will fail to submit the job, and thus such invocations should report failures from systemctl start
[10:28] <rbasak> "note that we do not use invoke-rc.d in package maintainer scripts"
[10:29] <otto_> traditional init scripts wait for the process to come up and yield and exit code. servicectl apparenlty does not wait for the service to come up
[10:29] <rbasak> I thought we did? Or is that different with dh_installinit or dh_systemd or whatever it is?
[10:30] <xnox> rbasak, yes, that.
[10:30] <rbasak> mysql-server-5.7.postinst is currently using invoke-rc.d, but we're planning to move away from that.
[10:30] <cjwatson> To be fair systemctl(1) says "If [--no-block] is not specified, the job will be verified, enqueued and systemctl will wait until the unit's start-up is completed."
[10:30] <xnox> true.
[10:30] <cjwatson> which seems to disagree with observed behaviour here
[10:31] <xnox> but for simple ExecStart the mere exec is successful start, unless there is pid / notify / dbus stanzas.
[10:31] <xnox> arguably it should not be....
[10:31] <rbasak> We did use invoke-rc.d because we needed to start the server temporarily for schema updates, but we're planning to change that to fix bug 1592669
[10:31] <ubottu> bug 1592669 in mysql-5.7 (Ubuntu) "postinst fails when daemon is not running (or is disabled by policy-rc.d)" [High,In progress] https://launchpad.net/bugs/1592669
[10:32] <cjwatson> ah yeah of course
[10:32] <otto_> maybe cups is just a bad example to test this as the .service file is so simple
[10:34]  * xnox observes that mysql-5.7 debian/ is 963k
[10:35] <rbasak> po is 224k
[10:35] <rbasak> changelog 240k
[10:35] <rbasak> copyright 32k
[10:35] <rbasak> Welcome to my world :)
[10:36] <xnox> rbasak, looking at the service file..... there is no notifications w.r.t. when the service is ready
[10:36] <xnox> rbasak, is there no systemd notify mysqld api?
[10:36] <Skuggen> xnox: Not currently. We use forking upstream (running mysqld with --daemonize)
[10:36] <rbasak> Not currently. I'm told (by Lars, sitting opposite) that currently forking is the only type
[10:36] <rbasak> Right :)
[10:37] <rbasak> But looks like we're using plain ExecStart at the moment.
[10:37] <xnox> Skuggen, i like upstream.
[10:38] <xnox> rbasak, i think we should fix our service file to be better and inlcude --daemonize and Type=forking and the PIDFile stanza
[10:38] <xnox> as per https://mysqlserverteam.com/mysql-5-7-native-systemd-support/
[10:38] <xnox> all of that looks sane
[10:38] <xnox> and missing in our units.
[10:38] <rbasak> Sounds like a task for Skuggen this week :)
[10:39] <xnox> at the very least; --daemonize; type=forking; PIDFile stanza (ideally /run, not /var/run ;-))
[10:39] <Skuggen> One of the issues we have with forking upstream is that we use RestartPreventExitStatus=1, and that doesn't seem to work
[10:39]  * xnox yells /var/run is dead, long live /run
[10:39] <rbasak> Actually /run is short-lived :-P
[10:40] <xnox> Skuggen, if that does not work, please open a bug against systemd and give me an example and the bug number i can look into fixing that.
[10:40] <xnox> rbasak, har har har har
[10:44] <Skuggen> xnox: Will do
=== mwsb is now known as chu
=== maclin1 is now known as maclin
[12:57] <Skuggen> Does anyone know how debconf prompt priorities are affected by doing a release upgrade (if at all)?
[12:58] <Skuggen> e.g. does it only show critical?
=== mhcerri_ is now known as mhcerri
[14:32] <jamespage> Skuggen, rbasak: how long are you all working out of London for? the whole of the week?
[14:58] <rbasak> jamespage: yes, whole week. Maybe early finish on Friday depending on Otto's and Lars' travel plans
[16:24] <didrocks> slangasek: FYI: https://bugs.launchpad.net/ubuntu/+source/gnome-characters/+bug/1713176/comments/6
[16:24] <ubottu> Launchpad bug 1713176 in gnome-characters (Ubuntu) "[MIR] gnome-characters" [Undecided,Incomplete]
=== smoser1 is now known as smoser
[16:25] <slangasek> didrocks: the expected subscriber for MIRs is desktop-packages
[16:26] <slangasek> if this is supposed to be a desktop package, I can add that subscription
[16:28] <didrocks> slangasek: maybe I'm wrong but I thought we were using ubuntu desktop bugs now
[16:29] <slangasek> didrocks: I heard someone express a preference for this, but no one has migrated the subscriptions to ubuntu desktop bugs for all the packages in main that desktop team is responsible for, and the tooling hasn't been updated to track that team
[16:30] <slangasek> didrocks: we're not going to just switch it and have an increase in the 'unsubscribed' count on http://reqorts.qa.ubuntu.com/reports/m-r-package-team-mapping.html
[16:30] <didrocks> slangasek: just note that some are probably wrong (like gdm3)
[16:30] <didrocks> but yeah, we should put some consistency over it
[16:30] <didrocks> I think subscribing desktop-packages for now is fine
=== mwhudson_ is now known as mwhudson