1 |
Daniel Drake a écrit : |
2 |
> Jimmy Jazz wrote: |
3 |
>> Instead /sbin/functions.sh has helped me a lot to write a script that |
4 |
>> does approximately the same but in ash and with candies too :) |
5 |
> |
6 |
> Now you're making more sense -- you prefer baselayout written in bash |
7 |
> because you are copying and mangling its code in ways that the |
8 |
> developers didn't intend. I see. |
9 |
> |
10 |
> FYI, baselayout-2 no longer requires bash. |
11 |
> |
12 |
>> Right, a shell is not what handles the best concurrency issues but |
13 |
>> "wait" and "jobs" have been quite improved. If you have an example i |
14 |
>> could try. Also, that makes life exciting and i cheer you up. I'm sure |
15 |
>> you will succeed and improve gentoo even better :) |
16 |
> |
17 |
> The problem is that a few baselayout operations can be running |
18 |
> concurrently, and these processes will share the same resources (e.g. |
19 |
> service state files). baselayout-1 makes very little effort to serialize |
20 |
> access to any of these resources, resulting in several highly repeatable |
21 |
> failure conditions due to races. |
22 |
> |
23 |
> The original bug report: |
24 |
> https://bugs.gentoo.org/show_bug.cgi?id=154670 |
25 |
> |
26 |
> My attempt to fix it: |
27 |
> https://bugs.gentoo.org/show_bug.cgi?id=166545 |
28 |
> |
29 |
> However, it turns out my locking implementation can be easily broken and |
30 |
> is not race free. |
31 |
> |
32 |
>> I'm not quite good in politics but i will follow your advice :). I |
33 |
>> just have feared you will definitely drop baselayout-1. (anyway, |
34 |
>> maintaining two different kinds of software that do approximately the |
35 |
>> same thing is a pain). I will need to reconvert sooner or later. |
36 |
> |
37 |
> I'm not involved in baselayout development, but yes, I am fairly sure |
38 |
> that baselayout-1 will be completely dropped in the near future. It's |
39 |
> partially unmaintained at the moment -- there are known bugs which will |
40 |
> not be fixed in the 1.x branches. |
41 |
> |
42 |
> Daniel |
43 |
|
44 |
|
45 |
Hello Daniel, |
46 |
|
47 |
I'm made a little draft to illustrate the possibilities of bash to |
48 |
manage threads and lock files even if it doesn't call external scripts |
49 |
from bash. That's a bit more tricky but that works well too ;) |
50 |
|
51 |
The script runs concurrent projects. Every projects has an ordered team |
52 |
affected to it and developers can be shared to more than one team. Every |
53 |
time a manager tries to hire a developer for its project, he |
54 |
will give more money for it ;). |
55 |
|
56 |
To increase the nomber of teams, you need just to uncomment the |
57 |
group[xx] lines or add new one. Take in mind, that is only a shell script. |
58 |
|
59 |
Until you get "XX says: task Y for project n°Z done." the dev XX cannot |
60 |
be affected to an other project. Otherwise you have found a bug :( |
61 |
|
62 |
I voluntarily left a stderr error on line 44 to be displayed to ease the |
63 |
comprehension of the process. |
64 |
|
65 |
Also $$ is useless in a subshell. It will always |
66 |
return the pid of the shell itself and not its own pid :( |
67 |
|
68 |
$PPID shouldn't be interpreted by the current shell or else you won't |
69 |
get the right pid (see the function getpid() in the script). Also, you |
70 |
can call a C program that returns for you the pid of the shell on where |
71 |
it was running. |
72 |
|
73 |
Something like, |
74 |
|
75 |
#include <sys/types.h> |
76 |
#include <unistd.h> |
77 |
#include <stdio.h> |
78 |
|
79 |
int main() |
80 |
{ |
81 |
printf("%d\n", getppid()); |
82 |
} |
83 |
|
84 |
will work. |
85 |
|
86 |
Anyway, it is possible to use bash and lock files even if you are not |
87 |
able to determine the pid of the process and use the kill -s 0 ${pid} |
88 |
command. If "set -C" is not supported by the shell, you can still use |
89 |
any "atomic" calls like hard links but you will need to use an |
90 |
intermediate file to do so. (See for examples on the web) |
91 |
|
92 |
islocked() { |
93 |
ln $1 $2 #<------------------ is atomic |
94 |
rm -f ${1:-undefined} |
95 |
} |
96 |
|
97 |
flock() { |
98 |
local keylock="$(basename $1)" |
99 |
local pid="$$" #<-- doesn't work if called from the same script |
100 |
local locked="/var/tmp/lock/${keylock}.lck" |
101 |
local locker="/var/tmp/lock/${keylock}.${pid}" |
102 |
|
103 |
echo ${pid} > ${locker} || return 1 |
104 |
|
105 |
if islocked ${locker} ${locked}; then |
106 |
return 0 |
107 |
fi |
108 |
|
109 |
... |
110 |
|
111 |
return 1 |
112 |
} |
113 |
|
114 |
Actually, to save the pid in the locker is a good idea and will help to |
115 |
find out any staled scripts still running, but that is not always |
116 |
necessary and required :) |
117 |
|
118 |
It should be executed like a user and needs no extra rights except to be |
119 |
able to write in /var/tmp (as usual it is safer). Because you are not |
120 |
allowed to write in /var/lock, create a new directory /var/tmp/lock |
121 |
and copy the script in /var/tmp. Rename it with whatever name you want |
122 |
and run it there. Moreover to save the believer, pass an option to that |
123 |
script. |
124 |
|
125 |
For the usage, the script is provided as-is ;) |
126 |
|
127 |
|
128 |
If you like the demo, just let me know, i will feel even less lonely on |
129 |
that mailing list ;) |
130 |
If you are convinced, it is even better... If not, life will still go on :) |
131 |
|
132 |
Jj |
133 |
|
134 |
Ps: i hope there is no bug in it. I really didn't have to much time to |
135 |
test it and ... that gives me a lot of headaches as well (i'm not used |
136 |
to it) lol. |
137 |
|
138 |
|
139 |
@Spock |
140 |
|
141 |
also i finally get splashutils to work with ash and without fbsplash. |
142 |
Most of the problems happened by the way how |
143 |
/etc/spash/default/1680x1050.cfg for example refreshs some portions of |
144 |
the screen and makes the lot flicker. |
145 |
|
146 |
Meantimes, i take many times to understand how to "call" icons with the |
147 |
daemon. If you send a svc_start you need to end with a svc_stop too |
148 |
otherwise the icon continues to be displayed again and again :) |
149 |
|
150 |
I still have one weird problem. It happens only on a x86_64 system. The |
151 |
daemon core dumps when called from /sbin/rc but works during the |
152 |
shutdown ?! I do not call expressly splash daemon from init.d as i |
153 |
didn't use the verbose mode for ttys. |
154 |
|
155 |
Thx anyway, |
156 |
|
157 |
Jj |