| keithzg[m] | JanC: After I restarted the Amavis service it instantly started passing along emails again, and flushing the postfix queue led to the mail system instantly tossing all the ones that had been building up in the queue into the respective mailboxes. Luckily indeed nothing is actually getting lost, but this is a rather unsettling quiet failure condition . . . | 02:17 |
|---|---|---|
| keithzg[m] | I've added a mailq check to the icinga2 monitoring setup I use so I can notice (without relying on email, heh) when this happens, but alas I'm no closer yet to figuring out why it's happening . . . | 02:18 |
| tomreyn | have you considered https://rspamd.com/comparison.html | 02:28 |
| cryptodan_mobile | Find out why Mavis died | 02:34 |
| cryptodan_mobile | Amvis | 02:34 |
| cryptodan_mobile | Amavis* | 02:34 |
| keithzg[m] | cryptodan_mobile: The problem in my case is, Amavis doesn't even appear to have died; it just mysteriously isn't responding to requests. The service status, and even the output of `ps`, give the impression everything's still A-OK, with no indication otherwise . . . | 02:35 |
| cryptodan_mobile | Check mail.log | 02:36 |
| sarnold | strace it | 02:37 |
| sarnold | perf top it | 02:37 |
| keithzg[m] | cryptodan_mobile: mail.log doesn't give any indication at all as to why amavis isn't actually responding, it only shows that it isn't; there's no indication otherwise of amavis going wrong, no lines claiming it's shutting down, etc etc. | 03:09 |
| keithzg[m] | sarnold: Yeah it's getting to the point of having to dig that deep, alas I'm pretty inexpert at that level. | 03:09 |
| keithzg[m] | I guess now's the time to start finally learning ;) | 03:10 |
| keithzg[m] | Well, "now" as in the near future, it's now the Friday evening that I start my Christmas holidays, heh | 03:15 |
| cryptodan_mobile | keithzg[m]: could pastebin the log line showing amavis not working | 15:06 |
| === TheHonorableKitt is now known as ThKitten | ||
| keithzg[m] | cryptodan_mobile: As I wrote above, this time around the log line for each mail not being able to exit Postfox's queue was `(delivery temporarily suspended: conversation with 127.0.0.1[127.0.0.1] timed out while receiving the initial server greeting)`. The previous time it was instead `delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:10024: Connection refused)`, which more directly pointed to amavis | 19:38 |
| keithzg[m] | being the problem. Those lines, and that the postfix queue was visibly filling up with mail thus not being delivered, were the extent of evidence of anything going wrong that I could find. | 19:38 |
| Sven_vB | hi! what's the situation of php5 in Ubuntu 14.04 LTS trusty? ("<ubottu> Sorry, I don't know anything about php5") | 19:40 |
| Sven_vB | mostly, will it receive security updates next year? | 19:42 |
| Sven_vB | s:will it:which versions will: | 19:42 |
| tomreyn | are you planning to go into ESM? otherwise anytime is a good time to migrate off 14.04 which reach EOL in april. | 19:47 |
| cryptodan_mobile | That means that amavis died and was no longer running. A few lines up from that should be a reason why keithzg[m] | 19:47 |
| Sven_vB | anything that buys me time on upgrading my ancient web app makes my christmas holidays better. :) | 19:49 |
| tomreyn | Sven_vB: ^ other than that i'm also interested in an answer to your question, but (a) you're more likely to get this during the week, (b) with no answer i'd expect that anything "ubuntu-support-status" on a fully patched system lists as supported is supported. | 19:49 |
| Sven_vB | wow, ubottu says ESM is available even for 12.04 :D | 19:52 |
| tomreyn | until arpil, yes | 19:53 |
| Sven_vB | that's better than nothing. :) thanks! | 19:56 |
| keithzg[m] | cryptodan_mobile: Sure wasn't anything else listing anything that gave any indication in that log that amavis had died. And as aforementioned, `ps` showed it still running, as did the service status and journal. | 19:56 |
| NyanCat | tomreyn: Just an update... They don't care (In RE: OVH) | 19:56 |
| NyanCat | Right now the only way I've figured out to restart or reload networking is to restart the server after modifying interfaces | 19:56 |
| NyanCat | As for rsyslog, their response was that it's as minimal as possible | 19:57 |
| NyanCat | They didn't comment on the fact that this template is for 12.04.0 | 19:57 |
| NyanCat | er, 16.04.0 | 19:57 |
| tomreyn | NyanCat: a pity. but that's a common approach with hosters offering hosted arm hardware. maybe the arm64 situation is or may get better, but i'm not certain. | 19:59 |
| NyanCat | I'm under the impression they had a Kernel issue that essentially crippled the outbound traffic rate to 50Mbps | 20:00 |
| NyanCat | Which is now resolved | 20:00 |
| NyanCat | The issue with OVH ARM servers is that they're essentially EOL, they only built so many and they have no plans to produce anymore | 20:00 |
| NyanCat | My guess is because of this logic, they just don't give a shit | 20:01 |
| tomreyn | "resolved" by use of an outdated custom kernel which will never get updates? | 20:01 |
| NyanCat | and whatever happens happens | 20:01 |
| tomreyn | ilyad's (online.net) scaleway brand offers arm64, might be worth a try | 20:04 |
| NyanCat | why isn't apt-transfer-https installed | 20:05 |
| NyanCat | why OVH | 20:05 |
| NyanCat | I'm playing around to see if I can get updates on this server\ | 20:06 |
| NyanCat | tomreyn: looks like you can get updates for this arch by adding xenial-security and xenial-updates to the sources.list file | 20:10 |
| NyanCat | I'm going based on http://ports.ubuntu.com/ubuntu-ports/dists/ | 20:10 |
| tomreyn | NyanCat: of course you can. will it break the server? idk. | 20:11 |
| NyanCat | we're about to find out | 20:11 |
| tomreyn | also it may be better to reinstall if you already decided you dont trust their images. i never do. | 20:12 |
| NyanCat | I'm not using this server for anything critical | 20:13 |
| NyanCat | so I | 20:13 |
| NyanCat | * so I'm just screwing around to get it to work properly at this momnet | 20:13 |
| NyanCat | Just finished updating the server, issued reboot | 20:20 |
| NyanCat | Let's see if we get back online or not | 20:20 |
| NyanCat | oh hey, tomreyn | 20:21 |
| NyanCat | Welcome to Ubuntu 16.04.5 LTS (GNU/Linux 4.9.124-armada375 armv7l) | 20:21 |
| NyanCat | I got in, looks like nothing's broken so far, and now the system is a tad more secure | 20:22 |
| tomreyn | the kernel isnt, i suppose | 20:25 |
| tomreyn | "cat /proc/version" says what? | 20:25 |
| NyanCat | Linux version 4.9.124-armada375 (root@ns3034447.ip-51-255-90.eu) (gcc version 5.3.1 20160413 (Ubuntu/Linaro 5.3.1-14ubuntu2) ) #1 SMP Mon Sep 3 19:18:09 CEST 2018 | 20:27 |
| tomreyn | oh, sep 3, that's not as old as i assumed | 20:28 |
| tomreyn | but its not an ubuntu kernel, and i assume you dont know how it was built | 20:28 |
| NyanCat | If I had to guess, I would say by OVH | 20:28 |
| NyanCat | based on the hostname of the build box | 20:28 |
| NyanCat | which is kinda bad because I specifically said to use the distribution kernel and not OVH's special kernel when I imaged the machine | 20:29 |
| NyanCat | But eh, if it works it works I suppose | 20:29 |
| tomreyn | grub prefers the highest kernel version by default. ubuntu 16.04 comes with 4.4.0 | 20:30 |
| tomreyn | but then it's probably not a grub boot anyways | 20:30 |
| NyanCat | that's a negative | 20:31 |
| NyanCat | ran `dpkg -l grub*` which returned no results | 20:33 |
| tomreyn | well, it's ARM | 20:34 |
| NyanCat | but yeah, I did check in the repos and the kernel i'm running appears to be the latest available for armada | 20:38 |
| tomreyn | which repository is it from? | 20:39 |
| NyanCat | APT-Sources: http://last.public.ovh.hdaas.snap.mirrors.ovh.net/ubuntu xenial/main armhf Packages | 20:40 |
| NyanCat | OVH's own, go figure | 20:40 |
| tomreyn | upstream long term support for 4.9 is at 4.9.147, yours at 4.9.124, changelog is https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.147 | 20:43 |
| tomreyn | diff https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/?id=v4.9.147&id2=v4.9.124&dt=2 | 20:44 |
| tomreyn | looks like yours lacks spectre fixes | 20:44 |
| tomreyn | you could see what this reports https://github.com/speed47/spectre-meltdown-checker | 20:46 |
| NyanCat | reports vulnerable to spectre | 20:49 |
| NyanCat | :D | 20:49 |
| tomreyn | so you might want to try to upgrade to a newer kernel actually. but then this may also require firmware patches. | 21:32 |
| tomreyn | i guess i'd contact support and tell them you dont like what they sold you. | 21:33 |
| tomreyn | (and that they should be letting systems in configurations which are insecure out of thee box, and difficult, if at all posibble, to secure) | 21:35 |
| foo | Time to leave 14.04 and upgrade to 18.04.1 on Digital Ocean. Fresh install. Here goes nothing. | 23:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!