[Bug 304393] Re: cups: 127.0.0.1:631 - Address already in use.
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 took a lot of debugging before I stumbled upon the article above, and I've been using linux since it came on two floppies. The problem has been noted in redhat, suse, even BSD. I propose a solution: rpcbind should NOT assign random ports, it should assign random *unallocated* ports (i.e. it should make a list of things listed in /etc/services and avoid those ports.) -- 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 use. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 304393] Re: cups: 127.0.0.1:631 - Address already in use.
** 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 use. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/304393/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1021699] Re: fetchmail: IDLE - multiple daemons should be started
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 use. So, personally I'd see removing IDLE as a
backward step. (as far as I can see, none of the servers I connect to
support NOTIFY). NOTIFY would presumably not help across multiple
servers, either.
I really like fetchmail, but it struck me as annoying that the default
initscript would only start the one daemon. I.e. for my use I don't see
the bug as in the binary but in the initscript.
OK, a re-write of the codebase to make it capable of handling multiple
concurrent connections would also solve it (sounds challenging, but I
haven't looked at the source in years) and possibly use far less
resources on a big system. I'm not in a position to fund such a project,
sorry.
I felt my patch to the ubuntu/debian initscript a reasonable work-around
until someone was.
For checking sanity of the relvant config files, how about this extra
bit of shell script?
POLLING=`sed 's/#.*$//;/^\s*[Pp][Oo][Ll][Ll]\s/p;d' ${CONFIG} | wc -l `
IDLE=`sed 's/#.*$//;/^\s*[Ii][Dd][Ll][Ee]/p;d' ${CONFIG} | wc -l`
if test ${POLLING} -gt 1 -a ${IDLE} -gt 0
then
echo WARNING: ${CONFIG} uses the IDLE directive but tries to access ${POLLING}
accounts. Processing will not pass the first account with an IDLE unless there
is a problem with the connection.
fi
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to fetchmail in Ubuntu.
https://bugs.launchpad.net/bugs/1021699
Title:
fetchmail: IDLE - multiple daemons should be started
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1021699/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1021699] Re: fetchmail: IDLE - multiple daemons should be started
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 IDLE is used, then that connection will only terminate on a network error, and other accounts will not be queried more than once (depending on position in the file.) At the moment the sysadmin can 'lock up' their fetchmail daemon by adding the perfectly legal 'idle' annotation to one command. My patch does not stop this, but provides a mechanism to use it safely. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to fetchmail in Ubuntu. https://bugs.launchpad.net/bugs/1021699 Title: fetchmail: IDLE - multiple daemons should be started To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1021699/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 236510] Re: default apparmor setting prevents bind from running under chroot
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,
/var/bind9/chroot/var/run/named/named.pid w,
/var/bind9/chroot/var/run/named/session.key w,
/var/bind9/chroot/dev/random r,
/var/bind9/chroot/dev/log w,
/var/bind9/chroot/dev/null rw,
# support for resolvconf
/{,var/,var/bind9/chroot/}run/named/named.options r,
/var/bind9/chroot/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libgost.so
rm,
No warantee at all, but it works for me (precise).
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to bind9 in Ubuntu.
https://bugs.launchpad.net/bugs/236510
Title:
default apparmor setting prevents bind from running under chroot
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/236510/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 988802] Re: squid3 killed by ABRT signal. assertion failed: disk.cc377: fd = 0
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 for my computer i.e. squid3 now starts properly. ** Patch added: Delay resolvconf reload when immediately after boot https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/988802/+attachment/3197159/+files/squid3-reslovconf_delay.patch -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to squid3 in Ubuntu. https://bugs.launchpad.net/bugs/988802 Title: squid3 killed by ABRT signal. assertion failed: disk.cc377: fd = 0 To manage notifications about this bug go to: https://bugs.launchpad.net/squid/+bug/988802/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 995523] Re: squid3 is killed by /etc/resolvconf/update-libc.d/squid3 in Precise
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 anyone else who hits this bug, -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to squid3 in Ubuntu. https://bugs.launchpad.net/bugs/995523 Title: squid3 is killed by /etc/resolvconf/update-libc.d/squid3 in Precise To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/995523/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 988802] Re: squid3 killed by ABRT signal. assertion failed: disk.cc377: fd = 0
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 soon as the reconfigure checks start being done. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to squid3 in Ubuntu. https://bugs.launchpad.net/bugs/988802 Title: squid3 killed by ABRT signal. assertion failed: disk.cc377: fd = 0 To manage notifications about this bug go to: https://bugs.launchpad.net/squid/+bug/988802/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 995523] Re: squid3 is killed by /etc/resolvconf/update-libc.d/squid3 in Precise
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 there any reason it should be after the setEffectiveUser() call?) ** Patch added: Catch HUP earilier in initialisation https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/995523/+attachment/3178729/+files/squid3.nodie.patch -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to squid3 in Ubuntu. https://bugs.launchpad.net/bugs/995523 Title: squid3 is killed by /etc/resolvconf/update-libc.d/squid3 in Precise To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/995523/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 995523] Re: squid3 is killed by /etc/resolvconf/update-libc.d/squid3 in Precise
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 in the startup e.g. a quick scan of cache.log shows it being killed after: Set Current Directory to /var/spool/squid3 Adding nameserver 192.168.12.1 from /etc/resolv.conf My guess without much testing: there is some kind of race condition/timing issue going on. Squid3 is started by upstart and at roughly the same time /etc/resolvconf/update-libc.d/squid3 is triggered (e.g. by bind9 startup, which was the previous logged event in /var/log/messages) which then sends squid a HUP. Normally a HUP to squid is harmless (reload config), but it seems to be fatal during startup. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to squid3 in Ubuntu. https://bugs.launchpad.net/bugs/995523 Title: squid3 is killed by /etc/resolvconf/update-libc.d/squid3 in Precise To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/995523/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 561750] Re: squid starts and stops immediately (after upgrade from karmic to lucid)
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 I'd see it as a regression that it isn't now. 2) replaced restart squid with reload squid in /etc/resolvconf /update-libc.d/squid. -- squid starts and stops immediately (after upgrade from karmic to lucid) https://bugs.launchpad.net/bugs/561750 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to squid in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 561750] Re: squid starts and stops immediately (after upgrade from karmic to lucid)
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 lines: if status squid | grep start/running /dev/null; then restart squid fi Syslog reveals: Aug 16 11:30:34 foo squid[1868]: Squid Parent: child process 1870 started [...] Aug 16 11:30:38 foo acpid: 1 client rule loaded Aug 16 11:30:39 foo kernel: [ 78.143745] nf_conntrack version 0.5.0 (10981 buckets, 43924 max) [...] Aug 16 11:30:40 foo named[2367]: starting BIND 9.7.0-P1 -u bind Aug 16 11:30:40 foo named[2367]: running [...] Aug 16 11:30:41 foo init: squid main process (1868) killed by TERM signal Aug 16 11:30:41 foo init: squid main process (2455) terminated with status 1 The relevant portion of cache.log ends up like: 2010/08/16 11:30:39| 0 Objects expired. 2010/08/16 11:30:39| 0 Objects cancelled. 2010/08/16 11:30:39| 0 Duplicate URLs purged. 2010/08/16 11:30:39| 0 Swapfile clashes avoided. 2010/08/16 11:30:39| Took 4.5 seconds (18266.9 objects/sec). 2010/08/16 11:30:39| Beginning Validation Procedure 2010/08/16 11:30:39| Completed Validation Procedure 2010/08/16 11:30:39| Validated 82655 Entries 2010/08/16 11:30:39| store_swap_size = 2793828k 2010/08/16 11:30:39| storeLateRelease: released 0 objects 2010/08/16 11:30:41| Preparing for shutdown after 0 requests 2010/08/16 11:30:41| Waiting 3 seconds for active connections to finish 2010/08/16 11:30:41| FD 16 Closing HTTP connection 2010/08/16 11:30:41| Shutting down... -- squid starts and stops immediately (after upgrade from karmic to lucid) https://bugs.launchpad.net/bugs/561750 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to squid in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
