On Aug 21, 2011, at 8:54 AM, Ed W wrote: > > >>> Which corresponds with my init file of: >>> >>> if [ "$COMMAND" = start -o "$COMMAND" = restart ]; then >> >> The above is wrong. Doing a blanket create of ipsets during a restart >> will always result in failures if the ipsets are used in the current >> configuration. > > Well, originally I deleted and recreated the ipsets each time, after > some time I decided I just wanted to create any missing entries. It's > just a harmless warning to try and create an already existing ipset > > On reflection I still don't understand what is happening here?
I couldn't understand from you trace either. > I thought "init" was a single script which would be run as a single unit > under a lock? All of the shell code being executed can be found at /var/lib/shorewall/.start or .restart depending on the command. The use of a lock file depends on whether the command being executed changes the configuration or not. Those commands that change the configuration create a lock file, do their thing, and then remove the lock file. > What seems to be happening is that each individual line is > getting individually subjected to some timeout - how is that happening? > Is "ipset" somehow getting intercepted as a function instead of calling > the ipset binary? > I don't know -- it is happening on your system, not mine. But again, you have access to the code. FWIW, your init file is wrapped in a function named run_init_exit(). > > >>> A follow-on minor gremlin is that if I control-C to kill this, then >>> there is a stale lock file left - this causes some follow on slowness >>> trying to do anything subsequently (a stale lock test might be nice?) >> >> As a workaround, simply remove the lockfile or set MUTEX_TIMEOUT to a >> few seconds. > > Thought occurs we could wrap access to the lockfile in a function and in > there check there is a valid process with that pid? If you felt this > was excessive stat-ing and a performance issue then we could solve the > most obvious occurrence by checking of the pid is stale (once) near the > start? > > What do you think? /usr/bin/lockfile does not store the locker's PID in the file; as far as I can tell, the file always contains '0' (with no newline). Using that program is the preferred way to create a lock file, since doing it in the shell is race-prone. But I'll see what I can do for 4.4.23. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
