[users@httpd] Custom 404 Pages not being GZIPed in Apache 2.4
Hi,
I’m pretty sure this problem isnt to do with PHP, and I’ve discussed it a
little on stackoverflow.com with another user, and come to the conclusion there
could be a problem with Apache, but I would like an opinion.
I've written myself a custom 404 page via PHP, but I've noticed that the page
doesn't get GZIPed when served, when I return the status code 404. Even though
I'm sure it should be.
(I'm redirecting all requests to index.php, then parsing the URI, and issuing
404's when needed through header(), so I'm not using ErrorDocument, although
I've tested with ErrorDocument in .htaccess and the same problem happens.)
I'm using PHP5.5.9/Apache2.4.7 On Ubuntu (Latest for Ubuntu), and Apache is
configured to use mod_deflate:
deflate.load: LoadModule deflate_module /usr/lib/apache2/modules/mod_deflate.so
deflate.conf: AddOutputFilterByType DEFLATE text/html text/plain text/xml
This is a simple test script I've got:
?php
header(HTTP/1.1 404 Not found);
print WILL THIS BE GZIPED! .str_repeat('X',500);
?
If you comment out the header 404 (so that it gets a normal 200 response) it
returns the page compressed fine.
I've also tried with the new http_response_code(404); command for PHP =5.4,
but that doesn't help.
I've tested in Chrome/Developer Tools and also directly with Curl to test if it
gets compressed, and it doesn't. There is no Response Header 'Content-Encoding:
gzip', so I'm guessing its Apache that's not compressing it.
Its not a major problem for me, obviously, as I hope to not get too many people
trying to link to pages that generate a 404 error, but it would be good if it
did compress correctly.
I can work around it, by making PHP compress it manually for my 404 page, but I
would like to know if you think this could be an Apache problem that needs to
be looked at and/or fixed.
(Note, you have to make sure the response is 256 bytes to get Apache to
compress, so that's what the str_repeat() bit is)
Thanks,
Rob Donovan.
Re: [Nut-upsuser] Slaves under Squeeze
Thanks - that brought me more progress than I've seen all day :) Changing to the following on the server : upsd.conf: LISTEN 0.0.0.0 with no other changes from what I posted on the previous page got both the server and slave nuts starting up ok. For the record ifconfig on the server returns the following: eth0Link encap:Ethernet HWaddr 00:26:b9:8d:18:b5 inet addr:192.168.1.102 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::226:b9ff:fe8d:18b5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7078694 errors:0 dropped:0 overruns:0 frame:0 TX packets:7756421 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:973255191 (928.1 MiB) TX bytes:1064820280 (1015.4 MiB) Interrupt:16 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:12697367 errors:0 dropped:0 overruns:0 frame:0 TX packets:12697367 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1351490194 (1.2 GiB) TX bytes:1351490194 (1.2 GiB) Instead of LISTENing to 0.0.0.0 I tried LISTENing to 192.168.1.102 or 00:26:b9:8d:18:b5 or fe80::226:b9ff:fe8d:18b5/64 but none worked when running /etc/init.d/nut start on the server (all gave immediate Communications with UPS cp1500avr1@localhost lost errors). ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Slaves under Squeeze
Changing to the following on the server : upsd.conf: LISTEN 127.0.0.1 LISTEN 192.168.1.102 also works :) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Bug#639539: top problem
has happened again : top - 22:49:30 up 7 days, 7:38, 3 users, load average: 1.19, 0.88, 0.80 Tasks: 212 total, 3 running, 209 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 1.5%sy, 92.7%ni, 5.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 16461424k total, 11328664k used, 5132760k free, 484068k buffers Swap: 35150104k total,0k used, 35150104k free, 8270712k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 5178 user 20 0 19180 1436 1004 R0 0.0 0:00.19 top 3431 user 20 0 79296 1904 944 S0 0.0 1:53.73 sshd 3432 user 20 0 21720 4592 1620 S0 0.0 0:00.17 bash 3474 user 20 0 186m 26m 12m S0 0.2 5:26.99 emacs 3478 user 20 0 26104 928 624 S0 0.0 0:00.00 dbus-launch 3479 user 20 0 23260 824 580 S0 0.0 0:00.00 dbus-daemon 3481 user 20 0 46008 5548 2316 S0 0.0 0:00.44 gconfd-2 3482 user 39 19 1844m 1.6g 932 S0 10.1 2590446h my_prog.x 3488 user 20 0 79316 2044 960 S0 0.0 0:02.31 sshd 3489 user 20 0 21764 4640 1620 S0 0.0 0:00.60 bash 16039 user 20 0 78988 1724 956 S0 0.0 0:00.12 sshd 16216 user 20 0 21720 4612 1632 S0 0.0 0:00.36 bash This is just processes owned by me (userid changed to user). The program that is eating all the CPU is my_prog.x, which is running nice 19. It's been running for about 67 hours now, not 2590446 hours. The 92% nice CPU usage (up the top) is credible, while 0% is not. 1844m memory usage is correct. The program is logging to stdout at the usual rate. Load average should be about 7.8. CPU usage for my_prog should be about 760% +. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639539: Load average bug
I can confirm that I'm seeing this bug too after an upgrade to the standard Debian Squeeze distribution from Lenny (new kernel is 2.6.32-5-amd64). It shows up in top and, of course, xload. In my case the load average comes in at about 0.3 for a nice-19 job eating 784% of my 8-cpu processor (max being 800%). Under Lenny xload displayed similar jobs as (almost) 8 bars. Now it's much less than 1 bar. xload is therefore effectively broken. Rob Donovan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639539: ps
This may be related : I run jobs that eat nearly 800% of my 800% available CPU that take about 10 days to complete, and I run them at nice 19. Under Lenny such jobs always showed up at the top of top reporting 700% + CPU consumption, as you'd expect. I upgraded to Squeeze on 19 August 2011, and since then such jobs have still shown up at the top of top... with one exception. On one occasion the job was still running (I could see it logging to stdout at the usual speed in the window in which it was running) but it wasn't at the top of top. In fact, only by restricting top to show processes owned by me (u userid) could I see it at all, and it was then displayed at the bottom of my processes. Memory was displayed OK, but CPU consumption... was displayed as zero I think. I can't remember what the CPU line at the top of the screen was displaying. If it happens again I'll make notes. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Bug 606999] Re: buffer length error in syslog
Me neither. I gave up on Ubuntu eventually (due to another bug) and installed Debian Lenny best /rob flavin wrote: I got the same, and I found this: http://mjg59.livejournal.com/126270.html but I still don't know how to fix it -- buffer length error in syslog https://bugs.launchpad.net/bugs/606999 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Nut-upsuser] NUT with Cyber Power 700 AVR
1) syslog errors every 20+ minutes or so like : Aug 7 10:21:03 ben
usbhid-ups[3321]: libusb_get_string: error sending control message:
Broken pipe
Not a cause of concern. It is a way of telling that the UPS is
currently not able to handle a command. Most likely this is due to the
UPS doing some internal housekeeping functions and the little
microcontroller inside is not able to handle a command. We will
probably suppress this in future NUT versions, as it is a common cause
of false alarms.
2) syslog errors on a similar timescale like : Aug 7 08:17:40 ben
kernel: [40170.402789] usb 2-1.2: usbfs: USBDEVFS_CONTROL failed cmd
usbhid-ups rqt 161 rq 1 len 8 ret -110
Same here. The kernel is informing you that the UPS didn't respond to
a command (110 = ETIMEDOUT). The cause is most likely the same as the
above and not a cause of concern either. Unlike the above message,
there is nothing we can do about this as it is logged by the kernel.
Good to know. Thanks for the reply.
3) The machine spontaneously shutdown this morning due to a low
battery condition. However, 80 minutes later when I noticed the UPS
battery was at 100%. I don't think it can charge that fast, so I
think this must have been a communication error.
I'm not so sure about that. Don't overestimate the accuracy of the
battery charge gauge on the UPS. It could be that it is just voltage
based, which means that it will indicate full charge long before the
battery is actually full. It could also mean that the battery is bad.
This may cause nearly instant shutdowns when the mains fails (when the
battery is under load) while it looks like the battery is (almost)
full with the mains present (and the battery is not under load).
Running a battery test usually reveals what is going in.
Best regards, Arjen
Fair points, but I think the battery is good. I've run several
on-battery shutdowns lasting 90s+ by flipping the breaker (using
upssched to initiate shutdown after 60s) and that works fine. I ran a
longer test for 2 or 3 minutes once and watched the UPS displayed
estimated run time count down from 76 minutes as you'd expect it to.
The UPS is brand new. Also, I suspect there was no power cut - in the
past I've had to reset my stove clock after a power cut, and I don't
recall having to do that this time. I have my system set up to shutdown
after 5 mins on battery, rather than wait for a lowbatt condition, so I
doubt the low batt could have been reached due to a power cut unless
perhaps it was a night of successive 4 minute power cuts or, given the
stove, 4 minute low-voltage conditions. I guess we'll never know for
sure... in any case, this was enough for me to abandon 2.4.3 and try
Cyberpower's own offering, which suffered from curious delays itself
which I wasn't happy with given that the eventual power-off is timer
based rather than signal based as in nut, and thence back to nut 2.2.2...
So, I went back to nut 2.2.2 under Debian Lenny with both MAXAGE and
DEADTIME set to 150s. This worked OK for 10 days, with the odd type (2)
error from above, and the odd stale data error [aside : it is my
understanding that data must now be stale for 150s for upsmon to log a
stale data warning to syslog, since upsd doesn't pass on the stale data
condition until MAXAGE is reached. So for 30 lots of 5s polls the data
is stale... then it shows up in syslog, and, and this is what's weird,
in almost every case it resolves itself 2s later just like it did
when MAXAGE was 15s.] After 10 days it went into a stale data condition
that continued all night until I stopped it by restarting nut in the
morning.
Since restarting nut seemed to fix the problem I decided to make
upssched restart nut on a NOCOMM condition. I'll briefly describe how I
did that here in case others are interested:
I set
NOTIFYFLAG NOCOMM SYSLOG+WALL+EXEC
in upsmon.conf in the usual way with
NOTIFYCMD /sbin/upssched
set to call upssched. In upssched.conf I set
CMDSCRIPT /sbin/upsschedcmd
and
AT NOCOMM * EXECUTE restart
/sbin/upsschedcmd is my command script, the relevant portion of which is :
#!/bin/bash
# This script is called by upssched on a UPS event.
# This script is designed to be run by user nut.
case $1 in
restart)
/sbin/upsrestart.x
;;
esac
upsrestart.x is the following C code, compiled using the gcc line in the
comment, and chowned/chmoded to have the ownership/permissions in the
2nd comment :
#include stdio.h
#include unistd.h
/*
This program is designed to restart nut.
The binary file permissions should be -rwsr-xr-- root:nut
gcc -g -Wall -o upsrestart.x upsrestart.c
*/
int main (int argc, char *argv[])
{
char *arg[] = { /etc/init.d/nut, restart, (char *) NULL };
char *env[] = { USER=root, PATH=/usr/sbin:/usr/bin:/sbin:/bin,
HOME=/root, (char *) NULL };
execve (arg[0], arg, env);
// if execve() returns there has been an error
fprintf(stderr,upsrestart.c
Bug#511463: [ddd] ddd: Symbol `_XmStrings' has different size in shared object, consider re-linking
I think I should add that the more serious consequences of this bug (machine hanging, etc) were seen when running ddd on my 64bit Linux server via a ssh session from, and with the display exported to, a 32bit Windows XP machine running the Cygwin X server. I haven't tried running an X server directly on the Linux box, but I did just try NX NoMachine in place of the Cygwin X server, which I think essentially fakes an X server on the Linux box, and I found that the newer (package supplied) Xm library does not cause the hanging problem (though clicking on the ddd window did once disconnect my NX session). If console X sessions are similarly tolerant of this bug that might explain why the more serious consequences I reported haven't been reported before. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511463: [ddd] ddd: Symbol `_XmStrings' has different size in shared object, consider re-linking
I have/had this bug running ddd under a new installation of Debian Lenny 5.05 amd64. It is now solved. In my case this bug didn't only cause the error message, but also caused ddd to become sluggish or unresponsive, consume large amounts of CPU or hang when accessing menus. For example, clicking on Edit-Preferences and then changing tabs from General to Source would take many seconds, with top showing 10-20% CPU. Changing tabs to Data would sometimes complete and sometimes just hang, with CPU going to 40%. Clicking OK would then hang completely with CPU going to 100%. I would then have to kill ddd. This made ddd close to unusable. The problem can be fixed by downgrading your version of the lesstif2 library /usr/lib/libXm.so.2.0.1 Unfortunately at the time of writing the oldstable Etch packages don't seem to be online. It looks like they've been removed from http://packages.debian.org/oldstable/ and don't yet show up in http://archive.debian.net/ I don't know if the Etch package would have been old enough anyway. Going back further there is Sarge, available from http://archive.debian.net/ I used the Xm lib from the lesstif2 package version 0.93.94-11.4 and this solves the problem. Note that the library is still called libXm.so.2.0.1 but it's clearly different, since it works. I've seen ddd fail on 4 successive invocations when using the original library, then succeed on 8 invocations using the new Xm library, changing tabs multiple times and opening and closing windows. I gave it this testing because the very first time I ran with the new library it worked for a moment and then failed. I can't explain this and can't reproduce it. My best (admittedly feeble) guess is that something was cached somewhere. Anyway, with the new lib in place I now can't get it to fail again. Yet :) On many architectures you can probably download the Sarge package directly from the website, unpack it with dpkg -x, and copy the libXm to /usr/lib/ and be done. Unfortunately Sarge packages aren't available for the amd64 architecture, so to get this to work I had to compile the package from source. Below therefore is a quick how-to for amd64 users who want to fix this problem on their system. Thanks to the folks on this thread http://www.mail-archive.com/coo...@linux-mandrake.com/msg129902.html back in 2003 for providing the solution to this problem. /rob - amd64 how-to under Debian Lenny 1) the source can be downloaded from the Debian Sarge package page : http://archive.debian.net/sarge/lesstif2 the three links on the right hand side under Download Source Package. 2) Packages you need which are/are used as generic code-building packages: sudo aptitude install fakeroot sudo aptitude install autoconf sudo aptitude install bison sudo aptitude install debhelper sudo aptitude install flex sudo aptitude install libtool autoconf gets automake which is automake1.10 You actually need automake1.6 but that isn't available from the Lenny Repositories. We'll deal with this below. Packages you need which are development and specific to this build: sudo aptitude install libice-dev libsm-dev libx11-dev libxext-dev libxp-dev libxt-dev libxrender-dev libxft-dev libfontconfig1-dev libfreetype6-dev 3) Following http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html In the directory containing your source tar files: dpkg-source -x lesstif1-1_0.93.94-11.4.dsc 4) You have to edit the lesstif1-1-0.93.94/debian/rules file to remove the 1.6 references to aclocal and automake. Make sure you end up with calls to aclocal and automake just like that. 5) Run this. It takes a few minutes. cd lesstif1-1-0.93.94 dpkg-buildpackage -rfakeroot -b -d 6) It falls over eventually complaining about a man page, but not before it compiles the libs. They are available from debian/lesstif2/usr/lib/ You might like to archive your original /usr/lib library before you sudo cp libXm.so.2.0.1 /usr/lib/libXm.so.2.0.1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Nut-upsuser] NUT with Cyber Power 700 AVR
It turns out Cyberpower's own Linux software can't talk to the cp1500avr over serial cable either. So the nut serial driver probably isn't the problem. I've already shown the UPS and cable are OK by talking to Windows. It seems unlikely that both Thomas and I and all the other posts you can find on this have defective computer hardware. I saw someone suggest in a 2 year old post on this that it might be caused by problems with the Linux kernel serial driver. I'm not even entirely sure what that means, but since both Thomas and I are running Debian Lenny, it sounds pretty plausible to me! ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] NUT with Cyber Power 700 AVR
I applied the aforementioned patch to 2.4.3 and recompiled. Since the patch only affects newmge-shut and usbhid-ups I just copied the latter into /lib/nut/ This works, insomuchas all the nut programs start up and run. However, there are 3 remaining problems: 1) syslog errors every 20+ minutes or so like : Aug 7 10:21:03 ben usbhid-ups[3321]: libusb_get_string: error sending control message: Broken pipe 2) syslog errors on a similar timescale like : Aug 7 08:17:40 ben kernel: [40170.402789] usb 2-1.2: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 8 ret -110 3) The machine spontaneously shutdown this morning due to a low battery condition. However, 80 minutes later when I noticed the UPS battery was at 100%. I don't think it can charge that fast, so I think this must have been a communication error. I've now tried two versions of NUT, a patch, and both serial and usb communications. Only one mode (2.2.2 usb) works in any meaningful sense, but even that suffered from minute+ periods of stale data in the few days I ran it. I wanted to use NUT so I could hang possible future machines off one big ups, but for the present I give up. Hopefully the portmon log I posted will help. I note that both Thomas and I are running Debian Lenny and using recently purchased Cyberpower UPSs. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] NUT with Cyber Power 700 AVR
hi there, I ran portmon. Read on... I'm running nut 2.2.2-6.5 under Debian Lenny 5.05 on a Dell T110 PowerEdge Server hooked to a Cyberpower 1500 AVR LCD. All new hardware purchased in the last 3 months. I tried to attach via usb at first, but was getting stale data errors in syslog sometimes lasting a minute or more, plus USBDEVFS_CONTROL errors too, so I decided to try a serial cable instead. I get exactly the same errors Thomas was getting: /sbin/upsdrvctl start cp1500avr1 Network UPS Tools - UPS driver controller 2.2.2 Network UPS Tools - CyberPower driver 1.00 (2.2.2) Giving up on hardware detection after 3 tries Unable to get initial hardware info string Driver failed to start (exit status=1) /lib/nut/cyberpower -DDD -a cp1500avr1 Network UPS Tools - CyberPower driver 1.00 (2.2.2) debug level is '7' Giving up on hardware detection after 3 tries Unable to get initial hardware info string Changing to driver = powerpanel in ups.conf : /lib/nut/powerpanel -DDD -a cp1500avr1 Network UPS Tools - CyberPower text/binary protocol UPS driver 0.23 (2.2.2) Warning: This is an experimental driver. Some features may not function correctly. debug level is '7' Trying binary protocol... read: timed out read: timed out read: timed out Trying text protocol... send: (2 bytes) = 0d 0d read: timed out send: (3 bytes) = 50 34 0d read: timed out read: timed out send: (3 bytes) = 50 34 0d read: timed out read: timed out send: (3 bytes) = 50 34 0d read: timed out read: timed out CyberPower UPS not found on /dev/ttyS0 ls -l /dev/ttyS* crw-rw 1 root nut 4, 64 2010-08-06 09:18 /dev/ttyS0 crw--- 1 root root4, 65 2010-08-05 15:20 /dev/ttyS1 crw-rw 1 root dialout 4, 66 2010-08-05 15:19 /dev/ttyS2 crw-rw 1 root dialout 4, 67 2010-08-05 15:19 /dev/ttyS3 After running the cyberpower driver : stty /dev/ttyS0 speed 1200 baud; line = 0; min = 1; time = 0; -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke There are many ways to screw up serial port assignment on this machine, but I think I have it correct in the BIOS. I have : Serial Communications = On with Console Redirection via COM2 Console Redirection After Boot = Enabled External Serial Connector = Serial Device 1 Console Redirection Failsafe BAUD Rate = 115200 Serial Address Select = Serial Device1=COM1, Serial Device2=COM2 That is, COM2/Serial Device 2 are used for Serial-over-Lan console redirection, which works fine on ttyS1. There is only one physical connector on the back of the box, which I'm specifying is connected to Serial Device 1 = COM1 which I have to presume is ttyS0. I should note that the External Serial Connector assignment tends to drift. The documentation says that you can toggle between Serial Device 1, Serial Device 2 and Remote Access Device using Terminal Escape Sequences though I can't find any documentation on what those might be. They seem to be happening though. If I set External Serial Connector = Serial Device 1 in the BIOS and boot, then check it (using Dell Open Manage) it's still set to 1. But after another boot or two it's set to 2. Setting External Connector to Serial Device 1, power cycling the UPS (it is not powering my machine at the moment), issuing the above commands, and checking the connector is still assigned to Serial Device 1 gives the results above. It is interesting to note, however, that I got the same results once and then found it was set to 2... The External Serial Connector drift is probably not the cause of this problem though. If you Google Giving up on hardware detection after 3 tries you can find several people reporting this problem back to at least 2007. I think all of them had Cyberpower UPSs. I don't recall any of them mentioning Dells, or External Serial Connector settings. Moreover, if I boot with External Serial Connector = Serial Device 2 then the UPS will beep and keep flipping to battery during and after the boot, presumably because it is interpreting SOL traffic as instructions. If I set External Serial Connector = Serial Device 1 before the boot this doesn't happen. The boot stalls at the nut startup, presumably waiting for timeouts, which then fails. So there is a difference when the UPS is connected to ttyS0, but it still doesn't work. Anyway, since I have an old Windows PC with a serial connector, I decided to run portmon. For future reference, I found this worked: Disable any existing ups services/startups in msconfig (I had old APC stuff running...) Install portmon Install software under test (cyberpower in my case) Disable com1 in device manager reboot enable com 1 run portman connect local monitor com1 only connect ups by serial cable power on ups restart cyberpower's service in service management - messages fill portman save messages. I had a lot of trouble with stuff grabbing com1 before portmon, which then couldn't monitor it. I even got into a lovely state where
Re: [Nut-upsuser] NUT with Cyber Power 700 AVR
My previous post was a follow-up to this discussion in February: http://lists.alioth.debian.org/pipermail/nut-upsuser/2010-February/005924.html ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Bug#63995: obfuscation
The solution (namely, turning @ into !-- blah --#64!-- blah -- is a needless obfuscation that isn't going to actually net us anything. This sounds like a plausible argument, but it hasn't been my recent experience. I submitted my 1st Debian bug on 7/29/10 at 3.51pm and got my first spam email on the address used on 7/30/10 at 5.20pm, less than 26 hours later. Compare that to the Cygwin mailing list where I submitted a bug on 4/27/10 and where the address used has, as far as I can remember, yet to receive any spam. Cygwin uses a simple @ - at and . - dot obfuscation method. I think it very likely that Debian is losing bug reports because of this issue. I nearly balked myself, and I can assure you that I only went ahead because the Yahoo Plus mail account (that I pay for) lets me generate disposable addresses. Not everyone has this capability. Given that spam filters are not perfect I think many people are still inclined not to knowingly invite spam by posting non-disposable addresses on the web. While I agree that my recent experience is a sample of two, and so not exactly solid scientific evidence, I do think some sort of simple, yet novel, obfuscation method would be likely to help. Since it is now attracting spam I'll now disable the disposable address used for my Debian bug report and this comment. I guess that means that I will now become uncontactable via my bug report... which ironically is, I gather, exactly what you are trying to avoid by posting email addresses in the first place. My Cygwin address, meanwhile, is still active... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590895: sysvinit: shutdown -hP sets INIT_HALT to POWERDOWN not POWEROFF
Package: sysvinit Version: 2.86.ds1-61 Severity: normal The shutdown man page says that the -P option will set the INIT_HALT variable to POWEROFF. However, echo statements placed at the top of do_stop() in /etc/init.d/halt reveal that this variable is set to POWERDOWN. Assuming nothing modified the value of INIT_HALT inbetween, this suggests that either shutdown or its man page should be fixed. Further down in /etc/init.d/halt the following script if [ $INIT_HALT = POWEROFF ] [ -x /etc/init.d/ups-monitor ] then /etc/init.d/ups-monitor poweroff fi tests for POWEROFF only. So, if you configured your ups monitoring software to shutdown on a power outage with shutdown -hP your UPS will never power off. It seems to me that either shutdown should be fixed to set INIT_HALT to POWEROFF, or this script should test for both, or the use of -hP as a mechanism to deliberately leave your UPS on after a UPS induced shutdown should be documented somewhere. -- System Information: Debian Release: 5.0.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages sysvinit depends on: ii initscripts 2.86.ds1-61 Scripts for initializing and shutt ii libc6 2.7-18lenny4 GNU C Library: Shared libraries ii libselinux1 2.0.65-5 SELinux shared libraries ii libsepol1 2.0.30-2 Security Enhanced Linux policy lib ii sysv-rc 2.86.ds1-61 System-V-like runlevel change mech ii sysvinit-utils 2.86.ds1-61 System-V-like utilities sysvinit recommends no packages. sysvinit suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[Bug 606996] Re: ctrl alt F1 does nothing
Turns out this is not an Ubuntu bug - sorry. On this keyboard the last regular key on the right hand end of the function key row is F Lock. It has to be on (the indicator light nearest you) for the function keys to work. Except with the BIOS, apparently... Thanks for the post kurt. -- ctrl alt F1 does nothing https://bugs.launchpad.net/bugs/606996 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 606989] [NEW] /var/run /var/lock mounts prevent umount of /var at shutdown
Public bug reported: Title says it all really. Leads to error messages like umount2: Device or resource busy. umount: /dev/sda8 busy - remounted read-only in the shutdown console messages. Since /var is remounted read-only the technical consequences of this bug are nil, I think. However, the user consequences are non-nil: the error messages serve as a red-herring for anyone troubleshooting their system. I wasted time on it because I thought unsuccessful umounting of /var might be the cause of fscks on boot, this all following a power failure. I now know better, but I wasted a couple of days on it (fuser lsof come up blank). Ubuntu 10.04 LTS 64-bit. ** Affects: ubuntu Importance: Undecided Status: New -- /var/run /var/lock mounts prevent umount of /var at shutdown https://bugs.launchpad.net/bugs/606989 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 606996] [NEW] ctrl alt F1 does nothing
Public bug reported: Ctrl-Alt-F1 does nothing on either of my machines : Dell Dimension 2400 (old cheap desktop) and Dell T110 Poweredge (new expensive server). In both cases I'm using a Microsoft Natural Ergonomic Keyboard 4000 v1.0. I chose the nearest thing on setup, Microsoft Natural I think, and have notes I made on setup saying Microsoft Natural/USA/USA/NoAltGrKey/No Compose Key/VGA/16/default/ F keys work fine with the BIOS for entering boot/setup menus etc. ** Affects: ubuntu Importance: Undecided Status: New -- ctrl alt F1 does nothing https://bugs.launchpad.net/bugs/606996 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 606996] Re: ctrl alt F1 does nothing
woops : this is Ubuntu 10.04 LTS 32 bit and 64 bit. -- ctrl alt F1 does nothing https://bugs.launchpad.net/bugs/606996 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 606999] [NEW] buffer length error in syslog
Public bug reported: Binary package hint: acpi This error occurs in /var/log/syslog on boot. I have no idea if it has any consequences. System is Dell T110 Poweredge running Ubuntu 10.04 LTS 64-bit. Jul 16 10:57:42 ben kernel: [4.352252] ACPI Error: SMBus or IPMI write requires Buffer of length 42, found length 20 (20090903/exfield-286) Jul 16 10:57:42 ben kernel: [4.352258] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PMI0._GHL] (Node 88043fc2bde0), AE_AML_BUFFER_LIMIT Jul 16 10:57:42 ben kernel: [4.352276] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PMI0._PMC] (Node 88043fc2bd60), AE_AML_BUFFER_LIMIT Jul 16 10:57:42 ben kernel: [4.352291] ACPI Exception: AE_AML_BUFFER_LIMIT, Evaluating _PMC (20090903/power_meter-772) ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: acpi (not installed) ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2 Uname: Linux 2.6.32-22-generic x86_64 Architecture: amd64 Date: Sun Jul 18 14:14:31 2010 InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100427.1) ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: acpi ** Affects: acpi (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug lucid -- buffer length error in syslog https://bugs.launchpad.net/bugs/606999 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 605687] Re: mountall does everything twice
I spent another half day or so on this. I didn't really get anywhere but I think the evidence is that neither the mountall.conf main script nor mountall itself actually restart (the script doesn't echo and the 2nd set of fscks don't show the parse_filesystems comments of the first, which are generated early in mountall.c's main() even before daemonisation). So, my best guess is that for some reason mountall is losing its state information and then either a timer timing out or a signal is sending it back to the main loop in this amnesic state. I don't know why it doesn't exit, but suspect it may be hanging either due to problems communicating with a serial console or perhaps on that last line call to ply_boot_client_flush at a time when plymouth may already be dead (I can't see where ply_boot_client would be set to NULL in mountall.c, though I admit I haven't searched all the plymouth includes, but if this theory is correct I can't figure out what restarts plymouth for the 2nd set of fscks). Other mysteries : why does it work the 2nd time around, and why does it work when a large filesystem (my /var is 6GB) needs checking. I don't know. Most concerning is that I can't find anything that seems to umount the disks before that 2nd set of fscks kicks in. If so, this means that the 2nd set of fscks is being run on mounted filesystems. I gather this can be dangerous. I'm sure you're aware of this, but I'll point out that if you put -M in your fsck calls that would make things safer - you'd no longer be relying solely on your own internal book-keeping for running fsck. Maybe this would have downsides, I'm not sure. It's just a suggestion. I could spend more time on this but I won't. In fact I've made the tactical decision to move to Debian stable branch Lenny as of tomorrow. Goodbye and good luck! -- mountall does everything twice https://bugs.launchpad.net/bugs/605687 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 605687] Re: mountall does everything twice
1) I added 4 echo statements to each script in mountall.conf and can now say with no doubt that the main script runs once, and the post-stop script runs twice. I don't know how this can happen, but it does. 2) I added echo statements to both scripts in mountall-shell.conf too, also changing console owner to console output and commented out the su login. None of these were echoed - this is not running. (It was the only mountall restart I could find, so I was suspicious - I figured maybe the console grab failed and it skipped straight to the post-stop script. Anyway, it isn't happening). 3) My hunch was that maybe mountall or plymouth has trouble with a serial console. So, I carted my monitor, keyboard and mouse into the server room, and edited my kernel line on boot from quiet console=tty0 console=ttyS1,115200n8 to quiet console=ttyS1,115200n8 console=tty0 I also tried no console terms at all. The documentation I've read said that only the last console term is the one that is tied to /dev/console. I compared the boot messages on tty0 (captured by video camera) to those in /var/log/boot.log to those on serial console if applicable. This test was somewhat inconclusive. The serial console is now missing so many boot messages it's difficult to conclude anything from it. The tty0 console suffers a blank screen a fraction of a second into the boot, in which there probably is not time for a 2nd set of fscks to run. It then hung, in both cases, at the start of the dsm_sa_datamgr32d before going directly to pretty gnome screens. The hang was long enough that there might be time for it to run a 2nd set of fscks - maybe not - hard to say. Given that this is where it sometime starts the 2nd set over serial console, I don't think I can conclude much. /var/log/boot.log only contains the 2nd page of tty0 messages, up to the hang point. 4) I removed monitor, keyboard mouse and booted again over serial console using my unedited kernel line and it worked Only one set of fscks. I've attached boot_worked to this post. I figure there were two unusual things about this boot: A) the last shutdown didn't have a serial console connected. B) this boot decided to force a test on /var, because it's count was up. I figure if it CAN work on serial console, that's a big clue. Though maybe that's only if it doesn't try to interact with it. I think this result also suggests timing is an issue. Note also the Starting dsm_sa_datamgr32d: Already started * lines in the boot log. At one point I thought this meant two /etc/init.d/rc jobs were competing. I think that may still be possible (with the 2nd doing nothing because it's going to the same runlevel as the first), but this message clearly proves nothing since it gets printed when mountall works. 5) Odd things happening to console messages at the dsm_sa_datamgr32d jobs is something I get on shutdown too. I think it may be a plymouth timeout issue. I'll post a separate bug report for that. Note that I don't think that's the cause of the double fsck problem : often that occurs and is done with before the boot ever gets to dsm_sa_datamgr32d. I think I'm giving up on this bug now. Over to you guys. ** Attachment added: boot_worked http://launchpadlibrarian.net/52048176/boot_worked -- mountall does everything twice https://bugs.launchpad.net/bugs/605687 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 606512] [NEW] plymouth causes staircase right-shifting on serial console
Public bug reported: Binary package hint: plymouth I run Ubuntu 10.04 64-bit using a serial over lan (SOL) console. On shutdown I find my console messages print normally at first until I get to Stopping dsm_sa_eventmgr32d: * Stopping dsm_sa_datamgr32d: * Shutting down DSM SA Connection Service: * whereupon the text right-shifts with each successive line as if the terminal received a line feed but not a carriage return producing what I think is known as the staircase effect. On some terminals this causes the shutdown messages to right shift right off the screen, becoming unreadable. Using an xterm to run the SOL and setting for auto wrap- around enables the messages to be read, even if they are all over the place. I know this is a Plymouth bug because if I change /etc/init/plymouth.conf to read start on (starting mountall or (runlevel [16] and (stopped gdm or stopped kdm or stopped xdm or stopped lxdm))) instead of the default [016] then my shutdowns (runlevel 0) work perfectly, with the console messages one below the other. On boot similar messages are printed, which format fine... unless I boot without a serial console in the kernel line in which case I find that both my tty0 console messages and /var/log/boot.log stop at dsm_sa_datamgr32d dsm_sa_* are jobs associated with SARA's port of Dell's Open Manage Server Administrator. I dug a little deeper and found that the bulk of these messages (the text) is produced by echo -n statements in the associated /etc/init.d/ scripts. The * comes from a log_success_msg call to /etc/lsb- base-logging.sh which is sourced at the end of /lib/lsb/init-functions which is sourced in Dell's script. All this does is echo * $@ which looks pretty innocent. My guess is that what may be important here is that maybe a full second can elapse between the echo of the main part of the message and the echo of the *. Does Plymouth implement some sort of timeout after which it decides console messages are over? If so, then it think it may be set too short. Is there a conf file where this can be changed? If not, or in the meantime, is there any negative consequence to not running Plymouth at shutdown? I don't have or want splash screens. Does it do anything else at shutdown? Thanks ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: plymouth 0.8.2-2ubuntu2 ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2 Uname: Linux 2.6.32-22-generic x86_64 Architecture: amd64 Date: Fri Jul 16 15:04:43 2010 DefaultPlymouth: /lib/plymouth/themes/ubuntu-logo/ubuntu-logo.plymouth InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100427.1) Lsusb: Bus 002 Device 003: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS Bus 002 Device 002: ID 8087:0020 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0020 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. PowerEdge T110 ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.32-22-generic root=UUID=b0f54546-a7ed-4e35-86c0-3583021d00bc ro quiet console=tty0 console=ttyS1,115200n8 ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash ProcFB: 0 VGA16 VGA SourcePackage: plymouth TextPlymouth: /lib/plymouth/themes/ubuntu-text/ubuntu-text.plymouth dmi.bios.date: 01/28/2010 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.2.1 dmi.board.name: 0X744K dmi.board.vendor: Dell Inc. dmi.board.version: A01 dmi.chassis.type: 17 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.2.1:bd01/28/2010:svnDellInc.:pnPowerEdgeT110:pvr:rvnDellInc.:rn0X744K:rvrA01:cvnDellInc.:ct17:cvr: dmi.product.name: PowerEdge T110 dmi.sys.vendor: Dell Inc. ** Affects: plymouth (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug lucid -- plymouth causes staircase right-shifting on serial console https://bugs.launchpad.net/bugs/606512 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 606512] Re: plymouth causes staircase right-shifting on serial console
** Attachment added: BootDmesg.txt http://launchpadlibrarian.net/52051686/BootDmesg.txt ** Attachment added: CurrentDmesg.txt http://launchpadlibrarian.net/52051687/CurrentDmesg.txt ** Attachment added: Dependencies.txt http://launchpadlibrarian.net/52051688/Dependencies.txt ** Attachment added: Lspci.txt http://launchpadlibrarian.net/52051689/Lspci.txt ** Attachment added: ProcCpuinfo.txt http://launchpadlibrarian.net/52051690/ProcCpuinfo.txt ** Attachment added: ProcInterrupts.txt http://launchpadlibrarian.net/52051691/ProcInterrupts.txt ** Attachment added: ProcModules.txt http://launchpadlibrarian.net/52051692/ProcModules.txt ** Attachment added: UdevDb.txt http://launchpadlibrarian.net/52051693/UdevDb.txt ** Attachment added: UdevLog.txt http://launchpadlibrarian.net/52051694/UdevLog.txt -- plymouth causes staircase right-shifting on serial console https://bugs.launchpad.net/bugs/606512 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 602723] Re: Upstart job to clean /tmp does not run when /usr is on a seperate partion
*** This bug is a duplicate of bug 523587 *** https://bugs.launchpad.net/bugs/523587 ** This bug has been marked a duplicate of bug 523587 /etc/init/mounted-tmp.conf uses find, which is in /usr/bin -- Upstart job to clean /tmp does not run when /usr is on a seperate partion https://bugs.launchpad.net/bugs/602723 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 153425] Re: (Multiseat) screen shifts when /dev/console written to
For the record I filed this as Ubuntu Bug https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/606512 -- (Multiseat) screen shifts when /dev/console written to https://bugs.launchpad.net/bugs/153425 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 605687] Re: mountall runs fsck, all clean, mounts, twice... out of boredom?
I think I should say a little more about my power failure which may be relevant. I installed the NUT 2.4.3 package for use with a Cyberpower CP1500AVRLCD UPS system. I set it up with a usb connection using the usbhid-ups driver. Everything worked very well and I was pretty much done when I decided to test the upscmd ups shutdown.stayoff command. I expected this to run the usual shutdown procedure, but, as far as I could tell (my server is in another room) it did an immediate power off instead. The next two boots were very odd : part way into the boot process the machine would start to go into hibernation, where it would stay for exactly two minutes (as shown by /var/log/pm-suspend.log), before waking up and resuming the boot process. After two boots I disconnected the UPS usb cable and disabled NUT by setting MODE=none in /etc/nut/nut.conf and the hibernation problem went away. Amongst the fscks in my boot logs I found init: mounted-tmp main process (877) terminated with status 127 mountall: Event failed which I eventually discovered is caused by the /tmp (non-) cleaning bug https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/523587 I figured stale files in /tmp might have been responsible for the strange behaviour on boot, and fixed this bug on my system by changing /etc/init /mounted-tmp.conf to read start on local-filesystems. Now I'm not so sure... It seems to me that even if mountall is still running and the boredom timer does trigger the re-fsck and re-mount, it would not do so if the partitions were still mounted. So I'm wondering if maybe the NUT command did not simply power off my system, but instead did some sort of highly abbreviated shutdown, like killall5, umount -a, followed by a power off. I'm wondering if that umount command, or the trigger to run it, is still lurking somewhere in my system, and is discovered at boot causing the re-fsck problem. This is all speculation at the moment, but it's what I'll be investigating next. If anyone has any idea where NUT might have lodged a umount -a command on my system, please speak up. Thanks -- mountall runs fsck, all clean, mounts, twice... out of boredom? https://bugs.launchpad.net/bugs/605687 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 605687] Re: mountall does everything twice
** Summary changed: - mountall runs fsck, all clean, mounts, twice... out of boredom? + mountall does everything twice -- mountall does everything twice https://bugs.launchpad.net/bugs/605687 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 605687] Re: mountall does everything twice
It seems upscmd ups shutdown.stayoff does simply power off the load after all. I downloaded the nut source package and everything I saw pointed that way. I couldn't find any evidence of the code writing flags or commands to disk, though I admit I lost track of things through the socket. So, I figured maybe a dirty /tmp was the problem, attached the UPS, restarted NUT, and rebooted... and it was fine. No dive into hibernation halfway through the boot. Whether it was /tmp, or power cycling the UPS, or manually restarting NUT, or something else, I can't say, but this problem seems to have gone away. The boot still mounted all my disks twice though. So it seems likely to me that the power failure had nothing to do with this - it just caused me to study the boot logs. I put echos in both the script section and the post-stop script section of mountall.conf before this boot. The boot log shows the post-stop script echo twice, but the script echo only once. Sometimes boot messages do get partly obscured by others on the serial console, so I suppose it's possible the other script echo disappeared. I should add that /var/log/boot.log only contains a small fragment of the complete boot-time console messages seen over SOL. I have another hunch. Will investigate tomorrow. -- mountall does everything twice https://bugs.launchpad.net/bugs/605687 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 605687] [NEW] mountall runs fsck, all clean, mounts, twice... out of boredom?
Public bug reported: Binary package hint: mountall My system (running Ubuntu 10.04 64-bit Desktop) has partitions /, /var, /usr, /home, /boot, /tmp, and ben1 on a 2nd disk. At boot, fsck is run on all partitions, and all report clean, and are mounted successfully. The boot continues happily with several processes from /etc/init.d starting up OK. Then mountall goes through the whole process again, fscking everything and remounting all the partitions. The boot continues, with comments from some processes that they're already running. I've attached my boot log pasted directly from my serial-over-lan (SOL) console. I had mountall --debug in /etc/init/mountall.conf for this. Without this flag a different amount (slightly fewer) of my boot processes get completed before the 2nd fsck commences. I've studied mountall.c and although I'm stumped I suspect that the re- fsck may be caused by the 3 (second?) boredom timer timing out. If this is correct, the question becomes, why doesn't mountall exit when all the filesystems are mounted? I had a power failure recently. I don't know if that's relevant. That's when and why I started looking at boot logs closely. I have no idea if the system was doing this before the power failure ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: mountall 2.15 ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2 Uname: Linux 2.6.32-22-generic x86_64 Architecture: amd64 Date: Wed Jul 14 17:37:32 2010 InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100427.1) ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: mountall ** Affects: mountall (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug lucid -- mountall runs fsck, all clean, mounts, twice... out of boredom? https://bugs.launchpad.net/bugs/605687 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 605687] Re: mountall runs fsck, all clean, mounts, twice... out of boredom?
** Attachment added: boot_mountall_debug http://launchpadlibrarian.net/51952175/boot_mountall_debug ** Attachment added: Dependencies.txt http://launchpadlibrarian.net/51949956/Dependencies.txt -- mountall runs fsck, all clean, mounts, twice... out of boredom? https://bugs.launchpad.net/bugs/605687 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 153425] Re: (Multiseat) screen shifts when /dev/console written to
I now realise my comments were about a different kind of right-shifting behaviour which affects only the text on a line by line basis, not the whole screen, and which appears to be known as the staircase effect. Sorry for posting off topic. But, since I started, I'll mention that I managed to solve the problem by disabling Plymouth at shutdown. I'm not sure if this has other undesirable effects, but it did sort out my shutdown messages! -- (Multiseat) screen shifts when /dev/console written to https://bugs.launchpad.net/bugs/153425 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 603363] [NEW] sshd never stops, prevents umount of /usr partition
Public bug reported: Under Ubuntu 10.04 Lucid, sshd is an upstart job controlled by /etc/init/ssh.conf This file provides for start and stop as follows: start on filesystem stop on runlevel S At shutdown or reboot, therefore, sshd is not stopped. Since sshd is in /usr/sbin/sshd and also accesses lib files in /usr/lib this means that /etc/rc0.d/S40umountfs cannot successfully umount /usr at shutdown when /usr is on its own partition. This definitely leads to umount reporting errors in the shutdown console messages. It may also lead to fsck running on reboot and problems with mountall... I can't say for certain yet as I am also having problems umounting /var, possibly due to a power failure, which is what led me to notice and investigate these messages. My guess is that when sshd was a System V init process, it was killed by the killall5 process in /etc/rc0.d/S20sendsigs. Under Lucid sshd has been made an upstart job and as such is exempt from the killall5 and so needs to be stopped explicitly. I admit I am by no means an expert on upstart or sshd, but the fix appears to me to be to modify /etc/init/ssh.conf to read stop on runlevel [!2345] ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: openssh-server 1:5.3p1-3ubuntu4 ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2 Uname: Linux 2.6.32-22-generic x86_64 Architecture: amd64 Date: Thu Jul 8 14:45:50 2010 InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100427.1) ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: openssh ** Affects: openssh (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug lucid -- sshd never stops, prevents umount of /usr partition https://bugs.launchpad.net/bugs/603363 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openssh 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 603363] Re: sshd never stops, prevents umount of /usr partition
** Attachment added: Dependencies.txt http://launchpadlibrarian.net/51594460/Dependencies.txt -- sshd never stops, prevents umount of /usr partition https://bugs.launchpad.net/bugs/603363 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openssh 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 603363] Re: sshd never stops, prevents umount of /usr partition
Jolly good. I'm blogging my progress on this thread http://ubuntuforums.org/showthread.php?t=1474942 which also describes the boot time messages that _may_ be related to this problem. I'll post here directly if/when I can confirm that they are/aren't. -- sshd never stops, prevents umount of /usr partition https://bugs.launchpad.net/bugs/603363 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openssh 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 603363] [NEW] sshd never stops, prevents umount of /usr partition
Public bug reported: Under Ubuntu 10.04 Lucid, sshd is an upstart job controlled by /etc/init/ssh.conf This file provides for start and stop as follows: start on filesystem stop on runlevel S At shutdown or reboot, therefore, sshd is not stopped. Since sshd is in /usr/sbin/sshd and also accesses lib files in /usr/lib this means that /etc/rc0.d/S40umountfs cannot successfully umount /usr at shutdown when /usr is on its own partition. This definitely leads to umount reporting errors in the shutdown console messages. It may also lead to fsck running on reboot and problems with mountall... I can't say for certain yet as I am also having problems umounting /var, possibly due to a power failure, which is what led me to notice and investigate these messages. My guess is that when sshd was a System V init process, it was killed by the killall5 process in /etc/rc0.d/S20sendsigs. Under Lucid sshd has been made an upstart job and as such is exempt from the killall5 and so needs to be stopped explicitly. I admit I am by no means an expert on upstart or sshd, but the fix appears to me to be to modify /etc/init/ssh.conf to read stop on runlevel [!2345] ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: openssh-server 1:5.3p1-3ubuntu4 ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2 Uname: Linux 2.6.32-22-generic x86_64 Architecture: amd64 Date: Thu Jul 8 14:45:50 2010 InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100427.1) ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: openssh ** Affects: openssh (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug lucid -- sshd never stops, prevents umount of /usr partition https://bugs.launchpad.net/bugs/603363 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 603363] Re: sshd never stops, prevents umount of /usr partition
** Attachment added: Dependencies.txt http://launchpadlibrarian.net/51594460/Dependencies.txt -- sshd never stops, prevents umount of /usr partition https://bugs.launchpad.net/bugs/603363 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 603363] Re: sshd never stops, prevents umount of /usr partition
Jolly good. I'm blogging my progress on this thread http://ubuntuforums.org/showthread.php?t=1474942 which also describes the boot time messages that _may_ be related to this problem. I'll post here directly if/when I can confirm that they are/aren't. -- sshd never stops, prevents umount of /usr partition https://bugs.launchpad.net/bugs/603363 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 153425] Re: (Multiseat) screen shifts when /dev/console written to
I'm seeing much the same right shifting of the console while running a serial console. System is Dell T110 PowerEdge, running Ubuntu 10.04 Lucid. Serial Console is running on windows with the same results using either a mintty windows or a Cygwin X xterm window. It mostly seems to affect shutdown messages rather than boot messages, and, as far as I can figure out it's related to shutdown messages generated using echo -n. When the newline finally comes it causes a line feed but not a carriage return. The text gradually shifts right making some of it unreadable. I'm not sure this is the same problem you're seeing, but it sounds very similar. -- (Multiseat) screen shifts when /dev/console written to https://bugs.launchpad.net/bugs/153425 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 153425] Re: (Multiseat) screen shifts when /dev/console written to
In the case that I've examined I can add that the newline is supplied by the log_success_msg function in /etc/lsb-base-logging.sh which is sourced into the bash script providing the echo -n (Dell/SARA's /etc/init.d/dataeng in this particular case). -- (Multiseat) screen shifts when /dev/console written to https://bugs.launchpad.net/bugs/153425 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: Cygwin Maximum Memory Documentation
Looks like I posted too soon.
I can run SOME Cygwin/gcc programs up to 2.83GB with the changes I mentioned in my first post
(yesterday), but not ALL programs (and not anything useful...). The problem seems to be with
Cygwin's implementation of disk access functions like fscanf() and fgets(). The following code as
written here and compiled under gcc/Cygwin (with the gcc line commented out at the top) WILL run up
to 2.83GB image size. However, if the fscanf() line is uncommented the resulting program dies just
above a 2GB image size with the error *** fatal error - cmalloc would have returned
NULL. The file tmp contains hello.\n. If the program is compiled with fscanf()
uncommented using cl (Visual Studio C++ compiler - the 2nd compile line commented out below) the
program will run up to 2.83GB before it runs out of memory. fgets() has the same effect as
fscanf(). I'm using Task Manager Mem Usage column to watch the memory grow.
I also tested fprintf(stdout,...) strlen() sscanf() calloc() sprintf() fopen()
fabs() fclose() strtok() strcmp() strdup() strspn() and free() all of which
work fine up to 2.83GB.
My conclusion is that there's something in Cygwin's implementation of disk
access functions (fscanf(), fgets(), ...?) that stops working when the process
image size goes over 2GB. Since the /3GB switch enables user pointers above
7FFF my guess would be something like assumptions made about the most
significant pointer bit.
/rob
#include stdlib.h
#include stdio.h
// to compile : gcc -g -Wall -Wpadded -Wl,--large-address-aware -o
memory_eater2.x memory_eater2.c
// to compile : cl memory_eater2.c winmm.lib /link /largeaddressaware
int main (int argc, char *argv[])
{
FILE *f;
char *buf;
long c = 0;
while (1 != 2) {
if ((buf = (char *) calloc(24,sizeof(char))) == NULL) {
fprintf(stderr,Problem in %s line %d allocating
memory\n,__FILE__,__LINE__);
return(1);
}
c++;
if ((c % 5000) == 0) {
if ((f = fopen(./tmp,r)) == NULL) {
fprintf(stderr,Problem in %s line %d opening input
file\n,__FILE__,__LINE__);
return(1);
}
// fscanf(f,%s,buf);
fclose(f);
}
}
return(0);
}
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin Maximum Memory Documentation
[ Apologies for the duplicate post. I'm trying to get this
retraction/qualification to be added to the original post's thread list,
since my first attempt was not. I'm concerned someone might find the
original via Google and then waste their time. If this second attempt
fails and someone out there can get a URL pointer to this message into a
post on the original's thread list, please do! The original post is at
http://cygwin.com/ml/cygwin/2010-04/msg00983.html ]
Looks like I posted too soon.
I can run SOME Cygwin/gcc programs up to 2.83GB with the changes I
mentioned in my first post (yesterday), but not ALL programs (and not
anything useful...). The problem seems to be with Cygwin's
implementation of disk access functions like fscanf() and fgets(). The
following code as written here and compiled under gcc/Cygwin (with the
gcc line commented out at the top) WILL run up to 2.83GB image size.
However, if the fscanf() line is uncommented the resulting program dies
just above a 2GB image size with the error *** fatal error - cmalloc
would have returned NULL. The file tmp contains hello.\n. If the
program is compiled with fscanf() uncommented using cl (Visual Studio
C++ compiler - the 2nd compile line commented out below) the program
will run up to 2.83GB before it runs out of memory. fgets() has the
same effect as fscanf(). I'm using Task Manager Mem Usage column to
watch the memory grow.
I also tested fprintf(stdout,...) strlen() sscanf() calloc() sprintf()
fopen() fabs() fclose() strtok() strcmp() strdup() strspn() and free()
all of which work fine up to 2.83GB.
My conclusion is that there's something in Cygwin's implementation of
disk access functions (fscanf(), fgets(), ...?) that stops working when
the process image size goes over 2GB. Since the /3GB switch enables
user pointers above 7FFF my guess would be something like
assumptions made about the most significant pointer bit.
/rob
#include stdlib.h
#include stdio.h
// to compile : gcc -g -Wall -Wpadded -Wl,--large-address-aware -o
memory_eater2.x memory_eater2.c
// to compile : cl memory_eater2.c winmm.lib /link /largeaddressaware
int main (int argc, char *argv[])
{
FILE *f;
char *buf;
long c = 0;
while (1 != 2) {
if ((buf = (char *) calloc(24,sizeof(char))) == NULL) {
fprintf(stderr,Problem in %s line %d allocating
memory\n,__FILE__,__LINE__);
return(1);
}
c++;
if ((c % 5000) == 0) {
if ((f = fopen(./tmp,r)) == NULL) {
fprintf(stderr,Problem in %s line %d opening input
file\n,__FILE__,__LINE__);
return(1);
}
// fscanf(f,%s,buf);
fclose(f);
}
}
return(0);
}
Rob Donovan wrote:
I've found the following to be true on my system and feel these
details could usefully be added to the Changing Cygwin's Maximum
Memory page in the User's Guide. My system is a Dell Inspiron 1520
laptop with 4GB of physical RAM running Windows XP Home Edition with
SP3. Uname -v reports the Cygwin Kernel version as 2010-04-07 11:02
Some of these comments are specific to XP; I gather Vista does not use
a boot.ini file, for example. Perhaps others running other operating
systems could flesh it out to provide complete documentation across
operating systems.
1) When changing the maximum memory available to Cygwin using regtool
-i set /HKLM/Software/Cygwin/heap_chunk_in_mb the maximum useful
value of is 4095. Values of 4096 and above result in the heap
size reverting to its unset value (about 1000 on my system).
2) With this change in place processes are still limited to 2GB of
memory on 32-bit Windows systems, unless you set the /3GB switch in
your boot.ini file. This switch allows each process to grow to 3GB.
However, used alone it may have undesirable consequences (such as your
system hanging) which the /Userva= flag may prevent. from
2900 to 3030 is recommended. This switch caps user processes at MB.
The change might be from a boot.ini file of
[boot loader]
;timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS=Microsoft Windows XP Home
Edition /noexecute=optin /fastdetect
to
[boot loader]
;timeout=30
default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS=Microsoft Windows XP Home
Edition /noexecute=optin /fastdetect
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS=Microsoft Windows XP Home
Edition 2.83GB /3GB /Userva=2900 /noexecute=optin /fastdetect
You should then get a choice between OS configurations at boot. If
you use a 3rd party boot loader you may have to make the configuration
changes there instead of directly to the boot.ini file.
3) With both these changes in place your process will STILL be limited
to 2GB process size, unless you compile it with the /LARGEADDRESSAWARE
linker flag in place. Under gcc this flag is specified thus : gcc
-Wl,--large
Cygwin Maximum Memory Documentation
I've found the following to be true on my system and feel these details could usefully be added to the Changing Cygwin's Maximum Memory page in the User's Guide. My system is a Dell Inspiron 1520 laptop with 4GB of physical RAM running Windows XP Home Edition with SP3. Uname -v reports the Cygwin Kernel version as 2010-04-07 11:02 Some of these comments are specific to XP; I gather Vista does not use a boot.ini file, for example. Perhaps others running other operating systems could flesh it out to provide complete documentation across operating systems. 1) When changing the maximum memory available to Cygwin using regtool -i set /HKLM/Software/Cygwin/heap_chunk_in_mb the maximum useful value of is 4095. Values of 4096 and above result in the heap size reverting to its unset value (about 1000 on my system). 2) With this change in place processes are still limited to 2GB of memory on 32-bit Windows systems, unless you set the /3GB switch in your boot.ini file. This switch allows each process to grow to 3GB. However, used alone it may have undesirable consequences (such as your system hanging) which the /Userva= flag may prevent. from 2900 to 3030 is recommended. This switch caps user processes at MB. The change might be from a boot.ini file of [boot loader] ;timeout=30 default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINDOWS=Microsoft Windows XP Home Edition /noexecute=optin /fastdetect to [boot loader] ;timeout=30 default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINDOWS=Microsoft Windows XP Home Edition /noexecute=optin /fastdetect multi(0)disk(0)rdisk(0)partition(2)\WINDOWS=Microsoft Windows XP Home Edition 2.83GB /3GB /Userva=2900 /noexecute=optin /fastdetect You should then get a choice between OS configurations at boot. If you use a 3rd party boot loader you may have to make the configuration changes there instead of directly to the boot.ini file. 3) With both these changes in place your process will STILL be limited to 2GB process size, unless you compile it with the /LARGEADDRESSAWARE linker flag in place. Under gcc this flag is specified thus : gcc -Wl,--large-address-aware -o program.x program.cThat's W ell, not W one. With all these changes in place I can now run gcc compiled Cygwin processes up to 2.83GB in size :) /rob -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
