[00:33] <sarthor> HI, Can we install python_bidi on ubuntu-server 14.04? is there any howto, if Yes.
[01:04] <Fieldy> hello, how do I stop a process (in this case nginx) from starting at boot?
[01:08] <sarnold> Fieldy: if it has an upstart configuration file in /etc/init/nginx, echo manual > /etc/init/nginx.override
[01:08] <sarnold> Fieldy: details here: http://upstart.ubuntu.com/cookbook/#override-files
[01:09] <Fieldy> sarnold: unfortunately it doesn't
[01:09] <sarnold> Fieldy: sysvinit scripts?
[01:09] <Fieldy> sarnold: it has a file in /etc/init.d/
[01:11] <sarnold> Fieldy: there's some friendly little utility to manage those symlinks but I can never remember the name of the thing. I think if you delete all the /etc/init.d/rc*.d/S*nginx  scripts it ought to do it.. sigh. it's been long enough I've forgotten details :)
[01:11] <Fieldy> might have been update-rcsomething
[01:11] <Fieldy> sketchy memory here
[01:11] <sarnold> update-rc.d sounds familiar, but maybe that was only for postinst script use. :/
[01:11] <Fieldy> hm
[01:12] <sarnold> I thoght it was like chkconfig .. but I don't see that on my system. heh. :)
[01:13] <Fieldy> update-rc.d nginx disable
[01:13] <Fieldy> insserv: warning: current start runlevel(s) (empty) of script `nginx' overrides LSB defaults (2 3 4 5).
[01:13] <Fieldy> insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `nginx' overrides LSB defaults (0 1 6).
[01:13] <Fieldy> i'll be honest, that means nothing to me ;/
[01:13] <lhorace_> Looking for update-rc.d?
[01:14] <lhorace_> nvm
[01:14] <sarnold> Fieldy: that's fine, just warnings. it shouldn't start now :) hehe
[01:14] <Fieldy> alright i'll reboot it
[01:15] <lhorace_> "stop runlevel(s) (0 1 2 3 4 5 6)"? wha
[01:15] <Fieldy> heh yeah i know
[01:15] <sarnold> lhorace_: that means sysvinit would stop nginx when entering any of the runlevels 0 1 2 3 4 5 6 if it was running in the old runlevel
[01:15] <Fieldy> it's no longer running on boot
[01:15] <Fieldy> so that was it, thanks for the pointer
[01:15] <lhorace_> I know what it means
[01:16] <lhorace_> Did you set that up manually?
[01:16] <lhorace_> Or the script was shipped like that by default
[01:16] <Fieldy> came like that by default
[01:17] <sarnold> debian's policy says daemons should be started by default once they are installed
[01:18] <lhorace_> Well, it's not a bug persay, but whoever wrote the LSB default line... Didn't know what he typed
[01:18] <sarnold> in what way?
[01:19] <lhorace_> It's saying that the services should be stopped on runlevel 0 1 2 3 4 5 and 6
[01:19] <lhorace_> with no default start levels
[01:19] <lhorace_> If a program was obey it, how would the service start ?
[01:20] <sarnold> lhorace_: I think you misread; the LSB defaults come _afterwards_: "insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `nginx' overrides LSB defaults (0 1 6)."
[01:21] <lhorace_> Oh my
[01:21] <lhorace_> I think you misreading me
[01:21] <lhorace_> It says that in the /script/, the current stop levels are 0 1 2 3 4 5 6
[01:22] <lhorace_> That's why inserv complained
[01:22] <sarnold> lhorace_: heh, the current stop levels are set that way because Fieldy ran "update-rc.d nginx disable"
[01:23] <lhorace_> Oh okay, makes sense
[01:23] <lhorace_> I've worked with sysvinit scripts before
[01:23] <lhorace_> In openSUSE, the symlinks would just be remove, that's it.
[01:24] <sarnold> yes, that's likely what it did here, too; either remove them or rename them from Snn.. to snn... I forget the details.
[01:25] <lhorace_> Well, it looks like, it also modified the INIT script
[01:25] <lhorace_> LSB default line
[01:25] <sarnold> if it did that, then the script would never be updated on package upgrades
[01:25] <sarnold> there'd be no reason for it to modify the init script, and doing so would be a serious inconvenience
[01:26] <lhorace_> So, update.rc-d dosn't modify the init script when it disable it ?
[01:26] <sarnold> no, just the symlinks
[01:26] <lhorace_> Okay, so the script is shipped with LSB default stop runlevel as 0 1 2 3 4 5 6
[01:26] <sarnold> no.
[01:27] <lhorace_> innserv is saying that's what nginx init script has
[01:27] <sarnold> lhorace_: http://sources.debian.net/src/nginx/1.6.2-5/debian/nginx-common.nginx.init/
[01:27] <sarnold> # Default-Start:     2 3 4 5
[01:29] <lhorace_> Is that is Ubuntu repo? Because I asked Fieldy and I think he/she said it was shipped like that
[01:29] <sarnold> lhorace_: there's no similar corresponding service for ubuntu's packages, but it's unlikely to be changed between them
[01:29] <sarnold> lhorace_: apt-get source nginx if you want to compare with what your system would install
[01:31] <lhorace_> I use NGINX on arch
[01:31] <lhorace_> Fieldy: What Ubuntu version are you running ?
[01:33] <lhorace_> That of Default line like that ?
[01:33] <lhorace_> s/of/have/
[09:12] <lordievader> Good morning.
[10:26] <haithar> Re all! (Disclaimer: I'm a noob.) Repost: I'm still after bug https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1336742 (14.04.1 LTS has a broken squid) after I've checked out a bit older proxy of us (14.04.0 LTS) and it seems that squid works well there!
[10:26] <haithar> 1) Can this bug be a regression between 14.04.0 (squid3 3.3.8-1ubuntu6) and 14.04.1 (squid3 3.3.8-1ubuntu6.2), affecting everyone upgrading their proxy OS from 12 or from 14.04.0?
[10:27] <haithar> 2) Do you think I can downgrade my squid3 on the newer machine to squid3 3.3.8-1ubuntu6? (Tried apt-install going for that version, seemed to do no actual downgrade.)
[10:27] <haithar> 3) Even if that downgrade succeeded, is my understanding right that that forced version squid3 3.3.8-1ubuntu6 won't be supported and I'd have to wait until that bug gets fixed in 15 and then in 14?
[11:20] <Walex2> haithar: you trade the lack of an optimization with no security updates. Not so sure it is a good trade.
[11:22] <Walex2> haithar: also this seems a very long standing bug. one of the links points at this mailing list message: http://www.squid-cache.org/mail-archive/squid-dev/201207/0100.html where that bug happens with 3.2.0.16
[12:11] <haithar> Walex2: thank you. I'm contemplating what to do; since 14.04.0 LTS is not widely available at VPS companies, and can't really say when the patch gets into vivid and trusty, I'm leaning to roll out 12 LTS for our proxies.
[12:47] <igno818> hello, any feedback using LEMP vs LAMP?
[13:07] <dave65> when are the security updates and reboots going to slow down guys?
[13:07] <dave65> flipping nusiance
[13:09] <dave65> also when is ubuntu going to address the headless server timeout -1 issue
[13:09] <dave65> vent vent :)
[13:10] <dave65> scared to boot my servers these days before checking grub, and reboots are frequent and getting more so
[13:12] <rbasak> dave65: about security update frequency, don't shoot the messenger maybe? Vulnerabilities typically come from upstreams.
[13:12] <rbasak> dave65: for your headless server timeout -1 issue, what's the bug number please?
[13:12] <dave65> yeah, pain tho
[13:12] <rbasak> You don't have to take the security update. You also don't have to reboot :)
[13:13] <dave65> 797544
[13:13] <rbasak> I use unattended-upgrades and don't notice.
[13:14] <dave65> rbasak:  not updating a server with regards to security is foolish
[13:14] <dave65> rbasak:  I saw that update this morning
[13:14] <dave65> not used it before is it new?
[13:15] <dave65> I like to test updates first tho
[13:15] <rbasak> dave65: indeed not doing security updates is foolish :)
[13:15] <rbasak> unattended-upgrades has been around for years
[13:15] <dave65> virtualmin which I use has an auto update feature but it worries me :)
[13:16] <rbasak> There's always a risk. But I can't remember a security update which in hindsight I wish I hadn't applied.
[13:16] <dave65> might wake up one morning and a load of servers broke, sod that
[13:16] <dave65> hast a postfix problem once but that was a longtime ago
[13:16] <rbasak> Occasionally there is a regression (often in the upstream fix) but the vulnerability was always real and the choice is generally only to leave the hole there.
[13:17] <dave65> I know they are complicated vulnerability but I like to keep everything upto date anyway
[13:19] <rbasak> bug 797544 is marked fix released, with no additional bug tasks open.
[13:19] <rbasak> You shouldn't expect any further work on that bug.
[13:19] <dave65> it aint fixed I think
[13:20] <rbasak> Comment #11 might be relevant.
[13:20] <dave65> mind you check grub everytime now out have habit and always change the timeout to 10
[13:20] <dave65> yeah but the comments go on
[13:21] <dave65> I lost confidence
[13:22] <dave65> I have 2 test servers with 12.04 and 14.04 next time I will just boot without looking at grub
[13:23] <dave65> easy fix just booting to rescue mounting and edit and reboot, but is a pain
[13:25] <dave65> setting grub timeout error warning to less than zero, why does it still show?
[13:27] <bekks> Why do you set it to less than zero?
[13:27] <dave65> Ubuntu does it
[13:28] <dave65> on upgrade of kernel
[13:29] <bekks> Which parameter exactly, and where exactly?
[13:32] <dave65> terminal_output gfxterm if [ "${recordfail}" = 1 ] ; then set timeout=-1 grub.cfg
[13:32] <dave65> its the -1
[13:32] <bekks> And why is that line actually concerning you?
[13:33] <dave65> because if you dont change -1 the server can wait for a keystroke on reboot
[13:33] <bekks> That entry is exactly doing what it should - it stops on that boot entry, when booting fails.
[13:34] <dave65> but servers can hang
[13:34] <dave65> well not hang
[13:34] <bekks> Thats intended when using recordfail.
[13:34] <dave65> it just waits for a keystroke
[13:34] <dave65> on a remote headless what do you do?
[13:34] <bekks> I use a remote console.
[13:34] <dave65> no magic wand here
[13:35] <dave65> I have too but a reboot from console and no joy
[13:35] <bekks> You can take a look here, too: http://wiki.hetzner.de/index.php/Grub2_recordfail/en
[13:36] <dave65> ty, will take a look, have a few with hetz
[13:36] <bekks> That article is not dependant on that ISP.
[13:36] <rbasak> utlemming: looking at bug 797544. Shouldn't GRUB_RECORDFAIL_TIMEOUT be some positive number on all servers?
[13:36] <rbasak> (by default)
[13:36] <dave65> but why would a commanede reboot fail?
[13:37] <dave65> commanded
[13:37] <bekks> Because you installed a messed up kernel and you are trying to boot it, e.g.
[13:37] <bekks> Like a selfcompiled kernel with missing hdd controller drivers, etc.
[13:37] <dave65> hrmm
[13:38] <utlemming> rbasak: incidently was later fixed in grub with that exact solution
[13:38]  * utlemming goes looking for the fix
[13:39] <rbasak> utlemming: ah
[13:39] <rbasak> utlemming: I found /etc/default/grub.d/ I looked only in /etc/default/grub before
[13:39] <rbasak> I see 50-cloudimg-settings.cfg that sets it
[13:40] <rbasak> utlemming: but this doesn't come from a package. What about the server ISO install?
[13:40] <dave65> yep
[13:40] <dave65> I thought that
[13:41] <dave65> not an expert here
[13:42] <utlemming> rbasak: i did worked to enable the 50-cloudimg-settings.cfg in the cloud images, but also I had a patch for grub to support it.
[13:42] <utlemming> rbasak: I'm looking for the bug that captures that whole conversation
[13:43] <dave65> yeah sorry I have this habit apparently
[13:43] <dave65> absorbing
[13:49] <rbasak> utlemming: bug 669481 maybe?
[13:50] <utlemming> rbasak: yeah, this look like the one...I didn't think it was done that long ago
[13:51] <rbasak> utlemming: so am I right in thinking that the default is still -1 if installed from a server ISO?
[13:51] <rbasak> If so that seems unacceptable to me.
[13:52] <rbasak> Servers are expected to be headless, and so booting should always be attempted by default IMHO.
[13:52] <utlemming> rbasak: I thought that that conversation was captured in the bug...but there was some concern about the desktop
[13:52] <utlemming> rbasak: I'm +1 on that...it should be a default that is set in the postinst
[13:52] <rbasak> Maybe we need to drop in a file supplied only by the server seed?
[13:52] <rbasak> Have a package called "headless" or something if necessary.
[13:52] <dave65> :)
[13:53] <rbasak> utlemming: do you remember who was concerned about the desktop?
[13:53] <utlemming> rbasak: rbasak: the problem right now is that /etc/default/grub.d only supports a single file
[13:53] <utlemming> rbasak: cjwatson
[13:53] <dave65> more like handless as it needs a finger, at the moment its the middle one :)
[13:54] <rbasak> utlemming: OK I'll ask cjwatson in #ubuntu-devel
[13:57] <rbasak> utlemming: my reading of /usr/sbin/grub-mkconfig suggests that /etc/default/grub.d should work with multiple files. At least in Trusty.
[18:46] <mgagne> hallyn: ping
[18:51] <pmatulis> anyone having mirror problems?
[18:52] <SchrodingersScat> nope
[18:53] <genii> No, but I'm using the local one cor Canada
[18:53] <SchrodingersScat> I'm using US
[20:30] <hallyn> mgagne: not in today
[20:31] <mgagne> hallyn: ok, will follow up on monday. I managed to fix the migration issue from QEMU 1.5 to QEMU 2.0. I'm looking for help to get this fixed upstream.
[20:31] <hallyn> mgagne: awesome, thank you