[14:37] <goddard> why is the mysql server default setting to let the bin logs grow to infinity?
[14:37] <goddard> should be something rational like 1 gig at least
[14:38] <goddard> is this debian package or ubuntu?
[14:38] <goddard> how does that work?
[14:38] <goddard> do i talk to the package maintainer or something?
[14:42] <tomreyn> why is limiting them to 1 GB a rational choice?
[14:43] <tomreyn> and which mysql server are you using, on which ubuntu release?
[14:46] <goddard> default mysql server in 20.04
[14:47] <goddard> tomreyn: well a more rational choice would be the software seeing what the disk size is and not letting it grow to infinity
[14:49] <tomreyn> it seems that you're suggesting a change of behaviour of the mysql server software. that's something you'd take up with the developer. oracle in this case.
[14:49] <tomreyn> (AKA "good luck!")
[14:51] <goddard> well im just saying that would be the extreme rational thing, but since i dont see any situation where a user of this package would want to allow it to grow to infinity we should include this config setting by default in the package
[15:04] <dasm> goddard: usually, default behavior, is logrotate.
[15:04] <dasm> I would prefer to have full logs, aka infinity.
[15:05] <dasm> https://linux.die.net/man/8/logrotate
[15:21] <tomreyn> logrotation on mysql binary logs?
[16:18] <goddard> i dont know man after about 7 days or so i would not need the logs personally, but I guess it depends on your usage, but MySQL binlogs should at least be capped on something.  Not sure if we could just include a script to check disk space and cap it at some safe number.
[16:30] <leftyfb> goddard: in normal circumstances, the bin log should not grow out of control. For cases where it might, it is assumed the sysadmin is well aware of how these things work and that when you purposely enable the binary logs, that they also know how to configure the server to rotate the logs properly per their own personal requirements.
[16:32] <goddard> Sane defaults are okay even if all that is true and I agree with you
[16:33] <goddard> i mean that is why some distros will enable certain security measures by default but still allow you to make it insecure
[16:34] <goddard> mysql_secure_installation comes to mind
[16:34] <goddard> great little utility
[17:07] <leftyfb> goddard: bin logs are disabled by default
[18:08] <andybiker> Hi, I need a little help upgrading my wife's server. She is currently using v16 and needs upgrading to 18
[18:09] <andybiker> unfortunately the server is refusing to boot normally. The partitions seem to be okay via a Mint live usb
[18:10] <andybiker> I see it has made three partitions: boot, root and a large srv partition
[18:11] <andybiker> I am tempted to just install v 18 over the top of v 16 if I can't fix it by checking the partitions manuall
[18:16] <andybiker> does server v 18 come as 32 bit?
[20:54] <Soni> what is nova.clouds.archive.ubuntu.com and why's it so *painfully slow*?
[21:43] <Soni> and what can we do about it?
[22:58] <Soni> guess we're not migrating the VPS anytime soon if packages install at 4KB/s .-. ah well
[23:31] <tomreyn> Soni: maybe you hit a slow mirror? it points to several ip addresses
[23:32] <Soni> tomreyn: it also keeps disconnecting/retrying
[23:32] <Soni> not sure how to make it better
[23:35] <tomreyn> Soni: <ou can try to measure bandwidth using   wget -O /dev/null http://nova.clouds.archive.ubuntu.com/dists/focal-updates/main/installer-amd64/current/legacy-images/netboot/mini.iso
[23:37] <oerheks> 79,00M  9,84MB/s    in 7,9s
[23:37] <tomreyn> or using    curl -o /dev/null http://nova.clouds.archive.ubuntu.com/dists/focal-updates/main/installer-amd64/current/legacy-images/netboot/mini.iso
[23:37] <oerheks> so, the server can do it.
[23:37] <tomreyn> so this transferred fast enough from *this* mirror for you
[23:38] <JanC> maybe Soni gets connected to the wrong mirror also?
[23:38] <JanC> or Soni's VPS
[23:38] <tomreyn> wioth curl, you can test against specific mirrors using  --resolve originalhostname:originaltcpport:specificipaddress
[23:38] <Soni> it's not even going
[23:39] <Soni> --.-KB/s eta 4d and counting
[23:40] <oerheks> maybe it is your dataplan with this VPS?
[23:40] <Soni> hmm it's also not working on ipv4...
[23:40] <tomreyn> could also be that your vps' host has routing issues, or there could be any in between on the way. or they just have network trouble.
[23:41] <tomreyn> so you tried both ipv4 and ipv6 now?
[23:41] <Soni> yeah
[23:42] <tomreyn> casn you install "mtr"? a small traceroute utility
[23:42] <Soni> "small" "13.3 MB of archives"
[23:43] <tomreyn> mtr-tiny, sorry
[23:43] <Soni> do have mtr-tiny already tho
[23:44] <tomreyn> mtr -4 -c10 -w  nova.clouds.archive.ubuntu.com 2>&1 | nc termbin.com 9999
[23:45] <tomreyn> ah no this wont work, sorry
[23:45] <tomreyn> mtr -4 -c10 -w  nova.clouds.archive.ubuntu.com &>/tmp/mtr; cat /tmp/mtr | nc termbin.com 9999
[23:46] <tomreyn> this does 10 ipv4 traces with wide output format against the host, outputs to a file, then posts the file to termbin.com
[23:52] <tomreyn> Soni: ?
[23:52] <Soni> sorry afk for a bit
[23:53] <tomreyn> ah ok