From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1I11QH-0001hl-QX for garchives@archives.gentoo.org; Wed, 20 Jun 2007 14:44:43 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l5KEhvuu006289; Wed, 20 Jun 2007 14:43:57 GMT Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l5KEhuNE006281 for ; Wed, 20 Jun 2007 14:43:57 GMT Received: (qmail invoked by alias); 20 Jun 2007 14:43:56 -0000 Received: from AStrasbourg-253-1-65-4.w90-26.abo.wanadoo.fr (EHLO [192.168.1.10]) [90.26.96.4] by mail.gmx.net (mp037) with SMTP; 20 Jun 2007 16:43:56 +0200 X-Authenticated: #276141 X-Provags-ID: V01U2FsdGVkX18k6qBk+7ckYtYqW2zFuzgnGTcp7ZDMtQJiAoIGSW QS9tTsWbGtmKNw Message-ID: <46793D29.9010802@gmx.net> Date: Wed, 20 Jun 2007 16:43:53 +0200 From: Jimmy Jazz User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.8.1.4) Gecko/20070616 Thunderbird/2.0.0.4 Mnenhy/0.7.5.666 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-kernel@gentoo.org Reply-to: gentoo-kernel@lists.gentoo.org MIME-Version: 1.0 To: gentoo-kernel@lists.gentoo.org, spock@gentoo.org, Daniel Drake Subject: Re: [gentoo-kernel] I'm not able to get the vertical bar with gensplash after issuing alt+f1 key during the earlier boot stage References: <45FFB9FC.4000209@gmx.net> <46184BDD.2010708@gentoo.org> <461BA6BE.4090509@gmx.net> <20070411093231.GA26586@spock.one.pl> <465EE88C.7030100@gmx.net> <20070602205002.GC12155@spock.one.pl> <466DBF2C.1040508@gmx.net> <466DC5BC.50505@gentoo.org> <466DDCE2.10903@gmx.net> <466DE410.3040109@gentoo.org> <46753EA8.6060302@gmx.net> <46754BE6.7000608@gentoo.org> In-Reply-To: <46754BE6.7000608@gentoo.org> X-Enigmail-Version: 0.95.1 Content-Type: multipart/mixed; boundary="------------030101090107040406020608" X-Y-GMX-Trusted: 0 X-Archives-Salt: 920d6e73-fdf0-42c8-8ab4-0547cdabaf22 X-Archives-Hash: 0d893f90348992c8cb1220cfb405c1be This is a multi-part message in MIME format. --------------030101090107040406020608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by robin.gentoo.org id l5KEhvvj006289 Daniel Drake a =E9crit : > 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 :) >=20 > 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. >=20 > FYI, baselayout-2 no longer requires bash. >=20 >> 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 :) >=20 > 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 serializ= e > access to any of these resources, resulting in several highly repeatabl= e > failure conditions due to races. >=20 > The original bug report: > https://bugs.gentoo.org/show_bug.cgi?id=3D154670 >=20 > My attempt to fix it: > https://bugs.gentoo.org/show_bug.cgi?id=3D166545 >=20 > However, it turns out my locking implementation can be easily broken an= d > is not race free. >=20 >> 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. >=20 > 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. >=20 > 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=B0Z 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 #include #include 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=3D"$(basename $1)" local pid=3D"$$" #<-- doesn't work if called from the same script local locked=3D"/var/tmp/lock/${keylock}.lck" local locker=3D"/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 --------------030101090107040406020608 Content-Type: application/x-shellscript; name="NameYourCompanyHere.sh" Content-Disposition: inline; filename="NameYourCompanyHere.sh" Content-Transfer-Encoding: base64 IyEvYmluL2Jhc2ggCgpOT1JNQUw9JCdcZVswbScKV0FSTj0kJ1xlWzMzOzFtJwpCQUQ9JCdc ZVszMTsxbScKQk9MRD0kJ1xlWzFtJwpHT09EPSQnXGVbMzI7MW0nCkJMSU5LPSQnXGVbMjVt JwpSRUQ9JCdcZVsxOzMxbScKR1JFRU49JCdcZVsxOzMybScKWUVMTE9XPSQnXGVbMTszM20n CkJMVUU9JCdcZVsxOzM0bScKTUFHRU5UQT0kJ1xlWzE7MzVtJwpDWUFOPSQnXGVbMTszNm0n CldISVRFPSQnXGVbMTszN20nCkJSRUQ9JCdcZVs0MW0nCkJCTFVFPSQnXGVbNDRtJwpCTk9S TUFMPSQnXGVbNDltJwoKbWFnZW50YSgpIHsgZWNobyAtbiAke01BR0VOVEF9JCoke05PUk1B TH07IH0KZ3JlZW4oKSB7IGVjaG8gLW4gJHtHUkVFTn0kKiR7Tk9STUFMfTsgfQpyZWQoKSB7 IGVjaG8gLW4gJHtSRUR9JCoke05PUk1BTH07IH0KeWVsbG93KCkgeyBlY2hvIC1uICR7WUVM TE9XfSQqJHtOT1JNQUx9OyB9CmN5YW4oKSB7IGVjaG8gLW4gJHtDWUFOfSQqJHtOT1JNQUx9 OyB9CndoaXRlKCkgeyBlY2hvIC1uICR7V0hJVEV9JCoke05PUk1BTH07IH0KCm1lbWxvY2tl cigpIHsKICAgICAgICBsb2NhbCBtbnRvcHRzPSJkZWZhdWx0cyxub2F0aW1lLG5vZXhlYyIK CiAgICAgICAgaWYgZ3JlcCAtRXEgIltbOnNwYWNlOl1dK3RtcGZzJCIgL3Byb2MvZmlsZXN5 c3RlbXMgOyB0aGVuCiAgICAgICAgCXRyeSBtb3VudCAtbiAtdCB0bXBmcyAtbyAiJHttbnRv cHRzfSIgdG1wZnMgL3Zhci90bXAvbG9jawogICAgICAgIGZpCn0KCmlzcnVubmluZygpIHsK CWtpbGwgLTAgJDEgCn0KCiMgaGFyZCBsaW5rIGxuKCkgaXMgYXRvbWljIHRvbwppc2xvY2tl ZCgpIHsKCVsgJCMgLWVxIDEgXSB8fCBleGl0IDIKCWxvY2FsIGxvY2tmaWxlPSQxCgoJKCBz ZXQgLUM7IDogPiAke2xvY2tmaWxlfSApICYmIGVjaG8gIkJvbHQgJHtsb2NrZmlsZX0gc3Vj Y2Vzc2Z1bGx5IHNldCIKfQoKIyB0cmlja3kgb3IgdXNlIGEgQyBwcm9ncmFtIHRoYXQgY2Fs bHMgZ2V0cHBpZCgpCgpnZXRwaWQoKSB7CmV4ZWMgYmFzaCA8PC0gRU9GCiAgICAgICAgZWNo byBcJFBQSUQKRU9GCn0KCmZsb2NrKCkgewoJbG9jYWwga2V5bG9jaz0iJChiYXNlbmFtZSAk MSkiCglsb2NhbCBzdGFsZQoJbG9jYWwgbG9ja2VyPSIvdmFyL3RtcC9sb2NrLyR7a2V5bG9j a30ubG9jayIKCWxvY2FsIHBpZD0kKGdldHBpZCkKCglpZiBpc2xvY2tlZCAke2xvY2tlcn07 IHRoZW4KCQllY2hvICR7cGlkfSA+ICR7bG9ja2VyfQoJCWVjaG8gIkxvY2tlciAke2xvY2tl cn0gYmVsb25ncyB0byAke3BpZH0iCgkJcmV0dXJuIDAKCWZpCgoJc3RhbGU9IiQoPCAke2xv Y2tlcn0pIgoKCWlmIFsgLW4gIiR7c3RhbGV9IiBdICYmIFsgJHtzdGFsZX0gLWd0IDAgXTsg dGhlbgoJCWlmIGlzcnVubmluZyAiJHtzdGFsZX0iOyB0aGVuCgkJCXJldHVybiAxCgkJZmkK CgkJcm0gJHtsb2NrZXJ9ICYmIGVjaG8gIlN0YWxlIGxvY2sgZmlsZSBvZiAke3N0YWxlfSBy ZW1vdmVkIgoKCQlpZiBpc2xvY2tlZCAke2xvY2tlcn07IHRoZW4KCQkJZWNobyAke3BpZH0g PiAke2xvY2tlcn0KCQkJZWNobyAiTG9ja2VyICR7bG9ja2VyfSBiZWxvbmdzIHRvICR7cGlk fSIKCQkJcmV0dXJuIDAKCQlmaQoJZmkKCglyZXR1cm4gMQp9Cgpmb3JrKCkgewogICAgICAg IHRyYXAgJycgMSAKICAgICAgICAkQAp9CgpicmFpbnN0b3JtaW5nKCkgewoJc2xlZXAgJDEK fQoKam9iZm9yKCkgewoJbG9jYWwgZGV2PSQxCglsb2NhbCBwcm9qZWN0PSQyCglsb2NhbCB0 aW1lcj0iJCgoICR7UkFORE9NfSAlIDIwKSkiCgl0YXNrPSQoKCAke3Rhc2s6LTB9ICsgMSAp KQoJCgllY2hvICIkKHllbGxvdyAke2Rldn0pIHNheXM6IEknbSBnaXZpbmcgJCh3aGl0ZSAk e3RpbWVyfSlzIG9mIG15IHRpbWUgdG8gdGhlICQoY3lhbiB0YXNrICR7dGFza30pIG9mIHBy b2plY3QgbsKwJChjeWFuICR7cHJvamVjdH0pIgkKCWJyYWluc3Rvcm1pbmcgJHt0aW1lcn0K CgllY2hvICIkKHllbGxvdyAke2Rldn0pIHNheXM6ICQobWFnZW50YSB0YXNrICR7dGFza30p IGZvciBwcm9qZWN0ICQoY3lhbiBuwrAke3Byb2plY3R9KSBkb25lLiIKfQoKaGlyZSgpIHsK CWxvY2FsIG5hbWU9JDEKCWxvY2FsIHByb2plY3Q9JDIKCWxvY2FsIGZlZWQ9IiQoKCAke1JB TkRPTX0gJSAxMCkpIgoJbG9jYWwgY3VycmVuY3k9JyQnCglsb2NhbCBwaWFzdHJlPSR7cGlh c3RyZTotMX0KCgllY2hvICJXZSBuZWVkICQoeWVsbG93ICR7bmFtZX0pIGZvciBwcm9qZWN0 ICQoY3lhbiBuwrAke3Byb2plY3R9KSIKCgl1bnRpbCBmbG9jayAke25hbWV9OyBkbwoJCWVj aG8gIldlIHByb3Bvc2UgJChncmVlbiAke2N1cnJlbmN5fSR7cGlhc3RyZX0pIHRvICQocmVk ICR7bmFtZX0pIGZvciBwcm9qZWN0ICQoY3lhbiBuwrAke3Byb2plY3R9KSIKCQlwaWFzdHJl PSQoKCBwaWFzdHJlICsgZmVlZCApKQoJCXNsZWVwIDEKCWRvbmUKCgllY2hvICIkKHllbGxv dyAke25hbWV9KSBhY2NlcHRzIHByb2plY3QgbsKwJChjeWFuICR7cHJvamVjdH0pIGZvciAk KGdyZWVuICR7Y3VycmVuY3l9JHtwaWFzdHJlfSkiCglqb2Jmb3IgJHtuYW1lfSAke3Byb2pl Y3R9CgoJZWNobyAiVGFzayBkb25lOiBsb2NrIGZpbGUgZnJvbSAkKHJlZCAke25hbWV9KSBy ZW1vdmVkIgoJcm0gLWYgL3Zhci90bXAvbG9jay8ke25hbWV9LmxvY2sKCglyZXR1cm4gMAp9 CgpkZWNsYXJlIC1hIGdyb3VwCmdyb3VwWzFdPSJTdXNpZSBDYXZpbiBHZW9yZ2UiCmdyb3Vw WzJdPSJTdXNpZSBKb2UgQXJub2xkIEdlcmFsZCBTdXNpZSIKZ3JvdXBbM109IkNhdmluIEhv YmJlcyBKb2UiCmdyb3VwWzRdPSJDYXZpbiBIb2JiZXMgR2VyYWxkIgpncm91cFs0XT0iQ2Fs bHkgSm9lIEFybm9sZCBHZXJhbGQgTWFyY2llIgojZ3JvdXBbNV09IkppbW15IEpvZSBNYXJj aWUgQ2hhcmxpZSBDYWxseSIKI2dyb3VwWzZdPSJBbm5hIEppbW15IEFybm9sZCBXb29kc3Rv Y2sgQW5uYSIKI2dyb3VwWzddPSJDaGFybGllIEpvZSBUZXJlbmNlLUhpbGwgQ2h1Y2sgU25v b3B5IgojZ3JvdXBbOF09IkFubmEgUGVwcGVybWludC5QYXRpIEFybm9sZCBCdXR0LVNwZW5j ZXIgTWFyY2llIgojZ3JvdXBbOV09IkNodWNrIFNub29weSBBcm5vbGQgVHJ1ZmZlbCBQZXBw ZXJtaW50LlBhdGkiCgptZW1iZXJvZigpIHsKCWVjaG8gIiR7Z3JvdXBbJDFdfSIKfQoKd29y a2dyb3VwKCkgewoJbG9jYWwgcHJvamVjdD0kMQoJbG9jYWwgdGVhbT0kKG1lbWJlcm9mICR7 cHJvamVjdH0pCgoJc2V0IC0tICR7dGVhbX0KCWxvY2FsIHRhc2tzPSQjCgoJZWNobyAiV2Ug aGF2ZSAkKHJlZCAke3Rhc2tzfSB0YXNrcykgZm9yIHByb2plY3QgJChjeWFuIG7CsCR7cHJv amVjdH0pIgoKIwl3aGlsZSBbICR7dGFza3N9IC1ndCAwIF07IGRvCglmb3IgZGV2ZWxvcGVy IGluICR7dGVhbX07IGRvCgkJaGlyZSAke2RldmVsb3Blcn0gJHtwcm9qZWN0fSAKCQlpZiBb ICQ/IC1lcSAwIF07IHRoZW4KCQkJdGFza3M9JCgodGFza3MgLSAxKSkKCQkJZWNobyAiSXQg cmVtYWlucyAkKHJlZCAke3Rhc2tzfSB0YXNrcykgZm9yIHByb2plY3QgJChjeWFuIG7CsCR7 cHJvamVjdH0pIgoJCWVsc2UgCgkJCWVjaG8gIiR7ZGV2ZWxvcGVyfSB3YXMgbm90IGhpcmVk IGZvciBwcm9qZWN0ICQoY3lhbiBuwrAke3Byb2plY3R9KSIKCQlmaQoJZG9uZQojCWRvbmUK fQoKIyBldmVyeSBtYW5hZ2VyIHdhbnRzIGEgZGV2ZWxvcGVyIGZvciBoaXMgcHJvamVjdC4g CiMgZm9yIGEgcHJvamVjdCB0aGUgZGV2ZWxvcGVycyBhcmUgb3JkZXJlZC4KbWFpbigpIHsK CWxvY2FsIHByb2plY3RzPSQoZXZhbCBlY2hvIHsxLi4keyNncm91cFsqXX19KQoJbG9jYWwg dHJhcHM9JCh0cmFwKQoKCWVjaG8gIlBhcmVudCBwcm9jZXNzIGlkOiAkJCIKCgllY2hvICJX ZSBoYXZlICQocmVkICR7I2dyb3VwWypdfSkgdGVhbXMgdG8gbWFuYWdlIgoKCWZvciBwcm9q ZWN0IGluICR7cHJvamVjdHN9OyBkbwoJCXRyYXAgJ2VjaG8gIiQocmVkIEluZ29yZSBDdHJs LUMpIicgMgoKCQlmb3JrIHdvcmtncm91cCAke3Byb2plY3R9ICYgZWNobyAiSm9iIHN0YXJ0 ZWQgJChkYXRlKSBhcyBwaWQ9JCEiIAoJCWNoaWxkcmVuPSIke2NoaWxkcmVufSAkISIKCgkJ ZXZhbCAiJHt0cmFwc30iCgoJCWVjaG8gIlByb2plY3QgbsKwJChjeWFuICR7cHJvamVjdH0p IG5lZWRzIHJlc291cmNlcyAuLi4iCglkb25lCgoKCXdhaXQgJiYgdW5zZXQgY2hpbGRyZW4K CgllY2hvICJDb25ncmF0dWxhdGlvbiwgYWxsIHRoZSBwcm9qZWN0cyB3ZXJlIGRvbmUgaW4g dGltZS4iCn0KCl9leGl0KCkgewoKCWVjaG8gIlRoZSBjb21wYWdueSAkMCBmaW5hbGx5IGdl dCBiYW5rcnVwdCBhbmQgZmlyZWQgdGhlaXIgdHJ1c3R5IGRldmVsb3BlcnMiCgoJZm9yIGNo aWxkIGluICR7Y2hpbGRyZW59OyBkbwogICAgICAgICAgICAgICAJbG9jYWwgZm91bmQ9bm8K CgkJZm9yIGRldmVsb3BlciBpbiAke2dyb3VwWypdfTsgZG8KCSAgICAgICAgICAgICAgIFsg LWUgL3Zhci90bXAvbG9jay8ke2RldmVsb3Blcn0ubG9jayBdIHx8IGNvbnRpbnVlCgogICAg ICAgICAgICAgICAgCXBpZD0kKDwgL3Zhci90bXAvbG9jay8ke2RldmVsb3Blcn0ubG9jaykK CiAgICAgICAgICAgICAgICAgICAgICAgIGlmIFsgIiR7cGlkfSIgPT0gIiR7Y2hpbGR9IiBd OyB0aGVuCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm91bmQ9eWVzCgoJCQkJ a2lsbCAtcyAxNSAke2NoaWxkfSAmJiB7CgkJCQkJZWNobyAiJCh5ZWxsb3cgJHtkZXZlbG9w ZXJ9IG7CsCR7Y2hpbGR9KSB3YXMgc3VjY2VzZnVsbHkgZmlyZWQiCgkJCQl9CgoJCQkJcm0g LWYgL3Zhci90bXAvbG9jay8ke2RldmVsb3Blcn0ubG9jawoKCQkJCWJyZWFrCiAgICAgICAg ICAgICAgICAgICAgICAgIGZpCgkJZG9uZQoJCQoJCVsgIiR7Zm91bmR9IiA9PSAneWVzJyBd ICYmIGNvbnRpbnVlCgoJCWVjaG8gIiQocmVkIGVycm9yIG7CsCR7Y2hpbGR9KSBoYXMgbm8g YXNzb2NpYXRpb24iCgkJa2lsbCAtcyAxNSAke2NoaWxkfSAmJiBlY2hvICIkKHJlZCBub2Jv ZHkgbsKwJHtjaGlsZH0pIHdhcyBmaXJlZCIKCWRvbmUgMj4vZGV2L251bGwKCglmb3IgZGV2 ZWxvcGVyIGluICR7Z3JvdXBbKl19OyBkbwoJCVsgLWUgL3Zhci90bXAvbG9jay8ke2RldmVs b3Blcn0ubG9jayBdIHx8IGNvbnRpbnVlCgkJZWNobyAiJChyZWQgZXJyb3IpICR7ZGV2ZWxv cGVyfSBsb2NrZXIgc3RpbGwgZXhpc3QiCglkb25lCn0KCmNoaWxkaGFzZmluaXNoZWQoKSB7 CgllY2hvICJDYXVnaHQgc2lnbmFsIFNJR0NITEQgaW4gJDAiCn0KCgpbICQjIC1lcSAxIF0g fHwgZXhpdCAyCgp0cmFwIF9leGl0IEVYSVQKCnRyYXAgJ2NoaWxkaGFzZmluaXNoZWQnIFNJ R0NITEQKCm1haW4gIiQxIgoKZXhpdCAkPwo= --------------030101090107040406020608-- -- gentoo-kernel@gentoo.org mailing list