Univention Bugzilla – Bug 31173
Errno 4 tracebacks when calling computerroom/settings/set
Last modified: 2013-06-07 21:40:11 CEST
With the current MS1 setup, I receive Errno 4 tracebacks when trying to call computerroom/settings/set while starting a new exam, e.g.: ==================== > Traceback (most recent call last): > File "/usr/lib/pymodules/python2.6/univention/management/console/modules/__init__.py", line 204, in execute > func( request ) > File "/usr/lib/pymodules/python2.6/univention/management/console/modules/computerroom/__init__.py", line 763, in settings_set > smbstatus = SMB_Status() > File "/usr/lib/pymodules/python2.6/ucsschool/lib/smbstatus.py", line 101, in __init__ > self.parse( testdata ) > File "/usr/lib/pymodules/python2.6/ucsschool/lib/smbstatus.py", line 108, in parse > data = smbstatus.stdout.readlines() > IOError: [Errno 4] Unterbrechung während des Betriebssystemaufrufs > > Traceback (most recent call last): > File "/usr/lib/pymodules/python2.6/univention/management/console/modules/__init__.py", line 204, in execute > func( request ) > File "/usr/lib/pymodules/python2.6/univention/management/console/modules/computerroom/__init__.py", line 735, in settings_set > handler_set( ucr_vars ) > File "/usr/lib/pymodules/python2.6/univention/config_registry/frontend.py", line 190, in handler_set > handlers(changed.keys(), (reg, changed)) > File "/usr/lib/pymodules/python2.6/univention/config_registry/handler.py", line 803, in __call__ > handler(arg) > File "/usr/lib/pymodules/python2.6/univention/config_registry/handler.py", line 332, in __call__ > srcfiles=self.from_files, opts=filter_opts)) > File "/usr/lib/pymodules/python2.6/univention/config_registry/handler.py", line 129, in run_filter > value = child_stdout.read() > IOError: [Errno 4] Unterbrechung während des Betriebssystemaufrufs ==================== This can happen potentially during any file read operation. During development, and with older Italc version, I did not experience this problem. Could that be the cause for this new misbehaviour? Reproducible when calling via JS: require('umc/tools').umcpCommand('computerroom/settings/set', { internetRule:"none", customRule:"", shareMode:"home", printMode:"default", examDescription:"foobar", exam:"foobar" }); It seems that this error is due to some special signal handling of Qt. Has there anything been changed? See also: http://bugs.python.org/issue1068268
*** This bug has been marked as a duplicate of bug 31140 ***
> It seems that this error is due to some special signal handling of Qt. Has > there anything been changed? > > See also: http://bugs.python.org/issue1068268 I don't think Qt is the culprit. As mentioned in the issue1068268, Python still contains some glitches when doing I/O operations and a process signal occurs (e.g. SIGCHILD or SIGALARM). I think the timing has changed. As noted in the issue, a wrapper function may be a workaround: def no_intr(self, func, *args, **kw): while True: try: return func(*args, **kw) except OSError, e: if e.errno == errno.EINTR: continue else: raise But I'm not sure if this is the best solution to wrap all read/readlines/… function calls. → Reopened, since this may have to be fixed at different locations within the code base.
*** Bug 31140 has been marked as a duplicate of this bug. ***
This problem is fixed in python 2.7.4: http://bugs.python.org/issue9867 → http://bugs.python.org/issue12268 But subprocess seems to be fixed already in python 2.6.6, so the read() calls have been replaced by subprocess.communicate(). This bug only fixes ucs-school-lib. UCR gets fixed in Bug 31140. Changelogentry has been comitted. ucs-school-lib has been built. ucs-school-lib (2.0.25-1) unstable; urgency=low
I still could reproduce Errno 4 tracebacks: > Traceback (most recent call last): > File "/usr/lib/pymodules/python2.6/univention/management/console/modules/__init__.py", line 204, in execute > func( request ) > File "/usr/lib/pymodules/python2.6/univention/management/console/modules/computerroom/__init__.py", line 763, in settings_set > smbstatus = SMB_Status() > File "/usr/lib/pymodules/python2.6/ucsschool/lib/smbstatus.py", line 113, in __init__ > self.parse( testdata ) > File "/usr/lib/pymodules/python2.6/ucsschool/lib/smbstatus.py", line 120, in parse > data = [ '%s\n' % x for x in smbstatus.communicate()[0].splitlines() ] > File "/usr/lib/python2.6/subprocess.py", line 683, in communicate > stdout = self.stdout.read() > IOError: [Errno 4] Unterbrechung während des Betriebssystemaufrufs → As communicate() is only using 1 Pipe, python is using a version that is not protected. Workaround could be to use a pipe on stdout and stderr, then python would use the protected communicated() version (→ _communicate()). > Traceback (most recent call last): > File "/usr/lib/pymodules/python2.6/univention/management/console/modules/__init__.py", line 204, in execute > func( request ) > File "/usr/lib/pymodules/python2.6/univention/management/console/modules/computerroom/__init__.py", line 598, in settings_set > jobs = atjobs.list( extended = True ) > File "/usr/lib/pymodules/python2.6/univention/lib/atjobs.py", line 110, in list > for line in p.stdout: > IOError: [Errno 4] Unterbrechung während des Betriebssystemaufrufs The atjobs lib (univention-lib) seems to be a problem, as well. I could not find other trackebacks than those two.
The traceback in atjobs.py has been split off to bug 31319. > → As communicate() is only using 1 Pipe, python is using a version that is not > protected. Workaround could be to use a pipe on stdout and stderr, then python > would use the protected communicated() version (→ _communicate()). smbstatus.py now uses stderr and stdout. In normal use the traceback did not occur and even while using the following I had no problems: while /bin/true ; do sleep 0.0$RANDOM; echo -n "."; kill -CHLD 9338 ; done ucs-school-lib (2.0.26-1) unstable; urgency=low → FIXED
(In reply to comment #6) > The traceback in atjobs.py has been split off to bug 31319. OK, with the given while-true loop, it took quite some more time to yield an Errno traceback. I conclude that the probability that a SIGCHILD signal occurs during processing of AT jobs is thus low enough to ignore it in this context for now... given additionally that I could not reproduce anymore the initial problem on my snapshotted system. > smbstatus.py now uses stderr and stdout. In normal use the traceback did not > occur and even while using the following I had no problems: OK, I could not reproduce any Errno tracebacks in the smbstatus.py anymore. changelog → OK Bug → VERIFIED
UCS@school 3.1 R2 has been released: http://download.univention.de/doc/release-notes-ucsschool-3.1-rev2.pdf If this error occurs again, please use "Clone This Bug".