CVS Head: "Error Value: iterable argument required" when adding objects
Is anyone else seeing this with a fresh checkout of CVS head (linux, py2.3.2, 2004-01-17 16:40 EST)? When adding any object from the ZMI, I get the same error. Nothing shows up in Z2.log. I can only start zope with runzope at the moment, no error message is indicated in that console when adding. Thanks. ----------------------------- Site Error An error was encountered while publishing this resource. Error Type: TypeError Error Value: iterable argument required ----------------------------- (sidebar, the zopectl error is: $ /var/zope/bin/zopectl start Traceback (most recent call last): File "/opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py", line 207, in ? main() File "/opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py", line 190, in main c.onecmd(" ".join(options.args)) File "/usr/lib/python2.3/cmd.py", line 210, in onecmd return func(arg) File "/opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py", line 134, in do_start ZDCmd.do_start(self, arg) File "/opt/Zope-2.8/lib/python/zdaemon/zdctl.py", line 205, in do_start args += self._get_override("-m", "umask") File "/opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py", line 116, in _get_override value = getattr(self.options, name) AttributeError: ZopeCtlOptions instance has no attribute 'umask'
This error popped up in the nightly tests as well. I haven't spent any time tracking it down. On Sat, 2004-01-17 at 16:58, Jeff Kowalczyk wrote:
Is anyone else seeing this with a fresh checkout of CVS head (linux, py2.3.2, 2004-01-17 16:40 EST)? When adding any object from the ZMI, I get the same error. Nothing shows up in Z2.log. I can only start zope with runzope at the moment, no error message is indicated in that console when adding.
Thanks.
----------------------------- Site Error An error was encountered while publishing this resource. Error Type: TypeError Error Value: iterable argument required
----------------------------- (sidebar, the zopectl error is: $ /var/zope/bin/zopectl start Traceback (most recent call last): File "/opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py", line 207, in ? main() File "/opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py", line 190, in main c.onecmd(" ".join(options.args)) File "/usr/lib/python2.3/cmd.py", line 210, in onecmd return func(arg) File "/opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py", line 134, in do_start ZDCmd.do_start(self, arg) File "/opt/Zope-2.8/lib/python/zdaemon/zdctl.py", line 205, in do_start args += self._get_override("-m", "umask") File "/opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py", line 116, in _get_override value = getattr(self.options, name) AttributeError: ZopeCtlOptions instance has no attribute 'umask'
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
I forgot to check event.log, that gives information about the problem. Thanks. 2004-01-17T17:07:23 PROBLEM(100) ZODB FS FS21 warn: Ignoring index for /var/zope/var/Data.fs ------ 2004-01-17T17:07:24 INFO(0) Zope Ready to handle requests ------ 2004-01-17T17:07:48 PROBLEM(100) Zope Security Policy '<PermissionRole object at 0x40940db8>' passed as roles during validation of 'manage_access' is not a sequence. ------ 2004-01-17T17:07:48 PROBLEM(100) Zope Security Policy '<PermissionRole object at 0x40940db8>' passed as roles during validation of 'manage_access' is not a sequence. ------ 2004-01-17T17:08:04 PROBLEM(100) Zope Security Policy '<PermissionRole object at 0x40e4cec0>' passed as roles during validation of 'manage_addFolder' is not a sequence.
On Sat, 2004-01-17 at 16:58, Jeff Kowalczyk wrote:
(sidebar, the zopectl error is: $ /var/zope/bin/zopectl start Traceback (most recent call last): File "/opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py", line 207, in ? main() File "/opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py", line 190, in main c.onecmd(" ".join(options.args)) File "/usr/lib/python2.3/cmd.py", line 210, in onecmd return func(arg) File "/opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py", line 134, in do_start ZDCmd.do_start(self, arg) File "/opt/Zope-2.8/lib/python/zdaemon/zdctl.py", line 205, in do_start args += self._get_override("-m", "umask") File "/opt/Zope-2.8/lib/python/Zope/Startup/zopectl.py", line 116, in _get_override value = getattr(self.options, name) AttributeError: ZopeCtlOptions instance has no attribute 'umask'
I committed a patch with the umask option a few days ago. I thought it only affected zdaemon and the tests all looked clean afterwards. I'm not sure how zopectl.py ends up being affected or why there aren't any tests of it. The various scripts to start and stop programs are usually hard to test, but they're usually the source of a lot of bugs, too. Jeremy
Jeremy Hylton wrote:
I committed a patch with the umask option a few days ago. I thought it only affected zdaemon and the tests all looked clean afterwards. I'm not sure how zopectl.py ends up being affected or why there aren't any tests of it. The various scripts to start and stop programs are usually hard to test, but they're usually the source of a lot of bugs, too.
Speaking as a sysadmin I'd like to suggest that the zope daemons make no efforts to frob thier assigned umasks in any way. Thats generally something the sysadmin will take care of during the startup scripts, and to have daemons change it after the fact because they think they know "better" causes no end of frustration. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer
On Sat, 2004-01-17 at 17:22, Jamie Heilman wrote:
Jeremy Hylton wrote:
I committed a patch with the umask option a few days ago. I thought it only affected zdaemon and the tests all looked clean afterwards. I'm not sure how zopectl.py ends up being affected or why there aren't any tests of it. The various scripts to start and stop programs are usually hard to test, but they're usually the source of a lot of bugs, too.
Speaking as a sysadmin I'd like to suggest that the zope daemons make no efforts to frob thier assigned umasks in any way. Thats generally something the sysadmin will take care of during the startup scripts, and to have daemons change it after the fact because they think they know "better" causes no end of frustration.
You should take it up with the sysadmin on the zodb-dev list who wanted this feature :-). Daemons don't set the umask by themselves; they only do it when a sysadmin configures zdaemon to run with the --umask argument. All the advice I can find about writing daemon code suggests that setting the umask is desirable. The zdaemon code that we've been using is based on these guidelines http://www.hawklord.uklinux.net/system/daemons/d3.htm, which recommend resetting the umask in a daemon. They are basically the same as the coding rules for daemons in Steve's Advanced Programming in the Unix Environment. Jeremy
Jeremy Hylton wrote:
You should take it up with the sysadmin on the zodb-dev list who wanted this feature :-).
They already had it, they just need to learn how to take advantage of the environment they're working in.
Daemons don't set the umask by themselves; they only do it when a sysadmin configures zdaemon to run with the --umask argument.
Thats good.
All the advice I can find about writing daemon code suggests that setting the umask is desirable.
Its desirable in some circumstances, but not all. Part of the problem is people tend to blindly follow the traditional approach to daemon design without bothering to actually do any critical thinking. There are several very reasonable arguments for deviation from the historical approach. Perhaps the most relevant argument is the same old one about the Unix design philosophy; many small programs working together is more a flexible and ultimately useful approach than a monolithic one-program-does-it-all design. Anyway, if you want to question authority, consider reading: http://homepages.tesco.net/~J.deBoynePollard/FGA/unix-daemon-design-mistakes... or http://cloud9.hedgee.com./scribbles/daemon or even better yet, look back over the CVS commits and bugs fixed in the Zope code (or other traditional-design daemons) that have been related to the current design choices and think about how they could have arisen under the more modular approach and how they might have been fixed in those circumstances. -- Jamie Heilman http://audible.transient.net/~jamie/
On Sat, 2004-01-17 at 18:30, Jamie Heilman wrote:
Its desirable in some circumstances, but not all. Part of the problem is people tend to blindly follow the traditional approach to daemon design without bothering to actually do any critical thinking.
I expect you don't intend to sound rude, but this gives the impression you think I've failed to do some necessary critical thinking. Even if I you think that, it's hardly diplomatic to point it out.
There are several very reasonable arguments for deviation from the historical approach.
What are they?
historical approach. Perhaps the most relevant argument is the same old one about the Unix design philosophy; many small programs working together is more a flexible and ultimately useful approach than a monolithic one-program-does-it-all design.
I don't follow how this advice relates to the current discussion. We're talking about whether zdrun.py should have a --umask option. zdrun is a small program. It just allows some other program to run as a daemon.
Anyway, if you want to question authority, consider reading: http://homepages.tesco.net/~J.deBoynePollard/FGA/unix-daemon-design-mistakes...
I don't see how this questions authority. It sounds entirely compatible with the design of zdaemon. (The TCP/IP stuff doesn't apply to zdaemon, and Zope works differently, but that's typical for app servers.) Are you familiar with zdaemon? Jeremy
Jeremy Hylton wrote:
On Sat, 2004-01-17 at 18:30, Jamie Heilman wrote:
Its desirable in some circumstances, but not all. Part of the problem is people tend to blindly follow the traditional approach to daemon design without bothering to actually do any critical thinking.
I expect you don't intend to sound rude, but this gives the impression you think I've failed to do some necessary critical thinking. Even if I you think that, it's hardly diplomatic to point it out.
No I don't think you failed in any way, sorry if I gave that impression. I intended to bemoan the overall state of what are generally espoused to be "best-practices" when it comes to daemon design. As you said, the umask code only comes into play when explicitly asked for, and I think thats a really good thing, my initial concern was that the umask would be set to a default value regardless of the parent process's properties.
There are several very reasonable arguments for deviation from the historical approach.
What are they?
They were listed in the URIs, but the jist is that its better to let small dedicated programs handle the daemonization and supervision of long-running code, than it is to embed those gymnastics into the code itself.
I don't follow how this advice relates to the current discussion. We're talking about whether zdrun.py should have a --umask option.
Ah, well, you are maybe--to me I see an error thats carping about a missing "umask" attribute value and no mention of zdrun, so it wasn't immediately clear to me which aspects of zope the umask would apply to. Now that I know its part of a broad (entire process group) control mechanism I'm less concerned.
Anyway, if you want to question authority, consider reading: http://homepages.tesco.net/~J.deBoynePollard/FGA/unix-daemon-design-mistakes...
I don't see how this questions authority. It sounds entirely compatible with the design of zdaemon.
Well, yes, to an extent. There's a large breakdown when it comes to the design of event logging.
(The TCP/IP stuff doesn't apply to zdaemon, and Zope works differently, but that's typical for app servers.)
agreed
Are you familiar with zdaemon?
In purpose yes, but I don't use it in production. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby
Jeremy Hylton wrote at 2004-1-17 17:39 -0500:
... "umask" setting ... they only do it when a sysadmin configures zdaemon to run with the --umask argument.
That's not what the "zdaemon" documentation (as distributed with Zope 2.7b3) says: I read there: "zdaemon" sets the umask to "077" (preventing access by group and other) when it starts a program as a daemon. One may want that the group should have more rights. Therefore, someone suggested an "umask" option to control this "zdaemon" behaviour. -- Dieter
On Sun, 2004-01-18 at 16:02, Dieter Maurer wrote:
Jeremy Hylton wrote at 2004-1-17 17:39 -0500:
... "umask" setting ... they only do it when a sysadmin configures zdaemon to run with the --umask argument.
That's not what the "zdaemon" documentation (as distributed with Zope 2.7b3) says:
Where is that documentation? I'm not able to find it.
I read there: "zdaemon" sets the umask to "077" (preventing access by group and other) when it starts a program as a daemon.
Indeed, I was confused about this corner of the code, too. It calls umask(022) by default. The code is followed by an XXX comment that mentions Stevens' recommendation to use umask(0). Not sure why 022 was chosen, except, perhaps, that it is often a reasonable umask().
One may want that the group should have more rights.
Therefore, someone suggested an "umask" option to control this "zdaemon" behaviour.
That's was just added on the head. Jeremy
Jeremy Hylton writes:
Where is that documentation? I'm not able to find it.
There used to be a couple of .txt files for this, but I don't remember where. ;-( -Fred -- Fred L. Drake, Jr. <fred at zope.com> PythonLabs at Zope Corporation
Jeremy Hylton wrote at 2004-1-19 09:31 -0500:
On Sun, 2004-01-18 at 16:02, Dieter Maurer wrote: ...
That's not what the "zdaemon" documentation (as distributed with Zope 2.7b3) says:
Where is that documentation? I'm not able to find it.
"ZConfig" configured packages often have documentation in "schema.xml" and "component.xml" files. The mentioned documentation is in "zdaemon/component.xml". It reads: .... <key name="daemon" datatype="boolean" required="no" default="false"> <description> Command-line option: -d or --daemon. If this option is true, zdrun.py runs in the background as a true daemon. It forks an child process which becomes the subprocess manager, while the parent exits (making the shell that started it believe it is done). The child process also does the following: - if the directory option is set, change into that directory - redirect stdin, stdout and stderr to /dev/null - call setsid() so it becomes a session leader - call umask(022) </description> </key> .... -- Dieter
participants (6)
-
Chris McDonough -
Dieter Maurer -
Fred L. Drake, Jr. -
Jamie Heilman -
Jeff Kowalczyk -
Jeremy Hylton