[06:29] <lordievader> Good morning
[06:33] <wretchedspirit> sup
[06:36] <lordievader> Doing good here, how are you wretchedspirit ?
[06:39] <wretchedspirit> same here, playing some rocket league before I start working :0
[07:38] <pitastrudl> what is there more to having a dedicated server at a company compared to a VPS? i know, if you get the real deal, you have your own resources to deal with
[07:38] <pitastrudl> but what more can i do?
[07:39] <pitastrudl> i am not sure what more is there to configure, speficifally im looking on getting one from online.net
[07:45] <JanC> pitastrudl: depends on how online.net implements "VPS"
[07:48] <JanC> but in general, the provider should have documentation about whatever configuration you need (sometimes they have a wiki for such things)
[07:49] <pitastrudl> JanC: ah ok
[07:50] <pitastrudl> well i was mostly referring to a VPS like they have at digitalocean
[07:50] <JanC> in most cases you probably don't need any special setup
[07:50] <pitastrudl> i see
[07:57] <JanC> the main setup is probably about how you configure IPv4 and/or IPv6
[07:59] <pitastrudl> i see
[08:05] <JanC> but I would expect them to set that up by default
[10:14] <arul> i want host my odoo application in in ubuntu server.. anyone please give the details about low ubuntu-servers in low cost
[10:15] <arul> sorry ubuntu servers in low cost
[10:24] <TafThorne> arul: are you looking to hose in house and want advice on buying hardware or are you asking for a cloud solution?
[10:25] <arul> TafThorne, yes. cloud solution like digital ocean
[10:27] <arul> for deploying my odoo application
[10:29] <TafThorne> arul: I cannot provide that recommendation.  Thank you for clarifying though.  Hopefully someone can help.  You see a little more activity in this channel once the US wakes up.
[10:29] <arul> TafThorne, thanks for ur reply.
[11:41] <rickardo1> How fast should network between webserver and mysql be.. is it necessary with 1 Gbit?
[11:42] <ikonia> that depends on what you are doing
[11:42] <ikonia> and your system and application needs
[11:42] <ikonia> you're not doing enterprise stuff so "no"
[11:54] <andol> rickardo1: Might also be that the latency matters more than the bandwidth.
[11:55] <rickardo1> andol: ok, I think I need to measure the data flow get a better picture.. The service I provide shall handle maximum 50 requests per second
[11:59] <ikonia> rickardo1: I really think you don't need to do that
[11:59] <ikonia> it really sounds like you don't understand capacity planning or networking at this stage, yet you're trying to "provide a service"
[12:00] <rickardo1> ikonia: I am no sysadmin, that's right.. I am a backend developer..
[12:01] <JanC> really depends whether that's 50 req/s average or peak  :)
[12:01] <rickardo1> peak
[12:02] <JanC> and what sort of requests those are
[12:03] <rickardo1> JanC: A rest api, consume and respond with json
[12:05] <rickardo1> JanC: An algorithm with cpu heavy combinatorial optimization is the heart of the application.
[12:06] <JanC> the "form" isn't very relevant; the amount of work and/or the amount of results is
[12:07] <JanC> if you aren't sure, measure
[12:08] <rickardo1> JanC: Everything is on a 8 core 8 GB VPS distributed in docker containers in the moment.. and the bottleneck is mysql therefor I want to move it to it's own server without docker so it can utilize all of the hardware.
[12:08] <rickardo1> *) at the moment
[12:09] <JanC> so, the first thing you want to do is check if you can optimise the database queries and/or move more work from the app to the DB
[12:11] <JanC> and/or maybe figure out how to spread queries to multiple databases
[12:12] <JanC> (depending on what the real issue is)
[12:48] <ppetraki> rickardo1, is mysql bound on the compute or io side? htop with additional columns to show disk R/W would tell you which side your problem is on pretty quickly.
[12:49] <rickardo1> ppetraki: io side
[12:49] <ppetraki> rickardo1, are you writing more than you're reading?
[12:50] <ppetraki> rickardo1, how much is hiting the backend relative to mysql's contribution? (dstat)
[12:56] <cpaelzer> rbasak: the next version of squid tests is submitted to debian 500LOC instead of 2.5k and many cleanups
[12:57] <cpaelzer> rbasak: do you already have plans for the squid merge (schedule wise)
[12:57] <cpaelzer> it might be worth to wait if they accept it the next few weeks
[13:05] <rizonz> is someone preseeding against an 64bit only mirrir ?
[13:07] <rizonz> my preseed finishes but cannot find some packages which are there in 64bit
[13:19] <rbasak> cpaelzer: \o/
[13:19] <rbasak> cpaelzer: no plans. We should work out a plan (for all the merges).
[13:20] <cpaelzer> rbasak: yeah for now I'm dropping those that come to my mind into the blueprint as-is
[13:20] <cpaelzer> rbasak: but I wanted to invite for a shrot daily sync anyway - that would be a perfect place
[13:20]  * cpaelzer is doing so now
[13:26] <rbasak> Agreed
[13:29] <cpaelzer> nacc: It seems we officially have no overlapping times :-/, please get in touch if that is too early for you
[13:30] <cpaelzer> nacc: we might create a more interesting schedule that bites each of us in alternating patterns or so
[13:40] <rizonz> is someone able to do some testst against a 64bits mirror only ?
[13:55] <patdk-wk> what is a 64bit only mirror?
[14:02] <cpaelzer> without i386 packages mirrored I assume?
[14:02] <patdk-wk> dunno
[14:03] <patdk-wk> and no idea it is even a mirror of packages
[14:03] <patdk-wk> it's just a mirror, could be 64bit glass
[14:54] <jamespage> cpaelzer: btw I have ovs 2.7.0 prepped and ready to push to artful alongside openstack pike-1
[14:54] <jamespage> https://bileto.ubuntu.com/#/ticket/2732 to track
[15:02] <cpaelzer> cool thanks jamespage
[15:02] <cpaelzer> I'd wish to get a chance on vhost-client mode then this cycle
[15:12] <nacc> cpaelzer: ok -- that's fine, in the future, it makes me grumpy to wake up to be told i missed a meeting scheduled while i was asleep. Old IBM manager trick :)
[15:18] <cpaelzer> nacc: so you are ok with the time as is atm?
[15:19] <cpaelzer> nacc: and to be clear, I expected you to not be around today for you hopefully still sleeping fine
[15:24] <nacc> cpaelzer: ack, yeah it's fine
[15:24] <nacc> cpaelzer: and the grumpiness was at gcal, not you :)
[15:26] <cpaelzer> nacc: ok thanks
[15:26] <cpaelzer> nacc: I ran into a few usd issues when I wanted to push a few more easy ones
[15:27] <cpaelzer> nacc: if you need something from me for that please let me know
[15:27] <cpaelzer> nacc: oh I see mail replies
[15:27] <cpaelzer> let me read :-)
[15:27] <nacc> cpaelzer: ack
[16:56] <rizonz> anyone mirroring debian with debmirror ? I can't get main/installer-amd64 in
[18:42] <CodeMouse92__> I've got two scripts scheduled to run on @reboot on my server's user-cron (crontab -e), but they don't seem to run. Ever.
[18:43] <CodeMouse92__> I know (a) the scripts themselves work - I can run them manually, and they're fine. They're marked +x
[18:43] <sarnold> CodeMouse92__: can you pastebin the crontab in question?
[18:43] <CodeMouse92__> (b) I am not finding any errors in the system logs, unless I'm looking in the wrong place
[18:43] <sarnold> cron emails errors
[18:43] <CodeMouse92__> sarnold: Sure. Did you want the scripts too?
[18:43] <CodeMouse92__> sarnold: Yeah, no mails either
[18:43] <sarnold> CodeMouse92__: not immediately but if the crontab looks fine, then yeah, that's the next step :)
[18:44] <CodeMouse92__> sarnold: https://bpaste.net/show/230a4ba6d0f0 <-- NOTE: I added the ### COMMENTS ### *just now in pasting*. Those are not in the file
[18:45] <nacc> CodeMouse92__: and you know @reboot runs at startup, right?
[18:45] <CodeMouse92__> I know some things can't run right off after reboot, thus why I have it wait two minutes
[18:45] <CodeMouse92__> nacc: Yup.
[18:45] <CodeMouse92__> My server has hours (for multiple reasons I am not discussing)
[18:45] <nacc> CodeMouse92__: you might want to use absolute paths
[18:45] <nacc> in general in crontabs
[18:45] <CodeMouse92__> nacc: Uhm...I am.
[18:45] <nacc> "sleep 120"
[18:45] <sarnold> that was my expectation but the VBoxManage line apparently works fine :)
[18:45] <nacc>  /bin/sleep 120
[18:46] <drab> CodeMouse92__: do you see no messages in the logs at all about the cront running or the script seems to not be doing its job?
[18:46] <CodeMouse92__> nacc: Ah, well, I can. Although that works elsewhere.
[18:46] <sarnold> huh I thought that was a shell built-in. guess not.
[18:46] <CodeMouse92__> drab: Absolutely nothing weird.
[18:46] <drab> I had a cron recently that actually was running, but not doing its job for other reasons
[18:46] <CodeMouse92__> sarnold: It *is*. My root cron works great
[18:46] <drab> CodeMouse92__: so you don't see a CRON line in the logs saying the job ran, correct?
[18:46] <CodeMouse92__> And it has 'sleep 60' commands
[18:46] <sarnold> CodeMouse92__: I'd just blindly try removing the 'sleep 120;' bits and put them into the script, if they only ever get run via this file..
[18:46] <CodeMouse92__> drab: I don't see either way for this file. Only for the root one
[18:47] <CodeMouse92__> sarnold: I can. Although, i actually added those as a *result* of the script not seeming to run
[18:47] <sarnold> CodeMouse92__: oh. odd.
[18:47] <sarnold> CodeMouse92__: ok, I guess then time to pastebin the scripts :)
[18:47] <sarnold> maybe they are running but just not doing what you expect
[18:47] <drab> ok, one way I've debugged things before was to add a touch /tmp/test_cron && my_original_command
[18:47] <nacc> so there's another hack you could do
[18:47] <nacc> if the second line works
[18:47] <CodeMouse92__> (BTW, adding the sleep to the scripts would be BAD - I need to use the same scripts to start them on cue WITHOUT waiting
[18:47] <nacc> make it that scirpt && line3 && line4
[18:47] <nacc> and see what happens
[18:49] <CodeMouse92__> sarnold: https://bpaste.net/show/a969fee8b09e <-- both files are in the same paste for brevity, so I used the ############# long comments to separate the files
[18:49] <CodeMouse92__> NOTE: both scripts do EXACTLY what I expect if I run them manually
[18:49] <CodeMouse92__> From the same user as what the cron is running as
[18:50] <CodeMouse92__> nacc: I can try that if we find nothing - I'd have to restart the server is the only gotcha, but I can try
[18:50] <drab> CodeMouse92__: have you tried a simple one liner? like /usr/bin/touch /tmp/reboot_cron ?
[18:50] <drab> and see if that runs at all
[18:50] <sarnold> I'd change both those to #!/bin/bash and /usr/bin/screen and a direct path to supybot too..
[18:50] <CodeMouse92__> drab: That would do some very bad things to my system. >.>
[18:50] <CodeMouse92__> Doubling some processes, etc. yeah, I'd just need to reboot
[18:51] <CodeMouse92__> sarnold: I was told NOT to use #!/bin/bash by someone. I actually prefer your shebang
[18:51] <drab> eh? I don't see what very bad thing it'd do to your system...
[18:51] <sarnold> the PATH in cron is very very short. so either set PATH to what you want, or just use full paths..
[18:52] <sarnold> CodeMouse92__: the env thing is usually used by people who have python or ruby scripts or something and want them to work on windows and os x and linux and can't rely on them being the same paths, or want to use virtualenv or rvm or something to install a dozen different versions of ruby or python at once
[18:52] <CodeMouse92__> Want to see something weird, though? let me show you the startup_sparrowsgate script, which IS working....
[18:52] <sarnold> CodeMouse92__: I think shell scripts that are meant to run on linux should just be simple and not require starting up another pointless process. you knwo the path :)
[18:53] <CodeMouse92__> This one works: https://bpaste.net/show/ad97c4dbf763 (weirdly, I forgot the shebang)
[18:53] <CodeMouse92__> sarnold: Well, good to know. changing THAT back
[18:53] <sarnold> CodeMouse92__: heh, iirc linux just uses /bin/sh if a script is missing a shebang
[18:54] <CodeMouse92__> sarnold: Regardless, the relative path of 'screen' is used in that one without a problem
[18:55] <sarnold> yeah, so you can probably skip that change then
[18:55] <CodeMouse92__> I did set the absolute paths and added the touch commands to the scripts, just to see if they run at all
[18:55] <CodeMouse92__> So, let me try going for a quick reboot, ensure nothing explodes
[18:55] <CodeMouse92__> slash-make sure it works
[18:58] <CodeMouse92__> While I'm waiting, I have one other theory.
[18:59] <CodeMouse92__> Could the second line in the cron be somehow NOT releasing something, and thus the cron doesn't continue?
[18:59] <CodeMouse92__> Or does cron not work that way?
[19:00] <CodeMouse92__> Oh! Hey! It's working now!
[19:00]  * genii makes more coffee
[19:01] <CodeMouse92__> Okay. NEXT PROBLEM: both scripts are now running, but according to the log for one, it isn't finding node.js, which IS installed....
[19:01] <CodeMouse92__> Probably a path thing again, but I'm not sure.
[19:02] <CodeMouse92__> node.js exists in /opt/nodejs, and if I manually run the /opt/scripts/other/start_etherpad script, it works fine. but from the crontab, no dice....
[19:03] <nacc> CodeMouse92__: when run manually is /opt in your PATH?
[19:03] <CodeMouse92__> nacc: OH. MY. GOSH. Am I really that silly???????
[19:03]  * CodeMouse92__ checks
[19:03] <CodeMouse92__> Oh.
[19:03] <CodeMouse92__> Yes
[19:03] <nacc> CodeMouse92__: that's why i said earlier use absolute paths :)
[19:03] <CodeMouse92__> It is - https://bpaste.net/show/20b16452cfaf
[19:04] <nacc> right when run manually
[19:04] <nacc> but not when run via cron?
[19:04] <CodeMouse92__> (I actualy ran echo $PATH, but I typo'd
[19:04] <nacc> you cannot assume your path is anything in a crontab
[19:04] <nacc> *shouldn't
[19:04] <drab> you can assume it's nothing :)
[19:04] <nacc> drab: :)
[19:04] <CodeMouse92__> nacc: I see. Okay, so, how can I ensure that's doing what it's supposed to? Etherpad's start script isn't something I wrote
[19:04] <nacc> CodeMouse92__: any invocation of any binary should use absolute paths
[19:05] <nacc> CodeMouse92__: in the crontab script path up until the last exec
[19:05] <sarnold> your PATH in cron is probably just /bin:/sbin:/usr/bin:/usr/sbin. That's usually it.
[19:05] <nacc> sarnold: yeah
[19:05] <drab> anybody knows with qemu how to tell it to disable floppy and cdrom? I don
[19:05] <drab> 't have them called out as parameters and the devices are still created
[19:05] <drab> and it's erroring on the floppy
[19:05] <nacc> drab: can you pastebin the qemu line and output?
[19:06] <nacc> drab: you need -nodefaults usually
[19:06] <CodeMouse92__> nacc: Is there a good way to add to cron's PATH? Changing the etherpad scripts will be a nightmare
[19:06] <nacc> drab: floppy and cdrom are always there 'by default'
[19:06] <sarnold> drab: I think -nodefaults is what you're looking for
[19:07] <nacc> CodeMouse92__: i think you can set PATH at the top of a crontab, check `man 5 crontab`
[19:07] <sarnold> CodeMouse92__: set the PATH in your script there
[19:07] <nacc> CodeMouse92__: the way cron parses it is weird
[19:07] <nacc> "Note  in particular that if you want a PATH other than "/usr/bin:/bin", you will need to set it in the crontab file."
[19:07] <CodeMouse92__> sarnold: Now, changing the path variable IN my script...that won't ultimately cause it to have ten thousand instances of it in PATH by running that script every day, right?
[19:07] <drab> http://dpaste.com/3Q6NM71
[19:08] <CodeMouse92__> nacc: Right...I'll do that.
[19:08] <drab> sarnold: ah! I think that's a winner, I recall seeing it in some virt-manager generated line
[19:08] <drab> trying that
[19:08] <sarnold> nacc: hah so it's even half the size I expected? typical cron.
[19:09] <nacc> sarnold: yeah
[19:09] <nacc> sarnold: basically if you need PATH to be something, always set it
[19:09] <nacc> to exactly what you need
[19:12] <CodeMouse92__> nacc: Well, all this definitely makes sense now. You've demystified cron for me, TY :3
[19:12] <CodeMouse92__> I'll reboot and see if this works now
[19:12] <drab> sarnold: mmmh, that seems to have also done something else I did not want...
[19:12] <drab> sarnold: I no longer get curses output
[19:12] <drab> instance doesn't look like booting
[19:12] <nacc> drab: nodeaults turns off the display
[19:13] <nacc> drab: read `man qemu-system-x86_64` :)
[19:13] <drab> yeah just stuck there
[19:13] <nacc> drab: or
[19:13] <drab> well, it's not booting tho
[19:13] <nacc> drab: use libvirt! :)
[19:13] <drab> lol
[19:13] <nacc> drab: like i said ... a week ago? :)
[19:13] <nacc> it feels like a week ago
[19:13] <nacc> and you'd be up and running by now
[19:14] <drab> you're right and when you're right you're right :)
[19:14] <sarnold> nacc: bah don't discourage the guy I want him to finish his work and then publish it somewhere so I can steal it :D
[19:14] <drab> however I'd probably understand close to nothing about qmeu
[19:14] <nacc> drab: being able to run qemu does not equate to understanding it :)
[19:14] <drab> now I feel I have a reasonable enough understand of the options, how stuff connects to what etc
[19:14] <nacc> it's the craziest code i've seen in a long time
[19:14] <nacc> but yeah, it's a good point
[19:15] <drab> yeah, well, I can't run things I don't understand, at least at a minimum level
[19:15] <nacc> honestly, we need a tool between qemu and libvirt
[19:15] <nacc> i think it's kvmtool
[19:15] <nacc> but i can't recall
[19:16] <drab> there is such a thing, but I didn't try it
[19:16] <CodeMouse92__> And it ALL works! Thanks drab, nacc
[19:16] <drab> tbh I spent the first 2 days trying to figure out what the difference between qemu and kvm was...
[19:17] <drab> some ppl use the names interchangeably
[19:17] <drab> and whatnot
[19:17] <nacc> drab: kvm is a qemu mode
[19:17] <nacc> drab: technically it's a technology
[19:17] <nacc> for linux, using qemu is so rare these days -- only for cross-arch
[19:17] <nacc> (imo)
[19:18] <drab> or for when you need to run things like zfs and nfs-kernel-server that you don't want to run on the host
[19:18] <drab> :)
[19:18] <nacc> drab: but you'd be using kvm for that, presumably
[19:18] <nacc> drab: by qemu i meant unaccelerated qemu
[19:18] <drab> oh, doh, you got me :)
[19:18] <drab> see, I got it now
[19:18] <nacc> drab: kvm is accelerated qemu
[19:18] <drab> right
[19:18] <nacc> (hardware accelerated that is)
[19:25] <drab> ok, answer was "-nodefaults -vga std
[19:25] <drab> "
[19:25] <drab> no more silly floppy
[19:25] <drab> and I got my console back
[19:26] <nacc> drab: yep, that feels familiar
[19:27] <nacc> as to why everyone uses -nodefaults and yet -defaults are still the default...
[19:27] <nacc> no answer :)
[19:28] <drab> btw for whatever reason I'm not getting, zfs performances are higher on the KVM with a ZVOL than ton the host on the pool the ZVOL comes from
[19:28] <drab> same test file with fio and all
[19:29] <drab> the VM has even less mem theoretically
[19:30] <nacc> drab: could it be less contention for the cpu in the vm itself for zfs? i'm not sure how cpu bound zfs is, but if the vm is pinned (which you might want to do for performance), then it might be ok
[19:30] <nacc> drab: if you are performance-focused, you might want to look at hugepage backing your guest
[19:32] <sarnold> drab: time to fiddle with the caching flags for your disks ;) some are for fvery-fast-very-lossy and some are for slow-and-safe. :)
[19:33] <nacc> yeah that's true too
[20:43] <drab> nacc: good point about pinning, it's not, I need to look at that whole chapter for both kvm and lxc
[20:44] <nacc> drab: esp. if you are doing something like using a vm for backing storage to other vms
[20:44] <nacc> drab: you really don't want the storage to get swapped out
[20:45] <drab> nacc: yeah no, I don't want that. however "pinning" the way I've done it before is about CPU, not mem, bit from what you said it sounds like that's what you're talking about
[20:45] <drab> if the mem is already assigned to the guest tho, won't that be "reserved"
[20:46] <drab> other than oom kicking in ande deciding that qemu must die
[20:46] <nacc> drab: you can pin a vcpu to a lcpu so that it doesn't encounter thrashing at the cache level
[20:46] <nacc> drab: but then you also, probably, want to lock your vm into memory
[20:46] <nacc> drab: there is mlock to do that, or you can use hugepages (which will be evne better, presuming you set it up right )
[20:46] <drab> ok, the cpu part I get, the second one I'm not familiar with. but maybe google is, I'll ask it :)
[20:47] <nacc> drab: tuning vms is a rather complicated topic
[20:47] <drab> so I looked into hugepages briefly and sort of put it off to later
[20:47] <nacc> drab: yep it shouldn't be a huge deal
[20:47] <drab> one of the thing I found was this idea of rtansparent hugepags
[20:47] <nacc> but it will eventually potentially be an issue
[20:47] <drab> which seemed to imply you didn't need to set up hugepages anymore
[20:47] <nacc> depending on how overcommitted your host is
[20:47] <nacc> drab: thp works, generall
[20:47] <nacc> but pre-allocating hugepages performs better
[20:47] <drab> ok
[20:47] <nacc> as the kernel doesn't have to scan to figure out what base pages can be promoted to hugepages (whih takes cpu cycles and time)
[20:48] <drab> fair enough
[20:48] <nacc> drab: so often, my recommendation would be to use thp
[20:49] <nacc> drab: but if you have a specific use-case, being explicit an maximize  performance
[20:49] <nacc> thp helps everything -- which means some thing that maybe don't need to be inhugepages can be there
[20:49] <nacc> and on some level, due to fragmentations, hugepages are a resource
[20:49] <nacc> *precious* resource
[21:07] <drab> nacc: all I'm finding about pinning is using taskset on the host. I've seen some posts about some vcpu argument to qemu, but it seems a patch from way back when that was not applied afaics
[21:09] <drab> https://patchwork.kernel.org/patch/9361617/
[21:19] <pcn> Hi everyone.  Is there documentation on the linux-aws packages?  I'd like to understand how these are maintained and how I'm supposed to use them
[22:04] <sarnold> pcn: I suspect you just apt-get install linux-aws, that will bring in the other aws-specific kernels. you may need to edit grub or use the grub interface to test it out and if you like it, maybe uninstall the other linux-generic or other metapackages
[22:18] <pcn> OK, thanks.
[23:05] <nacc> drab: i'd have to go look