[00:02] <axisys> sarnold: well i was capturing for udp pkts from this server .. nothing going out
[00:02] <axisys> no pkts even trying to send to remote.. pure quite
[00:03] <sarnold> axisys: how about trying nc to send udp to the remote host?
[00:03] <axisys> ok.. let me check
[00:04] <sarnold> axisys: that would let you sort out if it is a matter of configuring rsyslog or fixing firewall rulesets or routing or something similar
[00:04] <axisys> right.. how do I generate a udp pkt with nc
[00:05] <axisys> got it..
[00:07] <axisys> ok nc 192.168.1.100 works .. remote server gets the pkts.. so it is issue with rsyslog then
[00:08] <axisys> nc 192.168.1.100 514
[00:08] <sarnold> are you using -u ? or not
[00:09] <axisys> nc -u 192.168.1.100 514 works too.. pkt recvd on remote side
[00:09] <sarnold> oh okay
[00:09] <sarnold> so that leaves troubleshooting rsyslog :/
[00:09] <axisys> right..
[00:13] <sarnold> hrm, do you need to restart or reload rsyslog to pick up changes? have you started or restarted rsyslogd since adding this line?
[00:13] <axisys> I did .. let me do it again
[00:15] <axisys> I killed it and it came back up right away
[00:16] <axisys> ah.. upstart
[00:18] <axisys> this is pre-start /lib/init/apparmor-profile-load usr.sbin.rsyslogd and /etc/default/rsyslog has RSYSLOGD_OPTIONS="" and then just an exec rsyslogd $RSYSLOGD_OPTIONS ..
[00:20] <sarnold> do you have anything in dmesg?
[00:22] <axisys> [20646747.288516] init: rsyslog main process ended, respawning
[00:23] <sarnold> heh. handy :) but sadly not much help
[00:23] <axisys> lol
[01:03] <sarnold> nacc: pity this was marked private security .. it might have been easier to address ~ten days ago. Is this something for your team? 1753018
[02:54] <nacc> sarnold: looking
[02:54] <nacc> sarnold: yes
[02:55] <nacc> sarnold: i'll make sure it gets noticed tmrw
[06:28] <cpaelzer> good morning #server
[07:24] <lordievader> Good morning
[12:22] <Mava> i'm facing quite an interesting case with sas storage in hp server. the storage is configured to be 12Tb, but the ubuntu server sees with blockdev only 1.1Tb. Any tips ?
[12:26] <OpenTokix> Mava: wrong partition table?
[12:27] <Mava> OpenTokix: should it affect the information blockdev reports ?
[12:29] <OpenTokix> Mava: It's where the sectors and sector-size is stored.
[12:30] <Mava> OpenTokix: good point, unfortunately converting it to gpt did not fix anything.
[12:32] <OpenTokix> Does the num sectors and sector size add up to wrong or right?
[12:32] <Mava> once you said: both are wrong
[12:33] <Mava> like. it calculates it right
[12:34] <Mava> but the amount of sectors and the sector size is not the ones specified in the array configuration utility
[12:37] <Mava> now i've got a clue. thanks OpenTokix !
[12:43] <Cheez> how do people monitor mdadm arrays? ilke, I have 2 different arrays, a 2 drive raid 1 for / and /boot and an 8 drive raid 6 for /mnt/storage - I know I can look at mdadm --detail and check the state is clean anddisks are active, but is there a best practice way of keeping on top of it in case a disk fails?
[12:44] <patdk-lap> I just let munin do it for me
[12:47] <dlloyd> you can also configure MAILADDR in mdadm.conf for alerting
[12:48] <Cheez> ooh, that'd probably be good enough
[12:49] <Cheez> although i presume it expects there to be a local MTA rather than being able to specify an SMTP server?
[13:10] <cpaelzer> ahasenack: rbasak: did you ever realize that system looses "fast" error messages?
[13:10] <ahasenack> not really
[13:11] <ahasenack> what did you (not) see?
[13:11] <OpenTokix> Mava: cool, good luck
[13:11] <rbasak> Am I missing some context here?
[13:11] <cpaelzer> slow: http://paste.ubuntu.com/p/2nybTkkm3h/
[13:11] <cpaelzer> fast: http://paste.ubuntu.com/p/mSfYPHssfT/
[13:12] <cpaelzer> essentially echo + exit vs echo + sleep + exit
[13:12] <cpaelzer> result: http://paste.ubuntu.com/p/TT38mQ83Mf/
[13:12] <ahasenack> you must be debugging something interesting :)
[13:13] <cpaelzer> many services that have wrappers do like "initial check, error out if failed"
[13:13] <cpaelzer> I realized while working on one that the message isn't there
[13:13] <cpaelzer> ahasenack: this is what got me to this
[13:14] <ahasenack> for what is worth, I do find that the logs from systemd are lacking detail
[13:14] <cpaelzer> ahasenack: rbasak: do you see that the "fast" output is not in the status info
[13:14] <ahasenack> maybe because of that
[13:14] <rbasak> Interesting
[13:14] <cpaelzer> ahasenack: I find the logs better accessible than before sytemd, but this is odd
[13:14] <cpaelzer> I just wondere - might this be a general flaw
[13:14] <cpaelzer> or do I miss something
[13:14] <rbasak> I can't think of any architectural reason why there has to be a race like that
[13:14] <cpaelzer> but I feel my example is not simplified a lot, and still reproduces
[13:14] <ahasenack> are they also not in the output of journalctl?
[13:15] <cpaelzer> ahasenack: the are in the journal
[13:15] <ahasenack> just not in the status output?
[13:15] <cpaelzer> just not on systemctl status, which is where people look first
[13:15] <ahasenack> ohh
[13:15] <ahasenack> that just got more interesting
[13:15] <cpaelzer> an i mean, sleep fixes it c'mon we are not in 1998
[13:16] <ahasenack> sleep fixes so many things
[13:16] <cpaelzer> I tried to echo to stderr (unbuffered) but that didn't change anything
[13:16] <ahasenack> how do you echo unbuffered?
[13:16] <ahasenack> or is that stderr's default behavior
[13:16] <cpaelzer> the default of stderr
[13:17] <cpaelzer> ahasenack: rbasak: but none of you points out obvious flaws right - so I might ask #systemd then
[13:17] <ahasenack> and even after a while systemctl status still won't show it?
[13:17] <ahasenack> right
[13:17] <cpaelzer> ahasenack: not after 7 minutes
[13:17] <ahasenack> good enough
[13:17] <ahasenack> what about the <3> prefix, does that mean anything special?
[13:18] <ahasenack> or just log level
[13:18] <ahasenack> (which would be special)
[13:18] <cpaelzer> ahasenack: that makes log levels for journal/systemd
[13:18] <cpaelzer> but yeah, lets try without
[13:19] <cpaelzer> removing the log level has no effect
[13:19] <cpaelzer> but was worth a try
[13:19] <ahasenack> ok
[13:20] <cpaelzer> sleep 0.01 is enoug
[13:20] <cpaelzer> h
[13:21] <cpaelzer> so just any sort of interruption
[13:29] <cpaelzer> rbasak: ahasenack: xenial not affected, but showing in bionic
[13:33] <TJ-> Is there a recommended way to set the FQDN on a pure IPv6 setup. Equivalent to the IPv4 /etc/hostname "127.0.1.1 hostname.domain.tld hostname" ? The "::1" is generally set to a similar list as '127.0.0.1' but do is there an IPv6 version of '127.0.1.1' ?
[13:34] <patdk-lap> no
[13:34] <patdk-lap> but I dunno why your using loopback for fqdn, that just doesn't work
[13:34] <TJ-> That explains why my search-fu has been failing :)
[13:34] <patdk-lap> you could always use ::127.0.1.1
[13:35] <TJ-> I'm not, I've been investigating a pure IPv6 deployment/config with IPv4 totally disabled in kernel to provoke bugs and other problems
[13:36] <TJ-> Recommendation is not but FQDN in /etc/hostname; if sticking to that then there ought to be a recommended location for the domain
[13:36] <TJ-> s/but/put/
[13:36] <OpenTokix> Anyone know what the point of the 127.0.1.1 address is? - From what I understand it's just a smeantic differnce. No technical difference.
[13:37] <TJ-> OpenTokix: i /think/ originally it was to prevent errors where 'localhost' was removed from the '127.0.0.1' entry
[13:37] <OpenTokix> since the entire network 127.0.0.0/8 is the same interface.
[13:43] <patdk-lap> no
[13:43] <patdk-lap> it's so you can have multible things going on
[13:43] <patdk-lap> I bind a lot of things to different loopback ip's
[13:45] <cpaelzer> rbasak: ahasenack: FYI that is https://github.com/systemd/systemd/issues/2913
[13:46] <ahasenack> I was following your discussion in #systemd
[13:46] <ahasenack> nice that you found the bug
[13:46] <cpaelzer> it essentically fails to associate with the unit before it is gone
[13:46] <cpaelzer> and therefore missing on systemctl status and journal -u output
[13:47] <ahasenack> that's an old bug :/
[13:47] <cpaelzer> it does not affect my xenial system it seems
[13:50] <cpaelzer> as I understand it we might loose any late message
[13:50] <cpaelzer> as long as it comes very shortly before the PID goes away
[13:50] <cpaelzer> :-/
[13:51] <cpaelzer> But quite often the last message before something dies is the most important one
[13:52] <OpenTokix> patdk-lap: yes, but they all bind to the same interface.
[13:53] <patdk-lap> isn't that the whole point?
[13:53] <patdk-lap> if it didn't, useless
[13:55] <OpenTokix> it is very useful, but also a magic interface
[13:56] <patdk-lap> nothing magic about it
[13:56] <patdk-lap> now, dummy, that is a magical interface :)
[13:56] <OpenTokix> It binds to a whole /8, but only one of those ips is showing.
[13:57] <patdk-lap> no it doesn't
[13:57] <patdk-lap> it binds to exactly one ip
[13:57] <patdk-lap> but it *routes* the rest
[13:57] <patdk-lap> just like anything else
[14:01] <cpaelzer> rbasak: ahasenack: for the sake of awareness on the Ubuntu side I filed bug 1756081
[14:05] <ahasenack> ok
[14:25] <Slashman> hello, I have an issue with the HWE kernel for xenial "linux-image-4.13.0-37-generic", it's freezing my server some minutes after the boot, is this a known issue?
[14:28] <rbasak> Slashman: try #ubuntu-kernel
[14:28] <Slashman> rbasak: thx
[14:44] <ahasenack> rbasak: hi, are you reviewing https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/341461 or was that comment just a drive-by?
[14:45] <rbasak> ahasenack: I claimed the review as I was curiousu to look anyway
[14:45] <ahasenack> cool
[14:45] <rbasak> cpaelzer: what does EFF_ stand for OOI?
[14:45] <cpaelzer> EFFECTIVE
[14:45] <cpaelzer> a rename can be done
[14:45] <rbasak> Ah
[14:45] <cpaelzer> just let men know
[14:45] <cpaelzer> me
[14:46] <cpaelzer> I just replied for the default conffile change
[16:28] <madLyfe> https://gist.github.com/61a118ed1c8437e2b480c6049cee07d7
[16:28] <madLyfe> not sure why i got those errors after running update && upgrade
[16:28] <sarnold> try running it as root
[16:45] <madLyfe> run commands it suggests or run update && upgrade again?
[16:46] <sarnold> update and upgrade again as a first step
[16:46] <madLyfe> its odd because i have 4 identical servers and only two of them had these errors.
[16:47] <madLyfe> and i always update them at the same time.
[17:05] <JimBuntu> madLyfe, what happens if you try `touch /var/lib/apt/lists/test.txt` ?
[17:06] <madLyfe> well it looks like the updates are going through at this point with root.