=== jamesh_ is now known as jamesh
=== Foxhoundz is now known as BenderRodriguez
=== Foxhoundz is now known as BenderRodriguez
=== ledeni_ is now known as ledeni
[12:13] <coreycb> sil2100: hey! any chance you could take a look at neutron in the bionic unapproved queue? it has some critical bug fixes.
=== mhcerri is now known as mhcerri_
=== mhcerri_ is now known as mhcerri
[13:16] <seb128> bdmurray, hey. Are those "[bionic/nautilus] Possible Regression" emails supposed to be sent daily? Also I think Trevinho responded to it, was it good enough or was there still concerns?
[14:00] <bdmurray> seb128: Hi! The emaisl are supposed to be sent whenever a new regression is found which could be daily. One of the emails I received talked about the crashes in general as a bunch rather than each one individually. As an example I'd prefer to know that crash 69d1bc is a memory error, while crash b9dfd02 will be fixed by the next SRU, etc....
[14:00] <seb128> Trevinho, ^
[14:01] <seb128> bdmurray, k, let's see if we can get what you need ... is there a place that shows all the report ids that are of a concern atm?
[14:01] <seb128> I deleted some of the emails, I though the content was the same
[14:01] <bdmurray> https://people.canonical.com/~ubuntu-archive/phased-updates.html
[14:01] <Trevinho> seb128: I've looked at all of them,
[14:02] <Trevinho> personally the only fix I'm concerned about is https://code.launchpad.net/~3v1n0/ubuntu/+source/nautilus/+git/nautilus/+ref/ubuntu/bionic-fix-file-remote-type-search-crash
[14:02] <Trevinho> and covered by that branch
[14:02] <seb128> Trevinho, can you take those ~20 ids and do a list of "id: <reason>" to help bdmurray?
[14:02] <bdmurray> Trevinho, seb128: or "id, id, id: <reason>" if there are some that are the same type
[14:03] <Trevinho> most of them are like: "I don't know", actually, a part from the one mentioned above which might cause some of them which I've marked as duplicated alaready
[14:03] <Trevinho> already*
[14:03] <seb128> Trevinho, I think we need a full summary in one email to help bdmurray to be confident if the update is fine or not
[14:03] <bdmurray> "I don't know" doesn't sound like the phasing should be increased, unless its an old crash.
[14:03] <Trevinho> as for the most of them I'm quite sure they happen as per other upstream changes and just changed the trace compared to what we had before, but nothing really concerning
[14:04] <seb128> Trevinho, well "I don't know" doesn't give confidence it's not a regression?
[14:04] <seb128> right
[14:04] <seb128> well if you write that it's fine
[14:04] <seb128> "not a new issue, different signature but the problem was already existing"
[14:05] <Trevinho> these unknowns, are more of them related to different trace I think, but most of them seems like memory errorrs unrelated to an actual change, but I can see if I can resume it
[14:07] <seb128> Trevinho, well, we just need a list and show that we looked at all the reports and are confident the SRU is still fine
[14:07] <seb128> seems you are confident
[14:07] <seb128> but your reply didn't convince bdmurray
[14:08] <Trevinho> seb128: yeah, but if we want to be better, would be nice to reupload to fix to #1795028
[14:08] <seb128> so please provide it in a format that he can review/understand enough to be fine with it as we are
[14:08] <seb128> Trevinho, ok, I can look at doing that ... do you think we should block the SRU until that one lands?
[14:08] <Trevinho> as I think there might be crashes related to memory issues that might be caused by that too...
[14:08] <seb128> ah
[14:08] <Trevinho> maybe it's better.
[14:08] <seb128> sounds like we do
[14:08] <seb128> k, let me put on my list to sponsor this week
[14:08] <seb128> bdmurray, ^ we are going to do a follow-up SRU with a fix and then we let you know the status :)
[14:09] <Trevinho> that branch is based on `XubuntuCancel` one though, so let me know if you want me to rebase it on top of ubuntu/bionic instead
[14:09] <rbasak> sil2100: I'm going to finish up SRU reviewing packagekit that I started yesterday now, if that doesn't clash with you?
[14:10] <Trevinho> seb128: ^
[14:10] <bdmurray> seb128: got it, let me know if you want the SRU reviewed.
[14:10] <seb128> Trevinho, yes please, let's not interlock those
[14:10] <seb128> bdmurray, will do, thx
[14:10] <Trevinho> ack
[14:40] <sil2100> rbasak: no problem, thanks for the heads-up
[14:48] <seb128> bdmurray, oh, other topic, I mentioned it at the sprint, but it would be nice to remove 15.04/15.10 from the error tracker legend ... is there a bug tracker/place for such requests?
[14:53] <bdmurray> seb128: https://bugs.launchpad.net/errors/
[14:53] <seb128> bdmurray, thx
[14:56] <seb128> bdmurray, https://bugs.launchpad.net/errors/+bug/1796107
[14:56] <ubottu> Launchpad bug 1796107 in Errors "Remove 15.04 and 15.10 from the graph/legend" [Undecided,New]
=== lool- is now known as lool
[14:59] <bdmurray> seb128: got it, thanks
[15:12] <doko> oSoMoN, tdaitx: the libreoffice tests fail with OpenJDK 11. does it need just a rebuild?
[15:12] <doko> are these related at all?
[15:30] <oSoMoN> doko, not sure, I need to take a closer look at the error, but I'm stepping out now, can do later in the evening
[16:55] <rbasak> sil2100: did you manage to look at bug 1782031 please?
[16:55] <ubottu> bug 1782031 in openscap (Ubuntu Xenial) "[SRU][xenial] Enable SCE option and systemd probe in libopenscap8" [Undecided,In progress] https://launchpad.net/bugs/1782031
[16:55] <rbasak> From history:
[16:56] <rbasak> sil2100_: around? May I have a second SRU opinion on bug 1782031 please? Seems to me there may be a functional (surprising) change to users there if unknown/notchecked ends up going to fail.
[16:56] <ubottu> bug 1782031 in openscap (Ubuntu Xenial) "[SRU][xenial] Enable SCE option and systemd probe in libopenscap8" [Undecided,In progress] https://launchpad.net/bugs/1782031
[16:57] <rbasak> 13:53 <ubottu> bug 1782031 in openscap (Ubuntu Xenial) "[SRU][xenial] Enable SCE option and systemd probe in libopenscap8" [Undecided,In progress] https://launchpad.net/bugs/1782031
[17:41] <tdaitx> oSoMoN: btw, hsqldb1.8.0 also breaks with openjdk-11 (System::runFinalizersOnExit() was removed) and libreoffice depends on it (it is the only dependency), do you know why? hsqldb 2.4 fixes this and we do have it in the archive, but it is not clear if it is a sane replacement for LO
[17:49] <sil2100> rbasak: looking at it now
[18:03] <ahasenack> infinity: hey, for when you are around, do you have squid's apparmor profile enabled by any chance?
[18:04] <infinity> ahasenack: How would I know?
[18:05] <ahasenack> infinity: aa-status on the box, or ps faxwZ and check if the squid process is listed as "confined"
[18:05] <ahasenack> infinity: I got logs from jibel that show apparmor denied messages right around the crash, so I'm thinking he did enable it
[18:06] <infinity>  ps faxwZ | grep squid | awk '{print $2}'
[18:06] <infinity> (enforce)
[18:06] <ahasenack> yep, enforce, sorry
[18:06] <ahasenack> so it's enabled
[18:06] <infinity> I didn't actively enable it.  Surely, it's a default thing?
[18:06] <ahasenack> I didn't think it was
[18:06] <ahasenack> I had to explicitly enable it in my test boxes/vms
[18:07] <ahasenack> something to investigate, but it gives a hint about this bug
[18:07] <infinity> I mean, this laptop install dates back to vivid, so I can never remember exactly what all I may have done to it, but I'm pretty sure my squid setup is just a side-effect of "apt-get install squid-deb-proxy" and editing the whitelists.
[18:07] <ahasenack> noted
[18:07] <ahasenack> now let's see what kind of DENIED messages you have related to squid
[18:07] <infinity> So, maybe the AA profile isn't enabled by default *anymore*, but it was in the past, and the maintainer scripts (correctly) don't change the current setup on upgrade?
[18:08] <ahasenack> lots of things
[18:08] <ahasenack> could have happened. I will check that, but now I want to see if I can correlate the profile with the crash
[18:08] <infinity> ahasenack: http://paste.ubuntu.com/p/PM8D6WdQD8/
[18:09] <sil2100> rbasak: hmmm, indeed an interesting case this is
[18:09] <infinity> ahasenack: And I woke up to apport telling me of a new crash.  Yay.
[18:10] <ahasenack> [95825.651047] audit: type=1400 audit(1537596453.254:301): apparmor="DENIED" operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/squid" name="run/dbus/system_bus_socket" pid=24740 comm="squid" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
[18:10] <ahasenack> ok,
[18:10] <ahasenack> there are two messages
[18:10] <ahasenack> one about the net_admin capability
[18:10] <ahasenack> and the above
[18:10] <ahasenack> I've seen other fixes in apparmor profiles about this disconnected path issue
[18:10] <infinity> SIGABRT is comm_openex().  That's the same one we were looking at before, right?
[18:10] <ahasenack> yes, the result of the failed assert
[18:10] <infinity> That does smell of something an AA denial could cause.
[18:11] <ahasenack> let me get you a diff
[18:11] <ahasenack> for the profile
[18:11] <ahasenack> I'll also post it to the bug
[18:11] <infinity> Kay.
[18:12] <jdstrand_> ahasenack: make sure the profile uses attach_disconnected
=== jdstrand_ is now known as jdstrand
[18:12] <ahasenack> jdstrand_: yeah, it's not using it
[18:12] <ahasenack> that will be my diff :)
[18:13] <ahasenack> I'm also wondering about the net_admin capability
[18:13] <ahasenack> but that has been in use since squid3 as far as I can tell
[18:13] <ahasenack> early squid3
[18:13] <jdstrand> * bind to any address for transparent proxying
[18:13] <jdstrand> from man capabilities
[18:14] <infinity> Yeah, squid seems like a solid net_admin consumer.
[18:14]  * jdstrand nods
[18:20] <sil2100> rbasak: let me think about it and leave a comment tomorrow, I think I have a split opinion about this SRU
[18:22] <ahasenack> infinity: apply this to /etc/apparmor.d/usr.sbin.squid: https://pastebin.ubuntu.com/p/R6Z84ZdsfP/
[18:22] <ahasenack> then issue sudo apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.squid
[18:22] <ahasenack> jdstrand: looks ok? ^
[18:23] <rbasak> sil2100: thanks
[18:23] <rbasak> jmbl: ^
[18:24] <infinity> ahasenack: Applied.
[18:25] <ahasenack> infinity: does dmesg show a profile_replace going on for squid and squidguard?
[18:26] <infinity> ahasenack: Applied.Oct  4 12:24:10 nosferatu kernel: [1057755.099944] audit: type=1400 audit(1538677450.686:496): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/squid" pid=18164 comm="apparmor_parser"
[18:26] <infinity> Oct  4 12:24:10 nosferatu kernel: [1057755.109369] audit: type=1400 audit(1538677450.695:497): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="/usr/sbin/squid//squidguard" pid=18164 comm="apparmor_parser"
[18:26] <ahasenack> cool
[18:26] <infinity> Erm, that.
[18:26] <ahasenack> now we wait I guess
[18:26] <infinity> I love waiting.
[18:26] <ahasenack> :)
[18:27] <ahasenack> you have been getting one crash per day basically?
[18:27] <ahasenack> I wonder if logrotate triggers it
[18:27] <ahasenack> I tried here, no dice
[18:27] <infinity> Probably.
[18:27] <jdstrand> ahasenack: lgtm
[18:27] <ahasenack> jdstrand: thx
[18:29] <infinity> Oct 04 00:00:14 nosferatu squid[32112]: assertion failed: comm.cc:428: "!isOpen(conn->fd)"
[18:29] <infinity>  Oct 04 00:00:15 nosferatu squid[10409]: Starting Squid Cache version 4.1 for x86_64-pc-linux-gnu...
[18:29] <infinity>  Oct 04 00:00:15 nosferatu squid[10409]: Service Name: squid
[18:29] <infinity> Hrm, unless I logrotate at midnight now, that's not the trigger.
[18:29] <ahasenack> ok
[18:29] <ahasenack> is the crash always around that timE?
[18:30] <infinity> ahasenack: Not sure.
[18:30] <infinity> ahasenack: Huh.  Yep.  Midnight every day.
[18:31] <ahasenack> fascinating
[18:31] <infinity> ahasenack: So maybe cron.daily moved?  Isn't it meant to be 6am or something?
[18:31] <infinity> Yeah, cron.daily and, thus, logrotate, is 6:25...
[18:31] <ahasenack> 25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
[18:31] <ahasenack> mine is that
[18:32] <infinity> Except there's also a systemd timer for logrotate now?
[18:32] <infinity> Fun.
[18:32] <jibel> ahasenack, this machine has been upgraded since utopic, so it might be something that was set then removed
[18:32] <ahasenack> do you see logrotate messages around that time?
[18:32] <infinity> Not sure where I'd see them.
[18:33] <infinity> Ahh, syslog apparently.
[18:33] <infinity> And yes, logrotate is at midnight here.
[18:33] <infinity> Thanks, systemd new world order, for changing everything.  Love you.
[18:34] <infinity> ahasenack: So yeah, I think it's fair to assume that the service restart/reload from logrotate is the trigger.
[18:34] <ahasenack> can you run it manually with logroate -f /etc/logrotate.conf? It will rotate your logs earlier than expected, if you care about it deeply
[18:35] <infinity> ahasenack: I can get sciency about that in a few minutes, sure.  Should probably unapply the apparmor patch first, confirm a few times that it's reproducible, then apply pach.
[18:35] <infinity> patch, too.
[18:35] <ahasenack> that's fine, whenever you can
[18:36] <ahasenack> I'll post on the bug with the patch
[18:36] <ahasenack> jibel: can you check if you have the squid apparmor profile enabled? Check with "ps faxwZ | grep squid", see if it's listed as enforced
[18:37] <ahasenack> jibel: ah, sorry, just saw your bug update
[18:40] <infinity> vorlon: My Technical Architect, is that a thing we should care about?  logrotate moved to systemd timers (apparently) and now runs at midnight instead of the previously-expected cron.daily time.
[18:40] <infinity> s/My/Mr/
[18:40] <infinity> Didn't mean to imply you were a Fisher Price My First Architect.
[18:41] <sarnold> lol
[18:45] <jmbl> rbasak, sorry was away from desk. ok thanks. I am happy to help answer any questions. Unfortunately, we need that functionality to ship a product. sighhhh :-)
[18:47] <infinity> ahasenack: Oh, changing apparmor profiles doesn't apply to running processes, does it?
[18:48]  * infinity suspects not.
[18:49] <sarnold> you need to apparmor_parser --reload /path/to/profile
[18:51] <jdstrand> infinity: if the process is already runningg under the parser, it does with apparmor_parser -r (or --replace, not --reload though)
[18:52] <jdstrand> infinity: if the process started outside of confinement, it needs to be restarted (see 'sudo aa-status')
[18:52] <infinity> Kay, I did replace.
[18:52] <infinity> So, this fix isn't a large enough hammer.
[18:52] <infinity> https://paste.ubuntu.com/p/nN5HqbS7ZB/ <-- ahasenack
[18:52] <infinity> I also tried a hard restart for kicks.
[18:52] <infinity> Looks like it's happer about net_admin, but still whiney about dbus, and still asserting.
[18:52] <infinity> happier, too.
[18:53] <ahasenack> I didn't handle dbus in that patch
[18:53] <ahasenack> that log is a bit different though
[18:53] <ahasenack> infinity: let's zero in on apparmor first, though. If you disable apparmor profile for squid, does the crash disappear?
[18:54] <infinity> ahasenack: Maybe! (how?  sorry, I'm apparmor stupid)
[18:54] <ahasenack> aa-complain /usr/sbin/squid I *think* is enough
[18:54] <ahasenack> it should still log, but not actually deny
[18:54] <ahasenack> not sure if restarts are needed, just give it a try
[18:54] <sarnold> argh. sorry about --reload. :( been dicking with systemd lately :(
[18:56] <infinity> ahasenack: No dice: https://paste.ubuntu.com/p/4zm9dDKgk2/
[18:56] <infinity> I should probably fix the config file it's complaining about too, but I can't imagine that being the issue. :P
[18:56] <ahasenack> it's not, I get that too
[18:57] <ahasenack> just no crash
[18:57] <ahasenack> infinity: so is this enough to crash it? /usr/sbin/squid -k rotate
[18:58] <infinity> ahasenack: Yup.
[18:58] <ahasenack> hm
[18:58] <infinity> ahasenack: So, I guess apparmor was a red herring (but clearing out all those sketchy DENYs still seems like a solid plan)
[18:58] <ahasenack> yep
[18:59] <ahasenack> now why can't I get it to crash
[18:59] <infinity> That's a mystery I'm not sure I can solve.
[18:59] <ahasenack> infinity: is that a host, or a container/vm? And amd64 I assume?
[18:59] <infinity> ahasenack: amd64 bare metal.
[18:59] <ahasenack> ok
[19:01] <ahasenack> infinity: is this squid the version from the ppa, or 4.1 from cosmic?
[19:01] <infinity> ahasenack: cosmic.
[19:01] <infinity> ahasenack: Not against trying the PPA now that we have a consistent reproducer.
[19:01] <ahasenack> infinity: can you try the ppa one, and then run /usr/sbin/squid -k rotate command?
[19:01] <infinity> ahasenack: URL to the PPA again?
[19:01] <infinity> (or short name for apt-add...)
[19:02] <ahasenack> infinity: add-apt-repository ppa:ci-train-ppa-service/3450
[19:03] <infinity> Why does squid take so friggin' long to shut down?
[19:03] <infinity> (longterm complaint, this isn't new)
[19:03] <ahasenack> I know
[19:03] <ahasenack> it waits 30s
[19:03] <infinity> Err, wat?
[19:03] <infinity> There's a sleep in there, it's not DOING anything?
[19:03] <ahasenack> it's like a graceful shutdown, but it always does that, regardless if there are open connections or not
[19:04] <infinity> That should be fixed..
[19:04] <infinity> Oh, that's fun.  Upgrading squid doesn't restart squid-deb-proxy.
[19:04] <infinity> Probably also a longstanding bug, but ew.
[19:05]  * infinity restarts manually.
[19:05] <ahasenack> interesting
[19:05] <ahasenack>  /o\ surrounded by bugs
[19:06] <infinity> I mean, squid can't be expected to know about *all* its potential rdeps, but the ones it does know about (cf: the apparmor profile knows of some), it should probably try to detect and restart.
[19:06] <ahasenack> there are ways to link systemd units, maybe it could be done
[19:06] <infinity> Or that.
[19:06] <infinity> Oct  4 13:06:43 nosferatu squid[17502]: assertion failed: comm.cc:428: "!isOpen(conn->fd)"
[19:06] <infinity> (with the new squid)
[19:06] <ahasenack> ok
[19:06] <infinity> So, no dice.
[19:07] <ahasenack> thanks for your help
[19:07] <infinity> I wonder if it's just a stupid assertion that needs to not? :P
[19:07] <infinity> Like, exiting a loop there might be just as sane as DYING HORRIBLY.
[19:08] <infinity> (note: I've not looked at the code at all, maybe it's the 1 in 100 times when assert() is used correctly)
[19:12] <infinity> ahasenack: The other possibility is that this is really expected behaviour, and upstream just didn't think about people like us who trap all unclean exits as errors and whine about them.
[19:12] <infinity> ahasenack: Note that this is the child process that's dying and respawning, not the master, AFAICT.
[19:13] <infinity> ahasenack: So maybe that assert just needs to be an exit, and we can wash our hands of it.
[19:13] <infinity> ahasenack: But an understanding of WTF is going on would be helpful to determine that.
[19:14] <infinity> ahasenack: I make that assertion based on my master processes running since I started them, and the children having new start times after rotate.
[19:15] <ahasenack> hm
[19:15] <infinity> Also, this seems to not have anything to do with squid-deb-proxy, it's the non-deb version that we're testing and killing with squid -k rotate, it looks like.
[19:15] <ahasenack> found an old bug, looking at it: https://bugs.squid-cache.org/show_bug.cgi?id=4796
[19:15] <ahasenack> many comments
[19:17] <sarnold> ew. I have to admit I would have expected socket interaction with logfile rotating to have been sorted out twenty years ago.
[19:19] <infinity> So many wheels to reinvent.
[19:19] <infinity> ahasenack: Seems stalled on another round of review/commit, but the last patch looks plausibly not the worst?
[19:20] <infinity> Oh, and the discussion moved to github... Somewhere.
[19:21] <ahasenack> yeah, tracking
[19:26] <ahasenack> infinity: about the long shutdown: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898469
[19:26] <ubottu> Debian bug 898469 in squid "Squid waits on shutdown even though there are no active clients" [Normal,Open]
[19:27] <ahasenack> been there since 3.5.x
[19:27] <infinity> Also, misreading "FreeBSD" as "Fedora" and then seeing libc.so.7 in a backtrace was mildly terrifying for a split second.
[19:27] <ahasenack> hehe
[19:27] <infinity> OH NO REDHAT WHAT HAVE YO DONE.
[19:27] <ahasenack> saw someone with a plan B of using restart for logrotate instead of "squid -k rotate"
[19:28] <infinity> ahasenack: Which then runs into the long shutdown issue. :)
[19:29] <ahasenack> true
[19:29] <infinity> ahasenack: I wonder if it would be out of line to suggest that the Debian/Ubuntu packages should drop the default for that to 5s or something.
[19:29] <ahasenack> yeah
[19:29] <infinity> Since it can be jacked back up by the config file for people who actually want that.
[19:30] <infinity> I mean, even 5s is too long.  The real bug should be fixed upstream, but whee.
[19:30] <infinity> (The part where it doesn't differentiate between active clients and *any open socket*, and thus always waits the max time)
[19:31] <infinity> I assume this actually, hilariously, means that the log sockets we're currently asserting on are also responsible for the shutdown taking 30s.
[19:31] <infinity> Not that fixing A will fix B.
[19:31] <infinity> Just related code with two stupid bugs that should probably date and make hundreds of little bugs.
[19:32] <ahasenack> debian should also be affected by the crash
[19:32] <infinity> One would assume, yes.
[19:32]  * ahasenack reads through the bug one more time
[19:32] <infinity> But they don't have a crash handler installed by default, so less likely to notice.
[19:32] <infinity> As I pointed out, it's the *child* that dies and respawns, so there's not DoS or anything here.
[19:33] <infinity> So without a crash handler, you'd have to be scouring logs to even notice it happened.
[19:33]  * infinity grabs his crossbow and goes to hunt wild tacos.
[19:34] <sarnold> mm tacos
[20:17] <ahasenack> got it in debian
[20:17] <ahasenack> Oct  4 20:17:00 sid-squid4 squid[582]: assertion failed: comm.cc:428: "!isOpen(conn->fd)"
[20:17] <ahasenack> not sure how yet, I ran -k rotate multiple times, sometimes with an open connection
[20:17] <ahasenack> but getting there
[20:52] <ahasenack> infinity: got a reproducer, and a one-line config change that explains why squid-deb-proxy doesn't crash by default, but squid does
[20:52] <ahasenack> squid-deb-proxy has cache_dir specified, as does my home proxy. With that, it doesn't crash on squid -k rotate
[20:52] <ahasenack> I'll update the upstream bug, and might file a debian one as well now that I have a simple reproducer
[21:07] <infinity> ahasenack: Shiny.  Well-sleuthed.
[21:08] <infinity> ahasenack: So, the TLDR for me is that if I mask out the main service (as I wanted to do anyway), the bug goes away for me? :P
[21:08] <infinity> ahasenack: (not at all a valid excuse to not fix it, obviously)
[21:08] <ahasenack> infinity: yes
[21:08] <ahasenack> or add cache_dir to squid.conf, for reasons
[21:09] <infinity> Should it not have a baked-in default for that anyway, pointing to a dpkg-owned directory?
[21:09] <ahasenack> if you want to confirm it
[21:09] <ahasenack> squid-deb-proxy does the right thing
[21:09] <infinity> Seems like a packaging bug tickling the upstream bug.
[21:09] <ahasenack> squid.conf, I don't know why there is no default, probably because you have to specify a size
[21:09] <ahasenack> the cache is only in ram then, without cache_dir, afaik
[21:09] <infinity> A default config with no cache dir seems vaguely useless.
[21:10] <ahasenack> let me see if there is an option where you don't have to specify the max size
[21:10] <infinity> But maybe I'm not imagning some weird use of squid where you would be happy with a tiny RAM cache.
[21:10] <infinity> imagining*
[21:11] <ahasenack> well, it's a proxy and a cache
[21:11] <ahasenack> two things in one
[21:11] <ahasenack> the proxy bit can be used for access control
[21:12] <infinity> There are other proxies that are better at that if you don't also want the caching, IMO.
[21:12] <ahasenack> all cache_dir types require a size parameter, something hard to guess a good default for
[21:12] <infinity> But fair point.
[21:12] <ahasenack> #Default:
[21:12] <ahasenack> # No disk cache. Store cache ojects only in memory.
[21:12] <infinity> I still think preconfiguring a cache dir (even if tiny) makes sense.  But, again, still not an excuse for not fixing the upstream bug.
[21:12] <ahasenack> after all, squid-deb-proxy does have a default cache dir
[21:13] <infinity> I'd rather waste some arbitrary value (500M?) of everyone's disk than eat their RAM.
[21:13] <infinity> If I had to pick a "sane" unpacked-but-not-user-configured state.
[21:13] <ahasenack> # use a different dir than stock squid and default to 40G
[21:13] <ahasenack> cache_dir aufs /var/cache/squid-deb-proxy 40000 16 256
[21:13] <ahasenack> that's from squid-deb-proxy
[21:13] <ahasenack> someone made the call
[21:13] <nacc> infinity: yeah, esp. as a default configuration setting these days
[23:38] <vorlon> infinity: ah, poor merger I that I didn't notice the change to timers also changed the time it ran.  I think that yes, we ought to move it to again run in the 6am window.
[23:51] <jbicha> vorlon: if you're around, there are some proposed hints: https://code.launchpad.net/%7Eubuntu-release/britney/hints-ubuntu/+activereviews