[07:53] <twb> Does anyone know the status of upstart on Sid?
[07:54] <twb> Rather, what is the status of upstart on Sid?
[10:54] <JK456> hi upstarters :)
[10:54] <JK456> i dont get how i can use the respawn system :
[10:55] <JK456> when i use it on a soft who forks, upstart dont see the son
[10:55] <JK456> and think the soft is dead, and respawn it
[10:56] <twb> I am not a regular here, but I believe the upstart position is that daemons that fork into the background are broken.
[10:56] <twb> What package are you having problems with?
[10:56] <JK456> some soft we wrote ourself
[10:56] <JK456> its a quite personalized system
[10:57] <JK456> but for exemple portmap daemon
[10:57] <JK456> it forks after launch
[10:57] <twb> Are you sure about that?
[10:57] <JK456> well i am gona check again
[10:58] <twb> I think upstart would say that portmap should be run with -d to prevent it disconnecting.
[10:59] <JK456> portmap forks, or if it doesn't it is restarted for no reason
[11:00] <JK456> -d ?
[11:00] <JK456> is it an upstart option ?
[11:00] <twb> Oh sorry, -f is more appropriate.
[11:00] <twb> See the portmap manual.
[11:00] <twb> "-f      (foreground) prevents portmap from running as a daemon, and causes log messages to be printed to the standard error output."
[11:01] <JK456> ok, its an option of portmap
[11:01] <twb> As I said, I am not associated with upstart.
[11:01] <twb> But I think they would advise you to add such an option to your program, too.
[11:01] <JK456> but it implies to modifie the code of all daemon in our system :s ^^
[11:02] <JK456> but your informations are very usefull :)
[11:02] <JK456> thanks a lot
[11:02] <ion_> One needs to add the daemon stanza to the job definition, but handling forking daemons isnt completely implemented yet.
[11:02] <twb> I'm afraid I can't help more; if you wait long enough a regular will stop by.
[11:02] <JK456> yep, i had the chance to talk them sometimes, freenode is great for that
[11:04] <ion_> The sole reason why Upstart needs to be pid 1 is that it can support forking daemons. Theres no upstart position that forking daemons are broken AFAIK.
[11:04] <twb> I apologize, I was clearly mistaken.
[11:05] <twb> Perhaps I am thinking of the cinit people
[11:05] <JK456> ion_ : oh ? how does it work ?
[11:06] <JK456> twb : no prob
[11:06] <twb> Does upstart on ubuntu still just call out to sysvinit compat for just about everything except inittab?
[11:07] <ion_> Pid 1 receives the SIGCHLD for parentless processes. But handling it isnt implemented yet AFAIK.
[11:07] <ion_> twb: The sysvinit scripts havent been replaced with upstart jobs yet.
[11:08] <twb> Doesn't that mostly take away the real benefit of using upstart for regular users?
[11:09] <JK456> ion_ : if i understand well, i will be possible to restart forking daemon, but it is not yet possible ?
[11:10] <ion_> jk456: Yes, thats the current situation as far as i know.
[11:11] <ion_> twb: I dont see what you mean. The scripts will be converted to upstart gradually.
[11:12] <twb> I mean that the real appeal of upstart (at least to me) is reduced boot time as a result of aynchronous service startup.  If upstart currently just uses run-parts to launch everything in rcS.d and rcN.d, then none of those scripts will be launched asynchronously.
[11:12] <JK456> ok, and i guess it is not possible to use inittab respawn because there is only one process (the 1) receiving sigchild
[11:15] <ion_> twb: I think the major point of upstart is a flexible bootup process that Just Works where sysvinit scripts would fail unless horrible kluges are added to them. Reduced boot time is just a bonus.
[11:17] <twb> In what way does it "Just Work" more than sysvinit?
[11:17] <twb> I mean, *right now* as opposed to after sysvinit scripts have been completely replaced
[11:18] <JK456> twb : if you seek for speed, you can test initng
[11:18] <twb> That's the gentoo thing?
[11:18] <JK456> initng ?
[11:19] <ion_> Right now the system is booted by the sysvinit scripts.
[11:19] <JK456> initng : no i dont think i is for a specific distrib
[11:19] <twb> But it's pioneered on gentoo, in the same way that upstart is on Ubuntu?
[11:20] <JK456> dont knwo, there is rpm and packages for lots of distrib 
[11:21] <JK456> ion_ : in my case, we builded a personalized init, we had 23 seconds at boot, we are at 5
[11:21] <twb> "built"
[11:21] <twb> ion_: I like their icon better than upstarts :P
[11:22] <JK456> (in init phase, there is also 15 seconds for hardware loading)
[11:22] <JK456> twb : but there is less features in initng
[11:23] <JK456> _ion : so thanks to upstart we won 18 seconds
[11:23] <JK456> (its linux embedded soft)
[11:25] <JK456> twb : why dont you write your own scripts ?
[11:26] <JK456> it is not so so hard to do
[11:26] <JK456>     `-- rcS
[11:26] <JK456>         |-- S02mountvirtfs
[11:26] <JK456>         |-- S10checkroot.sh
[11:26] <JK456>         |-- S30checkfs.sh
[11:26] <JK456>         |-- S39ifupdown
[11:26] <JK456>         |   `-- S40networking
[11:26] <JK456>         |-- S40hostname.sh
[11:26] <twb> Yes, it is.
[11:26] <JK456>         `-- S55urandom 
[11:27] <twb> It is hard because I don't have millions of other Debian users helping me debug them.
[11:27] <JK456> on mountvirtfs, you launch the runlevel you want
[11:27] <JK456>     |-- rc3
[11:27] <JK456>     |   |-- S00set-date
[11:27] <JK456>     |   |-- S02engine
[11:27] <JK456>     |   |-- S05sysfs
[11:27] <JK456>     |   |   `-- S06udev
[11:27] <JK456>     |   |-- S11messagebus
[11:27] <JK456>     |   |-- S65xinetd
[11:27] <JK456>     |   `-- S70lircd
[11:28] <JK456> thats the init profile we use (i removed the confidential parts)
[11:28] <JK456> twb : you just have to call the scripts in rcS.d and rcX.d
[11:29] <JK456> this scipts will do the job
[11:31] <JK456> so all your files in event.d will look like to this :
[11:31] <JK456> description     "test"
[11:31] <JK456> author          "jerry"
[11:31] <JK456> start on stopped mountvfs
[11:31] <JK456> console output
[11:31] <JK456> script
[11:31] <JK456> 	echo "portmap"
[11:31] <JK456>  	exec /etc/rc.d/rcS.d/S41portmap start
[11:31] <JK456> 	echo "done"
[11:31] <JK456> end script
[11:31] <twb> Please stop flooding.
[11:32] <JK456> ^^ k
[11:32] <JK456> hope it helps
[12:00] <twb> Ew, bootchart-view is written in Java.
[12:06] <twb> ion_: have you looked at using LSB headers to programmatically convert sysv init scripts to upstart scripts?
[12:08] <ion_> Is there a LSB header for things like start when network is available, start when all partitions are mounted and writable, start when a sound card has been connected? If not, doing the conversion manually will yield much better results.
[12:09] <twb> Yes.
[12:10] <JK456> i agree too
[12:10] <twb> I concede that it won't be perfect, but I wonder if it can save you a lot of grunt work, allowing you to focus on the second 90%
[12:11] <JK456> twb : we wrote it in a day 
[12:11] <JK456> the main part is to kwow the dependencies
[12:11] <JK456> after that you just call the sys scripts
[12:12] <JK456> or you copy them
[12:12] <twb> http://user.skolelinux.no/~pere/mypapers/200706-bootseq/200706-bootseq.html
[12:12] <ion_> Upstart doesnt exactly deal with dependencies, its the other way around.
[01:38] <julo> hi
[01:39] <julo> I have created an upstart script and it fails to start automatically: "unable to read: Invalid argument", but if I manually start it, it works well.
[01:39] <julo> Any idea ?
[02:10] <julo> salut
[02:10] <julo> j'ai un problme avec upstart: j'ai cr un script, et  l'amorage du  j'obtiens l'erreur "unable to read: Invalid argument" au lancement du script. Par contre, si je lance ce script  la main, a marche.