Daniel Drake a écrit :
> Jimmy Jazz wrote:
>> Instead /sbin/functions.sh has helped me a lot to write a script that
>> does approximately the same but in ash and with candies too :)
> 
> Now you're making more sense -- you prefer baselayout written in bash
> because you are copying and mangling its code in ways that the
> developers didn't intend. I see.
> 
> FYI, baselayout-2 no longer requires bash.
> 
>> Right, a shell is not what handles the best concurrency issues but
>> "wait" and "jobs" have been quite improved. If you have an example i
>> could try. Also, that makes life exciting and i cheer you up. I'm sure
>> you will succeed and improve gentoo even better :)
> 
> The problem is that a few baselayout operations can be running
> concurrently, and these processes will share the same resources (e.g.
> service state files). baselayout-1 makes very little effort to serialize
> access to any of these resources, resulting in several highly repeatable
> failure conditions due to races.
> 
> The original bug report:
> https://bugs.gentoo.org/show_bug.cgi?id=154670
> 
> My attempt to fix it:
> https://bugs.gentoo.org/show_bug.cgi?id=166545
> 
> However, it turns out my locking implementation can be easily broken and
> is not race free.
> 
>> I'm not quite good in politics but i will follow your advice :). I
>> just have feared you will definitely drop baselayout-1. (anyway,
>> maintaining two different kinds of software that do approximately the
>> same thing is a pain). I will need to reconvert sooner or later.
> 
> I'm not involved in baselayout development, but yes, I am fairly sure
> that baselayout-1 will be completely dropped in the near future. It's
> partially unmaintained at the moment -- there are known bugs which will
> not be fixed in the 1.x branches.
> 
> Daniel


Hello Daniel,

I'm made a little draft to illustrate the possibilities of bash to
manage threads and lock files even if it doesn't call external scripts
from bash. That's a bit more tricky but that works well too ;)

The script runs concurrent projects. Every projects has an ordered team
affected to it and developers can be shared to more than one team. Every
time a manager tries to hire a developer for its project, he
will give more money for it ;).

To increase the nomber of teams, you need just to uncomment the
group[xx] lines or add new one. Take in mind, that is only a shell script.

Until you get "XX says: task Y for project n°Z done." the dev XX cannot
be affected to an other project. Otherwise you have found a bug :(

I voluntarily left a stderr error on line 44 to be displayed to ease the
comprehension of the process.

Also $$ is useless in a subshell. It will always
return the pid of the shell itself and not its own pid :(

$PPID shouldn't be interpreted by the current shell or else you won't
get the right pid (see the function getpid() in the script). Also, you
can call a C program that returns for you the pid of the shell on where
it was running.

Something like,

#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>

int main()
{
	printf("%d\n", getppid());
}

will work.

Anyway, it is possible to use bash and lock files even if you are not
able to determine the pid of the process and use the kill -s 0 ${pid}
command. If "set -C" is not supported by the shell, you can still use
any "atomic" calls like hard links but you will need to use an
intermediate file to do so. (See for examples on the web)

islocked() {
	ln $1 $2  #<------------------ is atomic
	rm -f ${1:-undefined}
}

flock() {
	local keylock="$(basename $1)"
	local pid="$$" #<-- doesn't work if called from the same script
	local locked="/var/tmp/lock/${keylock}.lck"
	local locker="/var/tmp/lock/${keylock}.${pid}"

	echo ${pid} > ${locker} || return 1

	if islocked ${locker} ${locked}; then
		return 0
	fi

...

        return 1
}

Actually, to save the pid in the locker is a good idea and will help to
find out any staled scripts still running, but that is not always
necessary and required :)

It should be executed like a user and needs no extra rights except to be
able to write in /var/tmp (as usual it is safer). Because you are not
allowed to write in /var/lock, create a new directory /var/tmp/lock
and copy the script in /var/tmp. Rename it with whatever name you want
and run it there. Moreover to save the believer, pass an option to that
script.

For the usage, the script is provided as-is ;)


If you like the demo, just let me know, i will feel even less lonely on
that mailing list ;)
If you are convinced, it is even better... If not, life will still go on :)

Jj

Ps: i hope there is no bug in it. I really didn't have to much time to
test it and ... that gives me a lot of headaches as well (i'm not used
to it) lol.


@Spock

also i finally get splashutils to work with ash and without fbsplash.
Most of the problems happened by the way how
/etc/spash/default/1680x1050.cfg for example refreshs some portions of
the screen and makes the lot flicker.

Meantimes, i take many times to understand how to "call" icons with the
daemon. If you send a svc_start you need to end with a svc_stop too
otherwise the icon continues to be displayed again and again :)

I still have one weird problem. It happens only on a x86_64 system. The
daemon core dumps when called from /sbin/rc but works during the
shutdown ?! I do not call expressly splash daemon from init.d as i
didn't use the verbose mode for ttys.

Thx anyway,

Jj