Re: #32
Cups and other processes expect to be able to assign their configured ports,
But rpcbind / portmap etc. assign ports randomly.
e.g.: http://www.linuxproblem.org/art_13.html
This bug has just hit me, with a deadline to print and no way to reboot the
computer without losing work.
It
** Also affects: rpcbind (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to rpcbind in Ubuntu.
https://bugs.launchpad.net/bugs/304393
Title:
cups: 127.0.0.1:631 - Address already in
For a home system, e.g. mine, where I have 3 or 4 accounts to check
(more when the kids get older, of course), the FD limitiation is not
significant at all, and of course IDLE is far nicer than polling,
especially on servers which limit how often you can connect, but have no
objection to IDLE
A suitable grep | wc pipeline could check and issue a warning, but the
whole point of my patch is that at the moment there is no way to have
more than one account if one of them is using IDLE.
There is no problem with having multiple accounts per daemon (config file) if
no IDLE is in use.
If
for what it's worth, here is my /etc/apparmor.d/local/usr.sbin.named:
/var/bind9/chroot/etc/bind/** r,
/var/bind9/chroot/var/lib/bind/** rw,
/var/bind9/chroot/var/lib/bind/ rw,
/var/bind9/chroot/var/cache/bind/** rw,
/var/bind9/chroot/var/cache/bind/ rw,
On the available evidence that this bug is caused by resolvconf reload squid
too soon, I attach a work-around patch.
It delays any resolvconf reload by 30 seconds if it occurs within 200 seconds
of boot.
Those numbers might well need tuning on other systems, but the patch has solved
the issue
Since applying the patch my server is now getting good at hitting another squid
bug:
https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/988802
Since that one is related to reconfiguring the cache during cache-rebuild, I
don't find that surprising.
I expect that this will be the case for
My trial patch to solve bug #995523 squid3 is killed by
/etc/resolvconf/update-libc.d/squid3 , now lets this bug be triggered instead.
That bug was caused by squid receiving a HUP before the signal handler has been
configured. My patch just moved the HUP handler earlier. Thus a reconfigure as
I've just had a very brief look at the code... I didn't see any reason why the
HUP handling should be delayed (all the handler does is set a variable), so
I've moved it earlier in the code. Patch attached.
Wiser heads than mine might want to check that I've put it in a sane place
(i.e. is
My experience: roughly 30% of boots, squid starts and mid-startup it dies
without logging any errors to its own files.
At least one occurance, /var/log/messages reports kernel: [ 42.178904] init:
squid3 main process (1274) killed by HUP signal
I've seen this premature death at various stages
I've done the following and this seems to have solved the issue for me:
1) added a line in /etc/default/squid
SQUID_ARGS='-D'
(disable startup DNS checks, since my server is not always fully started by
the time squid starts)
I'm fairly sure that squid used to be started with -D by default and
Chuck, you said it should be fixed for Lucid back in April. Unfortunately,
I'm still observing
exactly the same problem, of squid starting then immediatly stopping on boot.
I have resolvconf, along with a local copy of bind9 for my home network.
My /etc/resolvconf/update-libc.d/squid has the
12 matches
Mail list logo
