=== ChanServ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: feature freeze, DIF | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
[00:33] <foli> Canonical data centre firewall maintenance is now complete.
[00:34] <sarnold> \o/
[00:40] <nacc> juliank: technically, i think, we could use rewrite rules w/o changing the extraction algorithm at all (would need more rewrite rules to look in other component directories)?
[01:15] <sarnold> has anyone looked at https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1673247 yet? I'm curious if this one is worth yanking from the archive until it's sorted out. Breaking LTS installers doesn't seem fun.
[01:15] <ubottu> Launchpad bug 1673247 in snapd (Ubuntu) "package snapd 2.23.1 failed to install/upgrade: trying to overwrite '/etc/apparmor.d/usr.lib.snapd.snap-confine', which is also in package snap-confine 2.23.1" [Undecided,Confirmed]
[02:04] <sarnold> infinity,slangasek,stgraber,xnox,cyphermox,mvo, sorry for the mass highlight but https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1673247 sounds like our xenial and yakkety installers are broken at the moment
[02:04] <ubottu> Launchpad bug 1673247 in snapd (Ubuntu) "package snapd 2.23.1 failed to install/upgrade: trying to overwrite '/etc/apparmor.d/usr.lib.snapd.snap-confine', which is also in package snap-confine 2.23.1" [Undecided,Confirmed]
[02:11] <infinity> sarnold: Our installers?  You mean snapd is broken.
[02:12] <infinity> sarnold: It's only a problem for people who previously installed from proposed.  The breaks/replaces are << 2.23 instead of << 2.23.1
[02:12] <sarnold> infinity: except the reporters claim that the "download new packages" step explodes :(
[02:13] <infinity> sarnold: Not an installer bug, but yes, people who are internet-connected during install will see the bug, as we download and install updates during the install.
[02:14] <infinity> So, I should probably revert snapd in all stables.  Whee.  Fun.
[02:14] <Unit193> Sounds like you'll have a fun evening.
[02:14] <sarnold> infinity: sorry :( thanks <3
[02:18] <infinity> Oddly, my zesty upgrade Just Worked.
[02:19] <sarnold> hrm. Obviously it worked well enough in britney to move past -proposed, but .. I'm confused, since those folks didn't just decide to file bugs for the fun of it ;)
[02:19] <infinity> britney has no concept of package contents.
[02:19] <Unit193> sarnold: In fact, I saw something like that in #xubuntu earlier.
[02:19] <sarnold> infinity: oh? I thought it tested upgrades?
[02:20] <infinity> The file overlap is obviously real.  The reason my zesty upgrade worked is that it removed snap-confine on upgrade, it looks like.
[02:20] <infinity> sarnold: No, we don't do anything like piuparts.  It tests package relationships, but not actually installing them.
[02:20] <sarnold> ahh
[02:21] <jgrimm> nacc, fyi I reset bug 1668940 to 'new'.. otherwise release team will never notice its FFe (according to FFe protocol).  so sayeth the wiki.
[02:21] <ubottu> bug 1668940 in samba (Ubuntu) "[FFe] samba-vfs-modules misses ceph vfs module" [Medium,New] https://launchpad.net/bugs/1668940
[02:29] <Unit193> infinity: Got a sec for me to bother you?
=== RAOF1 is now known as RAOF
=== zyga_ is now known as zyga
[08:53] <juliank> nacc: The rewrite rules I posted in https://gist.github.com/julian-klode/600237d0b61cf92b01748b25cf5921d7 do exactly this. If you request a file for main in universe, it would redirect to main and so on
[08:58] <Saviq> happyaron, hey, let me know if you need anything re: bug #1673197
[08:58] <ubottu> bug 1673197 in zfs-linux (Ubuntu) "Upgrading zfs-initramfs breaks booting from a zfs root" [Critical,In progress] https://launchpad.net/bugs/1673197
[09:01] <tjaalton> uh, how come a freshly-installed zesty system reminds me to update 12.04 LTS before EOL?
[09:02] <tjaalton> on motd
=== gavinlin is now known as Guest72522
=== JanC is now known as Guest95676
=== JanC_ is now known as JanC
[09:59] <xnox> sarnold, infinity: yeah I cannot have fresh cloud-images now. and I am sad.
[09:59] <xnox> http://paste.ubuntu.com/24187744/
[10:01] <raphink> Hello
[10:02] <xnox> apw, can i have meta kernels respun for xenial-security and xenial-updates that are compatible with snapd in xenial-updates?
[10:02] <raphink> My ubuntu-core-dev membership expired recently and I did not see the warning emails. Would it be possible to renew it please?
[10:02] <apw> xnox, we'rw working on that right now
[10:02] <apw> xnox, we did not see that train wreck coming
[10:03] <xnox> apw, ack. thank you.
[10:03] <xnox> Tribaal, josvaz__ ^^^^
[10:04] <Tribaal> xnox: ack, thanks
[10:04] <xnox> apw, infinity: snapd pulled because upgrades broke; which now breaks installs/bootstraps in -updates|-security *sigh*
[10:05] <apw> xnox, yes we are aware, we are scrambling to unf*ck the world now
[10:09] <raphink> cjwatson, ajmitch do you happen to know who could do that?
[10:10] <ginggs> mitya57: i sync'd sphinx and texlive-base migrated.  http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sphinx beets amd64  is the only failure (murano amd64 and i386 passed on retry)
[10:10] <ginggs> tumbleweed: any ideas, re: beets ^
[10:10] <cjwatson> raphink: somebody in ~developer-membership-board
[10:12] <raphink> ok, so BenC, rbasak for example
=== Sir_Gallantmon is now known as Son_Goku
[10:51] <rbasak> raphink: if it's only just happened then I don't see a problem with that. Can you email devel-permissions@ though please, so there's a public record? Note that I'm out until Monday though so I might not see your reply.
[10:54] <raphink> rbasak, I emailed developer-membership-board@ but it's awaiting moderator approval
[10:57] <rbasak> raphink: that's the private list. Use devel-permissions@ please.
[10:57] <raphink> ok, np :-)
[11:00] <raphink> done
[11:10] <rbasak> raphink: I looked to check the expiry date and it was longer than I was expecting. If nobody objects them I'll JFDI, I just thought I'd ask the others to make sure they don't disagree, as I don't think it's quite as obvious as "just".
[11:11] <rbasak> IOW, I think I should act on what I think the DMB as a whole would do, and though I'm fine with it in this case, I'm not confident I understand the others' opinions, so I want to check first.
[11:24] <juliank> I hope this does not happen to me. Launchpad simply seems to drop a lot of emails, as explained in https://answers.launchpad.net/launchpad/+question/458337
[11:25] <juliank> I often wonder what stuff I'm missing. For example, I got xnox's initial bug 1672710 report, but not any comments on that.
[11:25] <ubottu> bug 1672710 in apt (Ubuntu) "apt fails to verify keys when Dir has space, and set via cmdline" [High,Confirmed] https://launchpad.net/bugs/1672710
[11:27] <xnox> juliank, i have timed out on that =( sorry
[11:27] <xnox> i need to fine more time to come back to it.
[11:30] <juliank> xnox: Oh, I was not criticizing you, but launchpad. it only ever sent me the initial bug report you wrote, and none of your or my comments.
[11:31] <juliank> So, launchpad sent 20% of the messages in that bug
[11:33] <xnox> juliank, depend son your subscription type no? one can subscribe with or without comments.
[11:34] <xnox> juliank, under subscriptions
[11:34] <xnox> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1657440/+subscriptions
[11:34] <ubottu> Launchpad bug 1657440 in apt (Ubuntu Yakkety) "apt won't redownload Release.gpg after inconsistent cache updates made while UCA is being updated" [Medium,In progress]
[11:34] <xnox> e.g. there should be stuff about comments, and whether one wants them or not.
[11:34] <juliank> xnox: Oh, you're right
[11:34] <juliank> How odd
[11:37] <xnox> juliank, it's like bug #1 people wanted to know when it will be closed; but not receive all the comments....
[11:37] <ubottu> bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
[11:37] <juliank> xnox: Odd because I sometimes receive more stuff, like adding a remote bug tracker, or my comment in (for example bug 1657440
[11:37] <ubottu> bug 1657440 in apt (Ubuntu Yakkety) "apt won't redownload Release.gpg after inconsistent cache updates made while UCA is being updated" [Medium,In progress] https://launchpad.net/bugs/1657440
[11:38] <juliank> Not that I received any other message from that bug
[11:38] <xnox> juliank, it's weird some things count as "status updates" and if in advance notifications a status update happened and a comment; and launchpad mailshot is delayed and colates the two into a single email then people who receive "only comments" and "only status updates" receive it.
[11:39] <xnox> juliank, i generally try to subscribe with all the things: send me all status updates and comments.
[11:39] <xnox> and then filter mail on my end.
[11:39] <xnox> seems to work for me.
[11:39] <juliank> I changed it now: "You will receive an email when any change is made or a comment is added."
[13:07] <raphink> rbasak, thanks for your answer. I replied to your email.
[13:37] <mitya57> ginggs, thanks for syncing (you were faster than me)! Sphinx migrated now.
[13:37] <ginggs> mitya57: yw!  it took a long time for launchpad to pick it up
[13:38] <brendand> does anyone know if there's a way of suggesting to autopkgtest to prompt debhelper *not* to run dh_auto_test for an unbuilt-tree?
[13:44] <cjwatson> brendand: --env=DEB_BUILD_OPTIONS=nocheck should do it
[13:47] <brendand> cjwatson, brilliant! thanks
[13:48] <brendand> although i guess that will probably apply across all --unbuilt-trees. let's see anyway
[14:43] <nacc> jgrimm: thanks!
[14:43] <nacc> juliank: ah ok, i was just reviewing mod_rewrite, thanks!
[14:45] <xnox> smb, hey, are you still having troubles with isms raid? aka https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1608495
[14:45] <ubottu> Launchpad bug 1608495 in mdadm (Ubuntu Zesty) "IMSM fakeraid handled by mdadm: unclean mounted volumes on shutdown/reboot" [Critical,Confirmed]
[14:46] <xnox> i am working on a fix; but my shutdowns result in rebuilding the array still =(
[14:46] <xnox> https://launchpadlibrarian.net/311133987/mdadm_3.3-2ubuntu7_3.3-2ubuntu7.3.diff.gz
[14:46] <xnox> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2596/+packages
[14:46] <smb> xnox, mainly not since I got fed up with the re-syncs and stopped mounting it
[14:46] <xnox> would you be able to test above & get me a shutdown console log.... somehow...?
[14:46] <xnox> smb, it all works on fedora; with dracut; which pivots back into initramfs
[14:46] <xnox> smb, ok.
[14:47] <xnox> smb, i'll have to rebuild my desktop then to test that myself then.
[14:47] <xnox> smb, at the moment this issue affects a bare metal cloud and they have root on isms raid =(
[14:47] <smb> xnox, mind it has been a long time but I think I had tried to copy the shutdown thing from yakkety and still had the sync
[14:47] <xnox> rebuilds take too long, and thus one fails to boot (as one hits timeout before 60min of resync is done)
[14:48] <smb> xnox, and console log is somewhat difficult with real hw
[14:48] <xnox> smb, but in addition to shutdown script one needs to patch mdmon to use @ to prevent being killed
[14:48] <xnox> yeap.
[14:49] <xnox> smb, any ideas on getting shutdown console log? i guess i will have to video record it =)
[14:49] <smb> xnox, also having re-syncs exhibits another issue with raid in xenial which is it seems to take away much more bandwidth than it should do. Which makes the whole system mostly unresponsive until its done
[14:50] <xnox> it takes about 1h on about 1TB drive, which is reasonable, no?
[14:50] <smb> xnox, not really. usually netconsole would come to mind but I never was very lucky with it
[14:50] <xnox> (raid1, two drives, i think actual container here is 800GB)
[14:51] <xnox> smb, i think i can arrange netconsole on my local network
[14:51] <smb> xnox, the time is reasonable. it just should not prevent the (different) disk with rootfs on from getting any slices
[14:51] <xnox> ah
[14:51] <smb> not sure why this is happening
[14:54] <smb> xnox, so could do certain testing if you add info to the bug but probably be not much more helpful with a log and I cannot promise how quickly turnaround will be
[14:55] <xnox> smb, i am better off rebuilding my desktop with isms raid i think indeed.
[14:56] <smb> xnox, yeah, sorry
[16:05] <nacc> smoser: rharper: "ystemd-remount-fs[55]: mount: can't find LABEL=cloudimg-rootfs" which is the only entry in /etc/fstab
[16:05] <nacc> *systemd-remount-fs
[16:08] <smoser> nacc, so i guess one path to solving that would be to have the squashfs image (or 'lxd' image) not have that in it.
[16:08] <smoser> but i'd say it woudl seem odd to not have an entry in /etc/fstab for /
[16:09] <nacc> smoser: yeah that would be weird, but also it's an unusable entry
[16:09] <smoser> i kind of think systemd-remount-fs should realize its talking about / and / is already  mounted rw, so "done".
[16:09] <nacc> smoser: yeah, that might be the solution
[16:09] <nacc> smoser: i'll update the bug and ask pitti to take a look
[16:09] <nacc> pitti: --^ fyi
[16:10] <nacc> in the context of LP: #1576341 and getting LXD images to be not in systemd-degraded
[16:10] <ubottu> Launchpad bug 1576341 in systemd (Ubuntu) "fails in lxd container" [High,Confirmed] https://launchpad.net/bugs/1576341
[16:10] <nacc> smoser: are you ok if i retitle that bug? :)
[16:12] <smoser> nacc, sure
[16:13] <nacc> smoser: thanks
[16:21] <nacc> bdmurray: where does c.u.c actually run? based upon feedback from juliank I have a potential change to the apache configuration for it, but I'm not sure if the configuration is stored in a SCM
[16:21] <nacc> bdmurray: given that change, no changes are needed to extract-changelogs
[16:25] <bdmurray> nacc: I'd check with the webops team about where it actually runs
[16:25] <nacc> bdmurray: ok, thanks!
[16:26] <bdmurray> robru: where emails sent about proposed migration for stable releases?
[16:27] <bdmurray> s/where/were/
[16:27] <robru> bdmurray: my original branch did but Laney disabled that when he merged
[16:28] <robru> bdmurray: i guess because it would email everybody for every SRU
[16:28] <doko> why isn't also the owner of packages with failing autopkg tests notified?
[16:28] <bdmurray> robru: okay, I was looking at a stuck SRU of mine and was wondering
[16:29] <bdmurray> maybe Laney'll tell us why
[16:29] <robru> doko: owners aren't notified because we don't want to spam debian people with Ubuntu failures they likely don't care about
[16:29] <doko> robru: I mean: the canonical bug subscriber for a package
[16:30] <robru> doko: nobody told me to inspect bug subscribers. I only send emails for the uploader+creator
[16:31] <doko> robru: and who told you to send emails to the uploader+creator? ;)
[16:32] <robru> doko: that would be slangasek
[16:32] <doko> aha
[16:52] <nacc> rharper: urgh, ugly -- both iscsid.service and open-iscsi.service would need the !container change, because with just changing iscsid.service,  'ExecStartPre=/bin/systemctl --quiet is-active iscsid.service' in open-iscsi.service makes it go to failed state ... since it doesn't distinguish that iscsid is not started due to 'condition failed' rather than an error
[16:55] <nacc> smoser: interestingly, manually starting lvm2-lvmetad.socket succeeds, so maybe it's an ordering issue?
[16:55] <smoser> thats odd
[16:57] <nacc> smoser: systemd-journald-audit.socket failing seems to be some conflict between it and systemd-journald.service
=== _salem is now known as salem_
[17:32] <nacc> stgraber: pitti: did this ever get followed upon? https://lists.freedesktop.org/archives/systemd-devel/2015-May/032126.html
[17:45] <rharper> nacc: hrm, that' seems fixable; there are other ways to only activate if another unit is active;  I think the ExecStartPre isn't best practice w.r.t dependencies;
[17:46] <rharper> it would seem like instead they'd want to run After=iscsid.service;  and Wants=iscsid.service;  that way , if iscsid wasn't going to run then the dependent service wouldn't run either;
[18:49] <smoser> aaaaaaaa vim stop touching my mouse!
[18:49] <smoser> https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1661691
[18:49] <ubottu> Launchpad bug 1661691 in vim (Ubuntu Zesty) "TERM=xterm enables mouse mode in vi, breaks pasting with middle mouse" [High,Confirmed]
[18:50] <sarnold> argh that looks terrible
[19:31] <infinity> smoser: I can middle-paste fine under TERM=xterm?
[19:31] <infinity> smoser: Which vim are you using?
[19:32] <smoser> did you try the recreate ?
[19:33] <smoser> lxc launch ubuntu-daily:zesty z1 && lxc exec z1 vi foo.txt
[19:34] <infinity> Trying.  It's downloading.
[19:35] <infinity> smoser: Weird.  So, it works fine on my base system, and only breaks in lxc?  That's suspect.
[19:36] <infinity> Oh, cause the base system is likely doing some X jiggery, and there's no X forwarding socket into the container.
[19:36] <smoser> yeah, i dont know. but yes. thats my experience too. i can paste into 'vi' on the desktop.
[19:37] <infinity> Curious.
[20:51] <nacc> rharper: both are already specified
[20:53] <rharper> nacc: hrm; there's certainly a way to chain units; I may not have it quite right in my head right now
[20:53] <nacc> rharper: yeah, i've been reading documentation -- i'll keep looking
[20:53] <nacc> agreed that hte ExecStartPre is ... a kludge i think
[20:58] <nacc> rharper: open-iscsi specifically says we don't want to use Requires (which would also be an issue anyways), which i think would be the hard-dependency, because then restarting iscsid woudl restart open-iscsi which would end up dropping disk sessions
[20:58] <nacc> I think
[20:58] <rharper> Requires means it needs to run successfully
[20:59] <cyphermox> robru: hey, you still looking for things to do in +1 maintenance?
[20:59] <nacc> rharper: right, which is tehcnically what we want -- only if iscsid succesfully started should we start open-iscsi
[20:59] <robru> cyphermox: sure, what you got?
[20:59] <nacc> rharper: but requires has other implications, it seems, including how services restart
[21:00] <cyphermox> robru: curl looks like it needs help to transition from proposed
[21:00] <rharper> yes; there are some strange dependent units;  you may find the postgresql units interesting; they've something dynamic like this IIRC
[21:00]  * rharper will bbiab
[21:00] <nacc> rharper: thanks, i will look
[21:00] <robru> cyphermox: thanks I'll take a look
[21:00] <smoser> infinity, random bit of information, the vim paste thing happen also for me if i ssh in
[21:04] <cyphermox> robru: let me know if you're stuck
[21:05] <infinity> smoser: You mean if you ssh in to the container, right?  Cause if I ssh to localhost, it works fine.
[21:06] <infinity> smoser: If the consistent variable here is "in the container", then that narrows down the search for what vim's detecting wrong about the environment.
[21:06] <infinity> (reproducing in a simple chroot would help narrow that too)
[21:10] <smoser> infinity, yes, when i ssh into container
[21:11] <smoser> and yeah, when i ssh to localhost i also paste fine
[21:38] <jackpot51> Using a preseed, ubuntu server sits at an empty virtual terminal after GRUB
=== salem_ is now known as _salem
[21:38] <jackpot51> has this been experienced by anyone else?
[21:39] <infinity> jackpot51: qemu or real hardware?
[21:39] <jackpot51> QEMU
[21:39] <infinity> Yeah.  '-vga qxl' works, I think.
[21:39] <infinity> One of the non-default vga options. :P
[21:40] <infinity> Or boot without splash bits.
[21:40] <jackpot51> No splash, and already using -vga qxl
[21:40] <jackpot51> My preseed looks like this: http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt#L1880
[21:42] <infinity> You sure there's no splash?  Interrupt the boot and check what grub says.
[21:42] <infinity> vt.handoff=7 might also be an issue.  But again, all of the above when using a VGA driver that sucks.
[21:44] <infinity> Maybe qxl is the one that sucks and vmware is the one I use that works.  I always forget.
[21:44]  * infinity tests.
[21:55] <jackpot51> I will try it again
[21:56] <infinity> Of course, testing with a quick xenial install, I don't get any of the splash/vt_handoff stuff in the first place, which also entirely avoids the problem.
[21:57] <infinity> I guess I'll grab a zesty ISO while I actually do go for lunch finally.
[21:59] <jackpot51> Do you want my preseed file?
[21:59] <nacc> rharper: if you do recall which postgres systemd file contains the deps, i'd appreciate it -- not seeing it yet
[22:00] <rharper> lemme see
[22:04] <rharper> nacc: postgresql-common:systemd/postgresql@.service ; which uses the 'PartOf'  unit directive
[22:05] <rharper> Configures dependencies similar to Requires=, but limited to stopping and restarting of units. When systemd stops or restarts the units listed here, the action is propagated to this unit. Note that this is a one-way dependency — changes to this unit do not affect the listed units.
[22:06] <rharper> the fancy thing there is that they have a generator which finds out the version of postgres and the cluster name, and then they use a generic 'postgresql.service' which will start or stop any of the postgresql@.service; so if you had 9.5-main , 9.5-backup, 9.6-test;  you could use one service to start/stop them all
[22:07] <rharper> that felt like the relationship in iscsid/open-iscsi but you'll know better
[22:07] <nacc> rharper: ack thanks
[22:07] <rharper> np
[22:08] <infinity> jackpot51: It might just be that you need "d-i debian-installer/quiet boolean false" to go with the splash in your preseed.
[22:08] <infinity> jackpot51: At least, to match what the server ISOs do.
[22:12] <jackpot51> Ok, I will try that
[22:18] <jackpot51> No dice :/
[22:21] <jackpot51> infinity: I will look into https://github.com/gc3-uzh-ch/openstack-tools/blob/master/etc/ubuntu-preseed.cfg
[22:31] <jackpot51> infinity: here is another one: https://github.com/joyent/mi-debian/blob/master/config/debian-installer/preseed.cfg
[22:33] <nacc> rharper: also i just double-check and privileged containers, as expected, are able to run iscsid, so we do want to (i think) adjust open-iscsi.service no matter waht
[22:33] <rharper> nacc: w.r.t removing the !VirtContainer check ?
[22:33] <rharper> and switching to the username space check ?
[22:34] <nacc> rharper: yeah, or something along those lines (implementation TBD)
[22:34] <nacc> rharper: PartOf does seem more correct
[22:34] <nacc> rharper: thanks for that pointer
[22:35] <rharper> nacc: then yeah; I think we shouldn't be overly restrictive to all containers since they're not the same
[22:35] <rharper> nacc: cool!
[22:35] <rharper> hopefully that switch can go upstream to debian as well
[22:35] <rharper> possibly to project
[22:35] <nacc> yep, i'll work on changes locally to test and then ask hallyn to review them
[22:35] <nacc> yep
[22:35] <rharper> awesome!
[22:35] <nacc> i've asked upstream too about mlockall
[22:35] <rharper> hehe
[22:35] <nacc> just curious if they even know :)
[22:38] <rharper> indeed
[22:43] <nacc> rharper: although, the more i think about it, what is the use-case to have iscsid.service running but not open-iscsi.service?
[22:43] <nacc> rharper: that is why isn't it one service really
[22:51] <nacc> rharper: PartOf doesn't solve this problem as it's not different enough from Requires, afaict. What it does is ties the two together (one way), so if we put in open-iscsi.service, PartOf=iscsid.service, then when systemd stops or restarts iscsid.service, it will stop or restart open-iscsi.service. It does not cover 'start' (afaict) and doesn't prevent the propogation when iscsid.service is not loaded.
[22:53] <nacc> pitti: maybe you're the best to just ask :) is it possible to have a systemd service defined in such a way that it only runs when another service is successfully running (and stops when that one stops), etc.
[22:57] <nacc> rharper: ah i see why -- maybe -- iscsid.service is forking, but open-iscsi.service is a onehsot
[23:21] <nacc> rharper: i might have a fix, it feels really hacky, though
[23:29] <nacc> http://paste.ubuntu.com/24192018/
[23:29] <nacc> and then i need to work ont he right fix for iscsid.service
[23:29] <nacc> as terrible as that is, i think it's 'no worse' than we are now
[23:30] <nacc> becasue in theory, if `/bin/systemctl --quiet is-active iscsid.service` were to return 15 or 21 (rather than 3), it seems like we would not have any problems ...
[23:31] <nacc> i mean it's wrong i think to assume 3 means anything
[23:50] <nacc> rharper: ooh fedora's systemd unit is way better :)
[23:50] <nacc> I will look into that