Bug 160459
| Summary: | Bugzilla "submit bug to Bugzilla" shows a blank page | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Community] Bugzilla | Reporter: | David Tonhofer <bughunt> | ||||
| Component: | Bugzilla General | Assignee: | PnT DevOps Devs <hss-ied-bugs> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | David Lawrence <dkl> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3.2 | ||||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-11-07 16:17:31 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
David Tonhofer
2005-06-15 09:55:04 UTC
Ok, so this submission worked, so it's not a temporary error on the Red Hat Bugzilla site. Good. Here are the submission results from the problematic bug: The blank page shown after "submit bug to bugzilla" has been clicked has URL https://bugzilla.redhat.com/bugzilla/easy_enter_bug.cgi and contains: <body> <form action="post_bug.cgi" method="get"> <input type=hidden name="product" value="Red Hat Enterprise Linux"> <input type=hidden name="component" value="rhgb"> <input type=hidden name="rep_platform" value="i686"> <input type=hidden name="version" value="4"> <input type=hidden name="priority" value="normal"> <input type=hidden name="bug_severity" value="normal"> <input type=hidden name="bug_file_loc" value=""> <input type=hidden name="short_desc" value=""rhgb-client --update" hangs during boot (the boot process block at 'starting network')"> <input type=hidden name="comment" value="From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Description of problem: When booting in graphical mode (/etc/sysconfig/init:GRAPHICAL=yes) the boot process goes up to 'starting networking', then hangs (the little rotary icon stops moving ;-) When booting in text mode (/etc/sysconfig/init:GRAPHICAL=no) or having clicked 'show details' once X comes up and starts to show the boot progress bar, the boot process proceeds normally. Analysis: When the boot 'hangs' it is actually waiting for "rhgb-client". Once the rotary icon stopped moving during 'starting networking', I could SSH into the machine (the network was up) and get the process list: root 1 0.5 0.0 2988 552 ? S 13:11 0:00 init [5] root 2 0.0 0.0 0 0 ? SN 13:11 0:00 [ksoftirqd/0] root 3 0.0 0.0 0 0 ? S< 13:11 0:00 [events/0] root 4 0.0 0.0 0 0 ? S< 13:11 0:00 \_ [khelper] root 5 0.0 0.0 0 0 ? S< 13:11 0:00 \_ [kacpid] root 19 0.0 0.0 0 0 ? S< 13:11 0:00 \_ [kblockd/0] root 29 0.0 0.0 0 0 ? S 13:11 0:00 \_ [pdflush] root 30 0.0 0.0 0 0 ? S 13:11 0:00 \_ [pdflush] root 32 0.0 0.0 0 0 ? S< 13:11 0:00 \_ [aio/0] root 196 0.0 0.0 0 0 ? S< 13:11 0:00 \_ [kmirrord/0] root 20 0.0 0.0 0 0 ? S 13:11 0:00 [khubd] root 31 0.0 0.0 0 0 ? S 13:11 0:00 [kswapd0] root 106 0.0 0.0 0 0 ? S 13:11 0:00 [kseriod] root 187 0.0 0.0 0 0 ? S 13:11 0:00 [scsi_eh_0] root 188 0.0 0.0 0 0 ? S 13:11 0:00 [ahc_dv_0] root 202 0.0 0.0 0 0 ? S 13:11 0:00 [md3_raid1] root 204 0.0 0.0 0 0 ? S 13:11 0:00 [md2_raid1] root 206 0.0 0.0 0 0 ? S 13:11 0:00 [md1_raid1] root 207 0.0 0.0 0 0 ? S 13:11 0:00 [md0_raid1] root 219 0.0 0.0 0 0 ? S 13:11 0:00 [kjournald] root 1051 0.0 0.0 2524 444 ? S<s 13:11 0:00 udevd root 1254 0.0 0.0 0 0 ? S 13:12 0:00 [kjournald] root 1255 0.0 0.0 0 0 ? S 13:12 0:00 [kjournald] root 1256 0.0 0.0 0 0 ? S 13:12 0:00 [kjournald] root 1257 0.0 0.0 0 0 ? S 13:12 0:00 [kjournald] root 1258 0.0 0.0 0 0 ? S 13:12 0:00 [kjournald] root 1259 0.0 0.0 0 0 ? S 13:12 0:00 [kjournald] root 1260 0.0 0.0 0 0 ? S 13:12 0:00 [kjournald] root 1261 0.0 0.0 0 0 ? S 13:12 0:00 [kjournald] root 1264 0.5 0.4 15912 7660 ? Ss 13:12 0:00 /usr/bin/rhgb root 1266 1.0 0.5 11588 8568 ? S 13:12 0:01 \_ /usr/bin/X11/X -s off -dpms -v -nolock -fp /usr/lib/X11/fonts/misc -logfile /etc/rhgb/temp/ root 1318 0.0 0.0 3760 580 ? S 13:12 0:00 \_ gnome-pty-helper root 1319 0.0 0.0 2572 308 pts/0 Ss+ 13:12 0:00 \_ /sbin/change_console -f root 1373 0.1 0.0 5500 1316 ? Ss 13:12 0:00 /bin/bash /etc/rc.d/rc 5 root 2044 0.0 0.0 5556 480 ? S 13:12 0:00 \_ /usr/bin/rhgb-client --update=rawdevices root 1832 0.1 0.0 3156 592 ? Ss 13:12 0:00 syslogd -m 0 root 1836 0.0 0.0 3016 468 ? Ss 13:12 0:00 klogd -x rpc 1857 0.0 0.0 2080 592 ? Ss 13:12 0:00 portmap rpcuser 1877 0.0 0.0 2504 768 ? Ss 13:12 0:00 rpc.statd root 1889 0.0 0.0 3540 508 ? Ss 13:12 0:00 mdadm --monitor --scan -f root 1921 0.0 0.0 5136 1012 ? Ss 13:12 0:00 rpc.idmapd root 1994 0.0 0.0 2928 820 ? S 13:12 0:00 /usr/sbin/smartd root 2004 0.0 0.0 3140 552 ? Ss 13:12 0:00 /usr/sbin/acpid root 2016 0.0 0.1 8360 2040 ? Ss 13:12 0:00 cupsd root 2041 0.0 0.1 5660 1640 ? Ss 13:12 0:00 /usr/sbin/sshd root 2045 0.4 0.1 8084 2220 ? Ss 13:13 0:00 \_ sshd: root@pts/1 root 2047 0.3 0.0 5504 1400 pts/1 Ss 13:13 0:00 \_ -bash root 2083 0.0 0.0 3660 756 pts/1 R+ 13:13 0:00 \_ ps faux One can see process "/usr/bin/rhgb-client --update=rawdevices" doing nothing in particular. GDB shows a not very informative backtrace: #0 0x0056a7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x0064ab01 in connect () from /lib/tls/libc.so.6 #2 0x08048fcb in ?? () #3 0x00000004 in ?? () #4 0x096f8a68 in ?? () #5 0x0000006e in ?? () #6 0xbfe7d65c in ?? () #7 0x00000004 in ?? () #8 0x00000000 in ?? () A kill of that process brings us one step forward, a new rghb-client process shows up which hangs in turn: /usr/bin/rhgb-client --update=gpm /usr/bin/rhgb-client --update=crond etc.. These processes are only started in graphical boot according to /etc/rc.d/init.d/functions: update_boot_stage() { if [ "$GRAPHICAL" = "yes" -a -x /usr/bin/rhgb-client ]; then /usr/bin/rhgb-client --update="$1" fi return 0 } This explains the differing behaviour in graphical and non-graphical boot. Version-Release number of selected component (if applicable): rhgb-0.14.1-5 How reproducible: Always Steps to Reproduce: 1. Start machine in graphical boot 2. Boot process proceeds up to networking 3. Actual Results: Boot process hangs at "starting networking" Expected Results: Boot process should continue normally or timeout in rhgb-client Additional info: Possible hardware dependency: This problem has only been encounterd on a Fujitsu-Siemens Primery L100 (a weird machine if ever ever saw one), RHN sid=1005558364. There is no problem on a Fujitsu-Siemens Primergy RX300 S2 on the same network. Here is the extract from the log of a successful boot: Jun 14 13:12:10 rei2 sysstat: Calling the system activity data collector (sadc): Jun 14 13:12:10 rei2 sysstat: Jun 14 13:12:10 rei2 rc: Starting sysstat: succeeded Jun 14 13:12:29 rei2 smartd: smartd startup succeeded Jun 14 13:12:10 rei2 readahead_early: Starting background readahead: Jun 14 13:12:11 rei2 rc: Starting readahead_early: succeeded Jun 14 13:12:16 rei2 kudzu: succeeded Jun 14 13:12:19 rei2 iptables: succeeded Jun 14 13:12:20 rei2 rc: Starting pcmcia: succeeded Jun 14 13:12:29 rei2 acpid: acpid startup succeeded Jun 14 13:12:20 rei2 sysctl: net.ipv4.ip_forward = 0 Jun 14 13:12:20 rei2 sysctl: net.ipv4.conf.default.rp_filter = 1 Jun 14 13:12:20 rei2 sysctl: net.ipv4.conf.default.accept_source_route = 0 Jun 14 13:12:20 rei2 sysctl: kernel.sysrq = 0 Jun 14 13:12:20 rei2 sysctl: kernel.core_uses_pid = 1 Jun 14 13:12:20 rei2 network: Setting network parameters: succeeded Jun 14 13:12:20 rei2 network: Bringing up loopback interface: succeeded Jun 14 13:12:22 rei2 network: Bringing up interface eth0: succeeded Jun 14 13:12:25 rei2 network: Bringing up interface eth1: succeeded Jun 14 13:12:34 rei2 cups: cupsd startup succeeded Jun 14 13:12:34 rei2 sshd: succeeded "> <input type=hidden name="op_sys" value="Linux"> </form> </body> Created attachment 115468 [details]
The offending page as attachment
I tried to resubmit the problematic bug submission described above without the 'ps faux' dump. That works --> bug 160461 has been created. So it's something in the 'ps faux' formatting that causes bugzilla to misbehave. This bug is alive and well. Does it occur if the submitted bug has too many bytes? I tried to submit a bug with a text dump of 800 chars, but that didn't work. Removed it, it worked. Red Hat's current Bugzilla version is 2.18. I am moving all older open bugs to this version. Any bugs against the older versions will need to be verified that they are still bugs. This will help me also to sort them better. Red Hat Bugzilla is now using version 3.2 of the Bugzilla codebase and therefore this bug will need to be re-verified against the new release. With the updated code this bug may no longer be relevant or may have been fixed in the new code. Updating bug version to 3.2. |