[00:03] <wr> RoyK, about 30 (sorry just got back now)
[00:18] <RoyK> wr: should be trivial
[00:19] <RoyK> wr: at work we have 30k or so - works well on a single vm
[00:30] <wr> RoyK, i think i'll use like 8Gb
[00:31] <sarnold> seriously, it's the 2000. Splurge on a few extra gigs so you never have to clean up kernels when /boot fills.
[01:22] <RoyK> sarnold: it's no problem to expand that later
[01:23] <sarnold> in some environments anyway :)
[01:30] <RoyK> sarnold: I'd say most - unless you refuse to use lvm :þ
[01:31] <sarnold> RoyK: I swear learning how to use lvm has been on my todo list for only a dozen years I'll get to it :)
[05:27] <cpaelzer> good morning
[12:38] <caribou> hello everyone; I just wanted you to know that I revived LP: #1662345 and took ownership of the bug
[12:38] <caribou> it is a showstopper for us to deploy cloud-init on ARM64 and, since it works on Bionic, I'll try to identify the change for an SRU to Xenial
[12:46] <ahasenack> caribou: ok, it definitely helps to have an arm64 host to try on
[12:47] <caribou> yeah, we got plenty of that
[12:47] <caribou> and a vested interest in fixing it :-)
[12:51] <ahasenack> good combination :)
[13:26] <hsn> i have ubuntu 12.04 what is end of support date?
[13:27] <rbasak> hsn: see https://wiki.ubuntu.com/Releases
[13:28] <rbasak> 12.04 is already EOL
[13:30] <hsn> so support is only for 5 years
[13:30] <rbasak> Correct.
[13:31] <rbasak> Canonical provide additional support to its customers, but Ubuntu LTS for servers has always been five years.
[13:31] <hsn> any linux distro has more then 5 years support? i have lot of linuxes out of support now here
[13:36] <blackflow> hsn: https://www.ubuntu.com/support
[13:37] <hsn> found this page https://linuxlifecycle.com
[13:38] <sdeziel> hsn: this site doesn't mention ESM that adds 2y of support to an LTS
[13:39] <Guest87713> I'm seeing lots of HTTP 404s that point to this website. http://t20.proxy-checks.com/favicon.ico: 1 Time(s) I'm running Nginx and don't have proxying configured. Should I be worried?
[13:42] <blackflow> hsn: if you're willing to change the entire distro and go through everything that assumes (different logistics, different programs, different versions of existing programs, etc...), then you can simply just upgrade to next LTS every 5 years, if you don't wanna pay for extended support beyond 5yr.
[13:44] <hsn> you will get different versions of programs after upgrade anyway no matter distro you use.
[13:44] <hsn> i want to update as less as possible to major software versions because it do not earns any money
[13:46] <blackflow> RHEL systems are radically different from debian/ubuntu based ones. you're not gonna change only program versions.
[13:47] <JanC> actually, upgrading every 2 or 4 years will make it easier to upgrade than when you wait 8 years or more
[13:49] <JanC> because even RHEL will run out of support one day, and by then everything will have changed so much you'll practically have to re-write all your code at once
[13:49] <blackflow> definitely. Netflix had a series of talks about that, why riding on development version of the OS helps them achieve that. It's another extreme (riding on dev), but it's part of the same paradigm of frequent upgrades with small steps and less to test, than rare huge bumps with months of testing and software adjustment required.
[13:50] <JanC> I doubt months of testing will be enough by then  :)
[13:50] <blackflow> right now, switching from 12.04 to, say, 18.04 is far less work than going to RHEL/CentOS 7 which is a totally diferent platform.
[13:51] <JanC> to get even just close to the same stability as a system that has been around for 10 years, you would be testing for years
[13:51] <hsn> we have RHELs and Ubuntus here. Ubuntus for development and RHEL for software testing.
[13:51] <blackflow> well yeah, in 10 years a LOT has changed, esp. in today's world of agile dev.
[13:52] <blackflow> hell, just look at Fedora and how much it changes from realease to release. Fedoras are what RHEL is made of.
[16:29] <arrrghhh> hey all.  How can I troubleshoot a service timeout?  My machine is taking a very long time to boot, I think it is waiting for a service to start and failing
[16:32] <nacc> arrrghhh: systemd-analyze blame will help you know if that's the case
[16:34] <arrrghhh> nacc, hm.  That is a great command, although perhaps you are correct that it is not the case - the longest service is 3.4s, everything else is milliseconds.
[16:34] <nacc> arrrghhh: does the total time there match what you are experiencing?
[16:34] <nacc> arrrghhh: as in, does it seem quite long
[16:35] <arrrghhh> I saw some timeouts in syslog yesterday related to snappy/snapd.  I tried removing it, and I still have a slow startup... I'm not sure if snapd is required or not tho
[16:35] <nacc> arrrghhh: well it is if you use snaps :)
[16:35] <arrrghhh> nacc, no I'd say not.  I guess there is another reason for the slow boot... seems like a timeout somewhere since the system is just sitting idle for almost 5 mins while it boots
[16:36] <arrrghhh> I don't think I use any snap packages
[16:36] <nacc> arrrghhh: `snap list` will tell you
[16:36] <nacc> and you can remove snapd if you don't need it
[16:36] <arrrghhh> yea snap is not installed haha
[16:36] <arrrghhh> "Command 'snap' not found"
[16:36] <nacc> arrrghhh: what version of ubuntu?
[16:37] <arrrghhh> 18.04
[16:39] <nacc> arrrghhh: strange, happens every time?
[16:40] <arrrghhh> nacc, yep.  It just started in the last few weeks... I don't think any changes were made, although I do randomly upgrade the system
[16:45] <arrrghhh> I really like this systemd-analyze tho.  I wonder what else it could be if it's not a service timeout
[16:45] <arrrghhh> wouldn't a NFS or CIFS mount timeout show in the syslog?
[16:45] <arrrghhh> I don't think I have any... nope none in fstab at least
[17:08] <JanC> arrrghhh: do you know at which point it hangs?
[17:09] <JanC> sometimes if filesystems aren't unmounted properly on shutdown they can be slow to start up...
[17:10] <JanC> database servers can also be slow to start up if they have lots of data to check
[17:10] <JanC> (even more so if they are not shut down properly, of course)
[17:29] <DammitJim> Do you guys know what gives a network interface the name eth0 or ens160, etc?
[17:30] <nacc> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
[17:31] <nacc> DammitJim: --^
[17:32] <DammitJim> thanks nacc
[17:34] <blackflow> DammitJim: the default order tried is defined in /lib/systemd/network/99-default.link    This part is a bit less obvious.
[17:37] <DammitJim> thanks guys
[17:37] <DammitJim> so, I had to do the net.ifnames=0 change to a server so that it would use eth0 instead of ens160
[17:37] <blackflow> yup
[17:37] <DammitJim> this server happens to use keepalived and the configuration relies on eth0 now that everything is working
[17:38] <blackflow> DammitJim: see NamePolicy=   in systemd.link(5) manpage
[17:38] <genii> Consistent Naming is both a blessing and a curse
[17:38] <blackflow> hear hear
[17:38] <DammitJim> well, now when we try to do a recovery from a backup on the cloud, the interface is coming up as ens3 instead of eth0
[17:39] <DammitJim> from what I understand, the could company doesn't use ESX, which is what we use, but they use KVM
[17:39] <blackflow> yah ens3 sounds like virtio net KVM VPS
[17:39] <DammitJim> so, I think the ethernet controller they are assigning it is an e1000 and not a VMXNET3
[17:39] <DammitJim> how do I overwrite that (again)
[17:39] <blackflow> DammitJim: should be virtio, check in dmesg
[17:39] <DammitJim> thanks for listetning blackflow
[17:40] <DammitJim> yeah, blackflow it changes to virtio if I change the controller from e1000 to virtio
[17:40] <DammitJim> but my Ubuntu VM was build in ESX with a VMXNET3 controller
[17:40] <DammitJim> I'm looking at the file you mentioned blackflow
[17:41] <blackflow> DammitJim: wait, what is the problem exactly? IF you use net.ifnames=0 kernel option, it'll be eth0
[17:42] <DammitJim> so, I would break it down in 2 things I did
[17:44] <DammitJim> 1) The default Ubuntu install on ESX would show ens160 as the network interface, so I set net.ifnames=0 and biosdevname=0 in /etc/default/grub
[17:44] <DammitJim> that changed ens160 to eth0
[17:44] <DammitJim> 2) When recovering the VM in a KVM environment, the network interface is showing up as ens3
[17:44] <DammitJim> so, how do I change it from ens3 to eth0 "again"
[17:45] <blackflow> same way. are you sure you're booting with those kernel options?
[17:46] <DammitJim> blackflow, how do you mean "same way" I already changed /etc/default/grub to use net.ifnames=0 and that changed ens160 to eth0
[17:46] <DammitJim> so, the VM has that configuration now
[17:46] <DammitJim> but when recovering the same VM in a KVM environment, it's not coming up with eth0, but with ens3
[17:46] <DammitJim> even though I already have net.ifnames=0 configured
[17:48] <blackflow> DammitJim: well are you sure that the kernel is given those options? what does    cat /proc/cmdline   say in that VM that doesn't change to eth0?
[17:48] <DammitJim> as a matter of fact, dmesg says: virtio_net virtio0 ens3: renamed from eth0
[17:48] <blackflow> DammitJim: note that /etc/default/grub per se doesn't do anything. it's a file sourced by update-grub that sets up the grub menu. is it possible different grub menu is used when you changed the VM?
[17:49] <DammitJim> cat /proc/cmdline yields: BOOT_IMAGE.... ro quiet root=UUID=.... rootfstype=ext4 enforcing=0
[17:49] <blackflow> DammitJim: yah, no net.ifnames=0
[17:49] <DammitJim> that's a good question blackflow I don't know what grub menu is used by the KVM (DR)
[17:50] <DammitJim> ok, cool! so, maybe when they recover the VM, they are passing a different parameter when booting the kernel?
[17:50] <DammitJim> I can't tell what is being used within the VM< right?
[17:50] <blackflow> DammitJim: you can force it yourself to test, in teh grub menu hit 'e' to edit the first line, navigate down to the line starting with vmlinuz, and add  net.ifnames=0 to it,   hit F10 to continue booting.
[17:51] <blackflow> DammitJim: under KVM you should have full control over the booting process and grub options.
[17:52] <DammitJim> Oh Ok... let me see what I can find
[17:52] <DammitJim> but what you have provided is invaluable!
[17:57] <DammitJim> where does one change the timeout to pick what kernel to load in grub?
[17:58] <blackflow> DammitJim: in /etc/default/grub
[17:58] <DammitJim> LOL.. thanks blackflow you are good
[17:58] <DammitJim> I was just going there telling myself I shouldn't have asked until I confirmed that wasn't it
[17:59] <blackflow> wasn't it?  did you run upate-grub after changing that file?
[18:00] <DammitJim> ah, that's what I missed
[18:01] <DammitJim> weird... I don't see a line that starts with vmlinuz after doing 'e' in the grub menu
[18:02] <DammitJim> ok, I see a line starting with /boot/vmlinuz-4.4 etc
[18:02] <DammitJim> but it has the parameters!
[18:03] <blackflow> DammitJim:   linux /boot/vmlinuz ......         ?
[18:03] <blackflow> ah yes, that one.
[18:03] <blackflow> DammitJim: so, there's net.ifnames=0 in there?
[18:04] <DammitJim> weird
[18:04] <DammitJim> hold on
[18:04] <DammitJim> it worked
[18:04] <blackflow> I'm guessing it works now because you ran update-grub, which you missed earlier.
[18:04] <DammitJim> no, I ran update-grub when I set net.ifnames=0
[18:04] <blackflow> I assumed you knew you had to run it, because you mentioned you already edited /etc/default/grub and had what you wanted, under ESX.
[18:04] <DammitJim> and that was working in ESX
[18:05] <DammitJim> I didn't run update-grub when I changed the timeout from 2 to 20
[18:06] <blackflow> DammitJim: so anyway, you have eth0 under KVM now?
[18:06] <DammitJim> yes
[18:08] <blackflow> great.
[18:12] <DammitJim> they must have a bug in their system where they change the things they load to the kernel
[18:14] <blackflow> DammitJim: as far as I know (could be wrong), under KVM you boot from the VM. It's not like Xen (sans pvgrub) with external kernel.
[18:15] <blackflow> so it boils down to which /boot was used, under which hypervisor. one of them has /boot separate from root?
[18:15] <DammitJim> hhmmmm
[18:15] <blackflow> anyway, gotta run, bbl
[18:16] <DammitJim> thanks man!
[18:34] <arrrghhh> JanC, sorry moved computers... I'm not sure which point it hangs which is a bit of the problem.  Should I look at syslog?  It doesn't seem extremely helpful
[18:38] <JanC> syslog might show what happens around the time it continues
[18:39] <JanC> syslog or journald, of course
[18:50] <arrrghhh> I guess I'll check journald?  Not familiar with that one.  syslog hasn't been extremely helpful thus far...
[18:50] <arrrghhh> bbiab
[19:43] <crandon> Today on a sever operated by someone else I faced the following problem: I created a .tar.gz with ordinary files, all owned by the user running tar, but could neither extract it, not list it's content with -ztvf. tar simply blocked and did nothing. Interestingly as root I could list the archive content just fine. Running an strace as both the regular user and root I found, that compared to where tar got stucked as regular user
[19:43] <crandon> (some futex calls after getuid() and getgid()) as root the next calls initiated some mysql queries. The machine's nssswitch.conf is configured to use mysql. Any idea what could be misconfigured and how tar could be told not to do such thing?
[19:44] <nacc> !crosspost | crandon
[19:50] <crandon> Sorry, I was told on the other channel to come here.
[19:50] <nacc> crandon: i see that now
[19:51] <nacc> crandon: does the system behave normally otherwise? what is the nsswitch.conf contents?
[19:55] <crandon> nacc:
[19:55] <crandon>        passwd: files mysql
[19:55] <crandon>        shadow: files mysql
[19:55] <crandon>        group:  files mysql
[19:55] <crandon>      
[19:56] <nacc> crandon: i see (switching to here)
[20:00] <crandon> nacc: You mean like "--no-same-owner"? No I haven't, but those should be the default. Unfortunately I don't have access to the system right now (trying to be proactive here until I get access again)
[20:01] <nacc> crandon: that's one idea, yeah
[20:01] <nacc> crandon: i really don't know, sorry
[20:01] <crandon> nacc: What I tried are --no-acls, --no-selinux, --no-xattrs
[20:01] <nacc> crandon: hrm
[20:02] <crandon> Ok, thanks. It's just annoying when you try to do some work and you got stuck on something like extracting a simple tgz...
[20:03] <crandon> nacc: BTW even if I'd find some tar switches which allow the extraction I'd still be stuck as the problem is triggered when running pyenv to which I'm not sure how I could pass the tar options...
[20:04] <crandon> nacc: Anyway, thanks for your time!
[20:10] <nacc> crandon: yeah not sure; it's almost certainly while tar is doing some lookup
[20:11] <nacc> crandon: i'm just wondering if the system is generally broken for that user