| djszapi | jodh: ping | 13:44 |
|---|---|---|
| jodh | djszapi: hello | 13:44 |
| djszapi | jodh: I am not getting my upstart job logged | 13:45 |
| djszapi | there is certainly issues with it and I have used console log | 13:45 |
| djszapi | but there is no /var/log/upstart/foobar.log entry. | 13:45 |
| jodh | does the directory /var/log/upstart/ exist? | 13:46 |
| djszapi | I do not see anything related: http://paste.kde.org/459902/ this is my upstart job: http://paste.kde.org/459908/ | 13:46 |
| djszapi | nope | 13:46 |
| djszapi | it does not exist | 13:46 |
| djszapi | on this pandaboard | 13:46 |
| djszapi | upstart 1.3-0ubuntu12~linaro2 | 13:46 |
| jodh | djszapi: http://upstart.ubuntu.com/cookbook/#stanzas-by-category | 13:47 |
| jodh | djszapi: console log didn't get introduced until 1.4. | 13:47 |
| djszapi | by default or altogether ? | 13:48 |
| jodh | djszapi: if you run "init-checkconf foo.conf" you should get a msg about invalid stanza as "console log" won't be understood. | 13:48 |
| jodh | djszapi: the feature was added in Upstart 1.4 and you are running Upstart 1.3 | 13:48 |
| djszapi | init-checkconf cannot be run as root | 13:49 |
| djszapi | and I am not supposed to have another user for this. | 13:49 |
| djszapi | at any rate, I trust you. | 13:49 |
| djszapi | jodh: shall I use console output ? | 13:50 |
| djszapi | and 2>&1 ? | 13:50 |
| jodh | djszapi: I suggest you read http://upstart.ubuntu.com/cookbook/#debugging | 13:51 |
| jodh | djszapi: it's all in there | 13:51 |
| jodh | djszapi: correct - init-checkconf runs as a normal user. | 13:52 |
| djszapi | jodh: what is wrong about this: http://upstart.ubuntu.com/cookbook/#console-output | 13:52 |
| jodh | djszapi: nothing - there are many options. It's your decision :) | 13:52 |
| djszapi | jodh: what do you recommend ? | 13:52 |
| djszapi | there is some operational issues with my binary | 13:52 |
| djszapi | it works if I run manually. | 13:52 |
| djszapi | but it does not function if it is run by upstart | 13:52 |
| djszapi | the binary is running and all that jazz, but no proper effect on the functionality. | 13:53 |
| djszapi | it opens a serial port, and begins to listen to that | 13:53 |
| jodh | djszapi: I'd recommend reading http://upstart.ubuntu.com/cookbook/#debugging then. | 13:53 |
| djszapi | and if there is a data, it parses. | 13:53 |
| djszapi | and act accordingly, that is all. What I now see, it does not act as expected. | 13:53 |
| djszapi | so needs to be debugged. | 13:53 |
| jodh | yes - see also http://upstart.ubuntu.com/cookbook/#debugging-a-script-which-appears-to-be-behaving-oddly | 13:54 |
| jodh | which might be the answer in your case. You'll just have to try it. | 13:54 |
| djszapi | that is a complete no go | 13:54 |
| djszapi | I would like to separate the logging out for my stuff | 13:54 |
| djszapi | I would not like to grep in a bunch of stuff | 13:54 |
| djszapi | and that is what console output is for, afterwards. | 13:56 |
| jodh | I think you have misunderstood - the 'grep' is an example in the section above. *You* don't need to grep, you need to test your script with '/bin/sh -e'. | 13:56 |
| djszapi | I do not understand | 13:57 |
| djszapi | Please note that I do not use script | 13:58 |
| djszapi | and there is no "failing" either. | 13:58 |
| djszapi | what I would actually like to get, is a 2>&1 like operation, and console output seems to be designed for that. | 13:58 |
| djszapi | as in: exec /usr/bin/foobar-commandline receive > /var/log/foobar.log 2>&1 | 13:59 |
| jodh | djszapi: you can do exactly that if you want to. | 14:00 |
| djszapi | what happend with Scott ? | 14:01 |
| djszapi | one or two years ago I had the discussions with him. | 14:01 |
| djszapi | he stepped down as the upstart maintainer ? | 14:01 |
| jodh | yes - he is now working at Google. | 14:04 |
| djszapi | I know that, but I did not know he stepped down from the upstart maintenance. | 14:04 |
| djszapi | interesting, after the launch: stop foobar; start foobar and the "foobar" binary works just fine... | 14:06 |
| djszapi | what is the difference ? | 14:06 |
| djszapi | the serialport is opened by that process after the launch, so I do not really understand. | 14:07 |
| djszapi | jodh: is the serialport available for writing for such a job ? | 14:08 |
| djszapi | jodh: the modem is not set up on the serial port :( | 14:23 |
| djszapi | while the upstart job is running, just later. | 14:23 |
| djszapi | how can that be ? | 14:23 |
| djszapi | since the modem does not respond to the commands that time I send out. | 14:24 |
| djszapi | so I guess the modem is not set up, but why ? | 14:24 |
| djszapi | I had the impression "start on runlevel [23]" should be just fine | 14:24 |
| djszapi | jodh: what should trigger the start of my job instead of the initlevel thingie ? | 14:35 |
| jodh | djszapi: you should probably add 'and X-device-added a=b c=d' for the modem device. See http://upstart.ubuntu.com/cookbook/#upstart-udev-bridge, upstart-events(7) and upstart-udev-bridge(8). | 14:42 |
| djszapi | jodh: I have honestly no ideas about the subsystem :/ | 14:46 |
| jodh | djszapi: what device does your app open? /dev/ttyS0? | 14:46 |
| djszapi | /dev/ttyUSB0 | 14:47 |
| djszapi | PL2303 (usb-serial converter) | 14:47 |
| djszapi | jodh: http://paste.kde.org/459968/ | 14:48 |
| djszapi | perhaps usbdev ? | 14:48 |
| jodh | so, have your job 'start on tty-device-added DEVPATH=*ttyUSB0' | 14:49 |
| djszapi | E: SUBSYSTEM=tty | 14:49 |
| djszapi | udevadm info --export-db | grep -B 2 -A 2 /dev/ttyUSB0 | 14:49 |
| djszapi | from this output | 14:49 |
| djszapi | this one then ? start on (tty-device-added) | 14:51 |
| djszapi | stop on (tty-device-removed) | 14:51 |
| djszapi | hmm, the documentation does not mention the DEVPATH | 14:51 |
| djszapi | just inside the log, but not for the "start/stop" lines. | 14:52 |
| jodh | I've given you the answer above. I'm guessing you either don't have your usb device plugged in or you didn't run udevadm as root? | 14:52 |
| djszapi | well, the documentation does not mention any DEVPATH examples. | 14:53 |
| djszapi | the documentation only speaks about the log wrt those. | 14:53 |
| jodh | ? | 14:53 |
| djszapi | show me the documentation example for the DEVPATH usage. | 14:54 |
| djszapi | these are the examples: start on (graphics-device-added or drm-device-added) | 14:55 |
| djszapi | start on (graphics-device-added or drm-device-added) | 14:55 |
| djszapi | 1) Both contain brakcets | 14:55 |
| djszapi | brackets* | 14:56 |
| djszapi | 2) None of the presents the usage of DEVPATH | 14:56 |
| djszapi | jodh: did not help | 14:57 |
| jodh | djszapi: what did not help? Please be specific. | 14:58 |
| djszapi | jodh: http://paste.kde.org/459974/ | 14:59 |
| djszapi | what I told above | 14:59 |
| djszapi | same symptom | 14:59 |
| djszapi | the modem was not able to reply to the message sent out while running the relevant binary from the upstart job. | 14:59 |
| jodh | djszapi: I suggest you (1) comment out the 'stop on' and make the job 'start onrunlevel [23] and tty-device-added DEVPATH=*ttyUSB0'. | 15:01 |
| jodh | djszapi: also, comment out respawn. | 15:02 |
| djszapi | init-checkconf /etc/init/piruag.conf | 15:02 |
| djszapi | ERROR: failed to ask Upstart to check conf file | 15:02 |
| djszapi | respawm is very important | 15:02 |
| jodh | djszapi: do this before running init-checkconf as presumably you're running on a console: eval `dbus-launch --auto-syntax` | 15:05 |
| djszapi | jodh: I am now having only two lines: 1) start onrunlevel [23] and tty-device-added DEVPATH=*ttyUSB0 2) exec /usr/bin/foobar-commandline receive | 15:05 |
| jodh | djszapi: ...? | 15:06 |
| djszapi | File /etc/init/foobar.conf: syntax ok | 15:06 |
| djszapi | jodh: what is not clear ? | 15:06 |
| jodh | djszapi: so what happens now? does the job work with the 2 lines or not? | 15:07 |
| djszapi | testing | 15:08 |
| djszapi | jodh: I think the point is not ttyUSB0 | 15:09 |
| djszapi | jodh: IMO, the point is that this specific modem is set up at that time. | 15:09 |
| djszapi | if they are the same, then ok. | 15:09 |
| djszapi | jodh: that way, it does not even run after the bootup | 15:11 |
| djszapi | probably no space between on and runlevel | 15:11 |
| djszapi | and I have just copied and pasted your line. :-) | 15:11 |
| djszapi | jodh: that line actually broke the initscripts | 15:17 |
| djszapi | even ssh does not work from outside anymore :( | 15:17 |
| djszapi | jodh: get it back, sorry but no ... my binary does not even run anymore with that "start on runlevel..." etc line | 15:18 |
| djszapi | are you sure brackets are not needed or other quirk ? | 15:19 |
| jodh | djszapi: init-checkconf will tell you if the file is valid. | 15:22 |
| djszapi | jodh: at any rate, the binary is not even started this way | 15:23 |
| djszapi | any ideas ? | 15:23 |
| djszapi | too bad upstart is this hard to use :/ | 15:25 |
| jodh | if your app isn't setting the modem, sounds like you need to find out what is. If it is being configured by an Upstart job, you can make your job 'start on stopped <thing>' since at that stage the modem will presumably be configured. If it's being done by a sysv script, then 'start on stopped rc'. | 15:34 |
| djszapi | I have no clue what you are talking about. | 15:35 |
| djszapi | my application does configure the modem, but it should obviously available for commands. As for me, upstart seems to be either broken or quite undocumented. | 15:36 |
| jodh | djszapi: it is neither. | 15:38 |
| djszapi | well, it does not work | 15:38 |
| djszapi | and I do not find in the documentation either how it is supposed to work either. | 15:38 |
| djszapi | as for me, it is time consuming either way as a "customer". | 15:39 |
| djszapi | script echo "`env`" > /dev/.initramfs/job-A.log | 15:40 |
| djszapi | end script | 15:40 |
| djszapi | this logged nothing, so even this part of the documentation is hilariously broken | 15:40 |
| jodh | djszapi: incorrect - that tells you the either you have a corrupt .conf file (your paste is incorrect in that 'echo' should be on the line below), or your job never started. | 15:41 |
| jodh | djszapi: have you tried "start <job>" on a booted system maybe? do you get a log file then? | 15:42 |
| djszapi | no log, no | 15:44 |
| djszapi | even after start stuff | 15:44 |
| djszapi | jodh: ^ | 15:45 |
| djszapi | start on (runlevel [23] and tty-device-added DEVPATH=*ttyUSB0) | 15:45 |
| djszapi | script echo "`env`" > /dev/.initramfs/job-A.log | 15:45 |
| djszapi | end script | 15:45 |
| djszapi | exec /usr/bin/... | 15:45 |
| jodh | djszapi: as stated above, that is incorrect syntax: the first 'script' should be on a line on it's own, as shown in the cookbook and as documented in init(5). | 15:47 |
| djszapi | no | 15:47 |
| djszapi | documentation shows this: start on (graphics-device-added or drm-device-added) | 15:47 |
| djszapi | script echo "`env`" > /dev/.initramfs/job-A.log | 15:47 |
| djszapi | end script | 15:47 |
| djszapi | have you actually checked the documentation ? | 15:47 |
| djszapi | also: init-checkconf /etc/init/piruag.conf | 15:48 |
| djszapi | File /etc/init/piruag.conf: syntax ok | 15:48 |
| djszapi | s/piruag/foobar/ | 15:48 |
| jodh | djszapi: what you have pasted above is therefore *not* what is in piruag.conf as it is invalid. the cookbook is correct. Maybe your web-browser is mis-rendering it. It views perfectly for me in ff and chromium. | 15:50 |
| djszapi | huh ? | 15:50 |
| djszapi | your irc client is wrong then | 15:51 |
| djszapi | since it was a simple copy/paste | 15:51 |
| djszapi | please do not argue about useless things | 15:51 |
| djszapi | let us just nicely proceed | 15:51 |
| djszapi | I would not like to spend yet another few hours with upstart to run a simply binary lol | 15:51 |
| djszapi | once tty is set up properly. | 15:51 |
| djszapi | s/simply/simple/ | 15:52 |
| djszapi | I do not understand why this hard to use an initiscript. | 15:52 |
| djszapi | this is a perfectly valid syntax made according to the documentation (TM): http://paste.kde.org/459992/ | 15:53 |
| jodh | djszapi: right - your problem is that you've specified both a 'script' section and an 'exec'. That's not valid, or rather the last valid entry will be selected (the exec), hence you won't get a log. | 15:58 |
| djszapi | init check returns /valid/ | 15:58 |
| djszapi | fix the check. | 15:58 |
| jodh | djszapi: put the call to /usr/bin/foobar-commandline at the end of the script section and comment out the exec section. | 15:58 |
| jodh | djszapi: it's valid, but not what you want. | 15:59 |
| djszapi | what is the point of upstart if it is this hard to run a binary once the serial port is set up ? | 15:59 |
| jodh | it isn't hard - you just need to read the documentation. If the documentation is unclear or needs more examples, please raise bugs so we can rectify the situation. | 16:00 |
| djszapi | well, you did not even provide any working solution so far | 16:00 |
| djszapi | so it seems to be even hard for you. | 16:00 |
| djszapi | so what can I say as a newcomer... | 16:01 |
| jodh | djszapi: I don't have a modem and I didn't write your application :) | 16:01 |
| djszapi | it has nothing to do with my application | 16:01 |
| djszapi | it expects a modem set up | 16:01 |
| djszapi | which is obviously a sane thing if you wanna configure it .... | 16:01 |
| djszapi | http://paste.kde.org/460028/ -> this is the env | 16:02 |
| djszapi | quite poor from what I can say. | 16:02 |
| djszapi | anyway, I have no clues... | 16:03 |
| djszapi | any help is welcome... | 16:03 |
| djszapi | otherwise I need to admit it is incredibly hard from upstart, and not worth spending the time with. | 16:03 |
| jodh | djszapi: so your application runs correctly from the command-line on a booted system? | 16:04 |
| djszapi | like I said in the very beginnig, of course... | 16:04 |
| djszapi | even from upstart ... | 16:04 |
| djszapi | not during the boot, but I said it many times really :) | 16:04 |
| djszapi | so clearly, the modem is not up and running | 16:04 |
| djszapi | and still, the last line I got for the "start on ..." is broken | 16:05 |
| djszapi | the binary is not even executed anymore | 16:05 |
| djszapi | jodh: ^ | 16:07 |
| SpamapS | djszapi: what release of Ubuntu are you on? | 16:18 |
| djszapi | upstart 1.13 | 16:19 |
| djszapi | (like I said in the beginning) | 16:19 |
| djszapi | why should the ubuntu version matter ? | 16:19 |
| SpamapS | djszapi: I wasn't here in the beginning. Please try to be a bit more polite. | 16:19 |
| SpamapS | djszapi: There is no such thing as 1.13 | 16:20 |
| djszapi | weird, I see you were online. | 16:20 |
| djszapi | of course there is. | 16:20 |
| SpamapS | 1.5 is the newest release of upstart | 16:20 |
| djszapi | 1.3-0ubuntu12~linaro2 | 16:20 |
| djszapi | yes, 1.3 | 16:20 |
| SpamapS | Ok, 1.3 not 1.13 :) | 16:20 |
| djszapi | it drives me crazy :/ | 16:21 |
| SpamapS | djszapi: so if you add this to your exec line, you can get the error messages from your command logged to syslog: | 16:21 |
| SpamapS | 2>&1 | logger -t pickatag | 16:21 |
| djszapi | that is not gonna work without console log IIRC | 16:21 |
| djszapi | console output | 16:21 |
| SpamapS | djszapi: you may also want to increase the log priority to 'info' so that you can see upstart events being processed. 'initctl log-priority info' | 16:21 |
| SpamapS | djszapi: you don't have syslogging? | 16:22 |
| SpamapS | djszapi: ok, change that to this then: | 16:22 |
| djszapi | I do have syslog | 16:22 |
| djszapi | but I would rather prefer a dedicated log just for this. | 16:22 |
| SpamapS | >> /run/mylog.log 2> /run/myerr.log | 16:22 |
| djszapi | -> /run ? | 16:23 |
| djszapi | you mean /var/log/ ? | 16:23 |
| SpamapS | choose whatever you want | 16:23 |
| djszapi | -> /run does not really fit the lfsh | 16:23 |
| SpamapS | ok, you get the idea. | 16:24 |
| djszapi | http://paste.kde.org/460052/ | 16:25 |
| SpamapS | djszapi: yeah that should work | 16:27 |
| djszapi | ok, it does not | 16:27 |
| djszapi | like I said before | 16:27 |
| djszapi | especially because console output is not there. | 16:28 |
| djszapi | and even if I was putting there, I would have the same information, I already do have. | 16:28 |
| djszapi | the modem does not respond. | 16:28 |
| djszapi | most likely because it is not set up | 16:28 |
| djszapi | so I do not understand what addition we would gain in here. | 16:28 |
| djszapi | Any ideas pushing the topic forward ? | 16:28 |
| djszapi | what I need is not the logging of my application, I already know where it fails. | 16:29 |
| djszapi | I would need to know what to trigger the application for. | 16:29 |
| djszapi | the documentation does not just work, period. | 16:29 |
| djszapi | nor the aforementioned ideas. | 16:29 |
| djszapi | I do not understand why one needs to spend many hours to run a binary once the serial port and the modem in there are ready. :/ | 16:30 |
| djszapi | it should be this simple: I would like to run my daemon once the system is fully set up: ok, use this. | 16:30 |
| djszapi | should be just one option. | 16:30 |
| SpamapS | djszapi: where does it fail then? | 16:32 |
| djszapi | huh ? | 16:32 |
| SpamapS | djszapi: is there hardware missing? | 16:32 |
| djszapi | have you actually read what I wrote ? :-) | 16:32 |
| SpamapS | djszapi: sounds like the device added event is emitted by udev too soon. | 16:32 |
| djszapi | sorry, but really getting frustrated. I would not like to spend /enormous/ amount of time to run a binary once the system is fully set up. | 16:33 |
| SpamapS | djszapi: I'm done. Good luck with upstart. You will get no help until you can be nice. | 16:33 |
| djszapi | you have not clearly read what I wrote. | 16:33 |
| djszapi | I wrote that the modem does not respond back then while trying to configure it. | 16:33 |
| SpamapS | Ok, I typed that while you said sorry. | 16:33 |
| SpamapS | djszapi: so that tells me that you need an event for when the modem is ready, not when the serial port is added | 16:34 |
| djszapi | I would need a common event which tells the system is up! | 16:34 |
| djszapi | now you can run anything. | 16:34 |
| djszapi | everything is set up. | 16:34 |
| SpamapS | "system is up" is hard to define. | 16:34 |
| djszapi | I do not care about low-level stuff, like a certain specific device is run | 16:34 |
| SpamapS | mobile systems have resources that come and go. | 16:34 |
| djszapi | with the certain specific vendor and so on ids. | 16:35 |
| djszapi | this is quite low-level. | 16:35 |
| djszapi | super low-level | 16:35 |
| djszapi | "system is set up" -> done | 16:35 |
| djszapi | run the binary | 16:35 |
| djszapi | what is so hard about it ? | 16:35 |
| SpamapS | runlevel 2 should be that the system is ready to run anything statically onfigurable | 16:35 |
| SpamapS | configurable rather | 16:35 |
| djszapi | like I said, runlevel 2 did not work. | 16:36 |
| djszapi | getting no replies from the modem | 16:36 |
| SpamapS | Right, so there is something not-static that you are dependent on. | 16:36 |
| djszapi | meanwhile if I make a stop myjob; start myjob, I do get replies | 16:36 |
| djszapi | either an "OK" or an "ERROR". | 16:36 |
| SpamapS | djszapi: perhaps try 'stopped udevtrigger and runlevel [23]' | 16:36 |
| djszapi | it is quite static, trust me :) | 16:36 |
| SpamapS | djszapi: udevtrigger will flush all events that the kernel knows about at system boot. | 16:37 |
| djszapi | I am not sure udevtrigger stopping check is a good point for that. | 16:37 |
| djszapi | Like I wrote: "start on (runlevel [23] and tty-device-added DEVPATH=*ttyUSB0)" does not even run the binary anymore | 16:37 |
| djszapi | so it is already a broken check. | 16:37 |
| djszapi | extending a broken check... I do not expect anything working. | 16:38 |
| djszapi | start on (stopped udevtrigger and runlevel [23] and tty-device-added DEVPATH=*ttyUSB0) | 16:38 |
| djszapi | I do not expect it to work either. | 16:38 |
| SpamapS | djszapi: it will delay the start a bit... perhaps until the modem is ready | 16:39 |
| SpamapS | djszapi: Otherwise, the modem needs to be polled | 16:40 |
| djszapi | no way | 16:40 |
| djszapi | if I stop and start, it runs fine | 16:40 |
| djszapi | without doing that, it does not appear. | 16:40 |
| djszapi | so no, sorry. | 16:40 |
| SpamapS | djszapi: let me put it another way. What actual event would you expect to signify that the modem is ready? | 16:41 |
| djszapi | modem is continously ready | 16:41 |
| djszapi | since it gets power supply, and not turned off. | 16:41 |
| djszapi | so I would expect once /dev/ttyUSB0 is available, it should work oob | 16:41 |
| SpamapS | djszapi: so perhaps there's a bug in the code that emits the event about ttyUSB0 being ready when it isn't | 16:43 |
| djszapi | I do not understand why I am having these troubles if it is super simple by using SystemV. | 16:43 |
| SpamapS | djszapi: because systemv takes 5x longer to start | 16:45 |
| SpamapS | djszapi: its still a race, its just that one car is WAY slower than the other :) | 16:46 |
| djszapi | I do not feel it funny, sorry for that... | 16:46 |
| SpamapS | djszapi: you can try putting yourself way after rc runs.. 'start on stopped rc RUNLEVEL=[23]' | 16:48 |
| SpamapS | djszapi: but thats really just slowing down the race a bit. Not solving the issue. | 16:48 |
| djszapi | huh ? | 16:48 |
| SpamapS | djszapi: perhaps also try 'respawn' which will retry a few times | 16:49 |
| SpamapS | djszapi: you need an event that is reliable. Your ttyUSB0 event is clearly not reliable. :-P | 16:49 |
| djszapi | jodh said to remove the respawn... | 16:49 |
| djszapi | you have nothing to prove that saying. | 16:49 |
| djszapi | really. | 16:49 |
| SpamapS | I don't, because you won't show me the output of your program | 16:49 |
| djszapi | ubuntu should drop upstart to the trash :) | 16:50 |
| djszapi | it is unusable even for simple cases like this. | 16:51 |
| SpamapS | djszapi: this has nothign to do with upstart. | 16:51 |
| djszapi | ofc it does. | 16:51 |
| djszapi | since it works with other systems like aforementioned. | 16:51 |
| SpamapS | djszapi: upstart is operating properly... as I said, you just don't have an event you can rely on. | 16:51 |
| djszapi | that makes no sense, sorry. | 16:51 |
| djszapi | stop/start works fine! | 16:51 |
| SpamapS | djszapi: so if I tune up my engine and get my car to go 220mph, but that makes the tires melt.. its the engine's fault? | 16:52 |
| djszapi | huh ? | 16:52 |
| SpamapS | djszapi: upstart is just the point where you're interfacing with the plumbing of the entire system | 16:52 |
| SpamapS | djszapi: stop/start works fine because the device has had enough time to initialize | 16:52 |
| djszapi | I joined this channel more than three hours ago | 16:52 |
| djszapi | and still not solved | 16:53 |
| djszapi | like...wtf ? | 16:53 |
| SpamapS | djszapi: well you've been really difficult. I'm trying to help. | 16:53 |
| SpamapS | djszapi: lets back up, because I want to make sure I'm as helpful as possible. | 16:53 |
| djszapi | I have not realized I would have any solution for the issue, really. | 16:53 |
| SpamapS | djszapi: you have this job which uses 'start on runlevel [23] and tty-device-added DEVPATH=*ttyUSB0 .. right? | 16:54 |
| djszapi | to run a daemon after the system is fully up takes more than three hours :( | 16:54 |
| SpamapS | djszapi: and you refuse to try adding 'stopped udevtrigger' right? | 16:55 |
| djszapi | not right | 16:55 |
| SpamapS | djszapi: and upstart tries to start the program, but the program fails with some kind of error about the serial port not being ready, right? | 16:55 |
| djszapi | no, the program does not fail | 16:55 |
| SpamapS | ahh | 16:55 |
| SpamapS | <-- misunderstood | 16:55 |
| SpamapS | djszapi: ok, so the program never starts? | 16:56 |
| djszapi | and, no, I am now trying this as recommended: start on stopped rc RUNLEVEL=[23] | 16:56 |
| djszapi | it does start | 16:56 |
| SpamapS | djszapi: and its in 'stop/waiting' after the system fully boots? | 16:56 |
| * djszapi ponders how many hours have to wasted yet for upstart :( | 16:57 | |
| djszapi | be* | 16:57 |
| djszapi | SpamapS: again: the binary runs with start on stopped rc RUNLEVEL=[23], but the modem does not respond with either "OK" or "ERROR" like after running stop/start | 16:57 |
| djszapi | tart on runlevel [23] and tty-device-added DEVPATH=*ttyUSB0 and stopped udevtrigger -> did not work | 16:58 |
| djszapi | the daemon did not even run | 16:58 |
| SpamapS | djszapi: is it possible that the modem doesn't initialize itself until the first time you run the program? | 16:59 |
| djszapi | huh ? | 16:59 |
| djszapi | like I said, the modem is fully powered | 16:59 |
| djszapi | it is configured | 17:00 |
| djszapi | it is working | 17:00 |
| djszapi | the running ubuntu stuf makes it not responding | 17:00 |
| SpamapS | djszapi: what I'm saying is, could it be that the modem won't respond to the first program that talks to it. | 17:00 |
| djszapi | during the bootup for probably some false bootup sequence. | 17:00 |
| djszapi | I do not see how that would be possible really. | 17:00 |
| djszapi | if I do not try to run the program, but I run after the bootup | 17:01 |
| djszapi | everything is alright. | 17:01 |
| SpamapS | djszapi: ok so it still is just a race.. and we need to find the event that means "the modem is active" | 17:01 |
| djszapi | again, again and again: I need to run my program once the system is set up ! | 17:01 |
| SpamapS | I would have expected tty-device-added to be that | 17:01 |
| djszapi | darn upstart, it is not possible to do such a basic thing... | 17:01 |
| SpamapS | djszapi: systems are mobile | 17:01 |
| SpamapS | djszapi: tty devices come and go | 17:01 |
| SpamapS | djszapi: 'stopped udevtrigger' is "when all the hardware that is plugged in at boot time is initialized" | 17:02 |
| djszapi | well | 17:02 |
| SpamapS | djszapi: perhaps take out the tty-device-added part | 17:02 |
| djszapi | 19:58 < djszapi> tart on runlevel [23] and tty-device-added DEVPATH=*ttyUSB0 and stopped udevtrigger -> did not work | 17:02 |
| SpamapS | djszapi: so start on runlevel [23] and stopped udevtrigger | 17:02 |
| djszapi | I am not sure it is a good thing to base a system on a such a brittle tool. | 17:03 |
| SpamapS | djszapi: the tool is actually quite strong. the events are just not easy to understand, because parallelism is hard. | 17:04 |
| djszapi | I do not care about the events | 17:04 |
| djszapi | have you still not realized ? :) | 17:04 |
| djszapi | I would like to run my binary once everything is set up! | 17:04 |
| djszapi | I do not care about premature optimization. | 17:05 |
| djszapi | which causes -3-4 hours from more people's life. | 17:05 |
| SpamapS | djszapi: I actually fully understand that. I want there to be more clear, simpler events like 'boot-hardware-initialized'. I created the event 'static-network-up' for this reason. | 17:05 |
| SpamapS | djszapi: I also think that runlevel 2 should probably be delayed until after 'stopped udevtrigger' .. but people want the boot to proceed without waiting for all the hardware | 17:06 |
| djszapi | I am not the people. | 17:06 |
| SpamapS | djszapi: then you must understand the events. :) | 17:07 |
| djszapi | no | 17:07 |
| djszapi | Again, I would like to run a binary once everything is set up! | 17:07 |
| SpamapS | djszapi: that is runlevel [23] and stopped udevtrigger | 17:08 |
| djszapi | did not work | 17:08 |
| djszapi | modem does not respond. | 17:08 |
| SpamapS | hmmm... one thing.. | 17:08 |
| SpamapS | I notice udevtrigger uses post-stop to run 'udevadm settle' | 17:08 |
| SpamapS | so perhaps the events will still be going after that event | 17:09 |
| SpamapS | *argh* | 17:09 |
| djszapi | Upstart, to the trash! | 17:09 |
| SpamapS | djszapi: I have to go soon.. but I think this is worth a bug. It should be possible to ask for a job which waits for udevadm settle to finish. | 17:10 |
| SpamapS | djszapi: let me make this clear. This has nothing to do with upstart. It is just a deficiency in the system plumbing available on top of upstart in Ubuntu. | 17:10 |
| SpamapS | djszapi: upstart is doing everything right. Ubuntu has just failed to expose the events in a way that makes sense. | 17:10 |
| SpamapS | I am surprised that your tty-device-added doesn't work | 17:11 |
| djszapi | is there *ANY* workaround ? | 17:11 |
| djszapi | put a sleep into the script ? | 17:11 |
| djszapi | but that is blocking. | 17:12 |
| djszapi | unless the kernel events are async. | 17:12 |
| djszapi | which is probably the case. | 17:12 |
| slangasek | if the goal is to delay the startup of the job, sure, you can use a sleep | 17:12 |
| djszapi | in any case, sleep would be blocking. | 17:12 |
| slangasek | what do you mean by "async"? | 17:12 |
| SpamapS | djszapi: a sleep might work. You can also try putting 'udevadm settle' right before it running the program (or in a pre-start) | 17:12 |
| SpamapS | djszapi: sleep would be blocking, exactly, thats why it might work ;) | 17:12 |
| djszapi | can you tell me the line exactly? | 17:13 |
| slangasek | pre-start exec sleep 10? | 17:13 |
| djszapi | ohh it is just sleep 10 | 17:13 |
| djszapi | pre-start ? | 17:13 |
| djszapi | why is that ? | 17:13 |
| SpamapS | slangasek: any ideas on an event for 'when all the hardware currently plugged in is available' | 17:13 |
| slangasek | djszapi: or you can put it at the top of the 'script' | 17:13 |
| SpamapS | djszapi: so that when you respawn you don't run it again | 17:13 |
| slangasek | SpamapS: I was thinking 'stopped udevtrigger' should do this, but I have the same uncertainty you do about whether post-stop scripts are required to complete before starting jobs that are 'stop on' | 17:14 |
| djszapi | http://paste.kde.org/ -> slt ? | 17:16 |
| slangasek | I think you missed the last part of that link | 17:16 |
| djszapi | http://paste.kde.org/460106/ | 17:17 |
| slangasek | I don't think you need both the udevadm settle *and* the sleep... but certainly that should be enough | 17:17 |
| djszapi | sorry, bruteforce for everything...just work... | 17:18 |
| slangasek | I would expect that to work | 17:19 |
| slangasek | btw, the 'console output' is irrelevant there, I think you've misunderstood what that does: that tells where to send stdout/stderr from the job script, but you're redirecting all of that to files anyway | 17:20 |
| djszapi | so no harm either... | 17:20 |
| slangasek | yes | 17:21 |
| djszapi | I guess "udevadm settle" is better to have than random sleep amount ? | 17:22 |
| slangasek | SpamapS: so if 'on stopped udevtrigger' doesn't catch the udevadm settle, we should probably split the trigger and settle out into separate jobs for dependency purposes | 17:22 |
| slangasek | djszapi: yes | 17:22 |
| slangasek | did it work for you when using both? | 17:22 |
| djszapi | slangasek: yes | 17:22 |
| djszapi | now cleaning up | 17:22 |
| SpamapS | slangasek: indeed, I was thinking we might also just emit another event after the udevadmsettle.. 'stopped udevadm' or 'stopped udevtrigger' is very hard to read. :-P | 17:23 |
| SpamapS | something like boot-devices-ready ? | 17:23 |
| djszapi | http://paste.kde.org/460112/ -> Anything to improve on this ? | 17:23 |
| djszapi | can I use exec + pre-script at all ? | 17:24 |
| djszapi | or just script + pre-script ? | 17:24 |
| slangasek | djszapi: ok. then I also suggest dropping the 'runlevel [23] and' from the start condition | 17:24 |
| slangasek | because a) it should be redundant, and b) it can cause the job to deadlock in certain corner cases involving runlevel changes, so it's best to not have it | 17:24 |
| slangasek | SpamapS: 'coldplug-finished'? | 17:24 |
| slangasek | or 'udev-coldplug-finished' | 17:25 |
| slangasek | which is more explicit about what you get than 'boot-devices' | 17:25 |
| SpamapS | slangasek: still feels very "I know about plumbing" | 17:25 |
| djszapi | slangasek: could you please my worry about ? | 17:25 |
| slangasek | djszapi: yes, 'pre-start exec udevadm settle' would be fine there | 17:25 |
| djszapi | comment on* | 17:25 |
| slangasek | and would be more idiomatic | 17:25 |
| djszapi | that was not my question... | 17:25 |
| * SpamapS suspends to save battery | 17:25 | |
| djszapi | my question was related to the exec mybinary... | 17:26 |
| djszapi | + pre-script... | 17:26 |
| slangasek | djszapi: ah, right - yes, that's also allowed | 17:26 |
| slangasek | in general, it's preferred to use 'exec' instead of 'script' if you only have one command because it spares you a needless shell execution | 17:27 |
| slangasek | but you can intermix them freely | 17:27 |
| djszapi | I have been said above I cannot. | 17:27 |
| slangasek | must have been a misunderstanding; you can | 17:28 |
| slangasek | and SpamapS and jodh certainly both know that :) | 17:28 |
| slangasek | SpamapS: I can see the point that a more generic name would be appropriate... particularly since that means we can adjust the underlying implementation as needed to fulfill that interface contract | 17:28 |
| djszapi | slangasek: did not work | 17:31 |
| slangasek | djszapi: pastebin the one that didn't work, please? | 17:31 |
| djszapi | see above | 17:31 |
| djszapi | runlevel [23] -> this was removed from that | 17:31 |
| slangasek | ok | 17:31 |
| slangasek | well, re-add it then if you must :/ that's not ideal, but it's more important that it work | 17:32 |
| djszapi | I am not saying that is the culsprit | 17:32 |
| slangasek | btw, what does your disk partitioning scheme look like? | 17:32 |
| djszapi | the original working got a decent cleanup | 17:32 |
| djszapi | my worry is that if it works only with hard coded sleep :( | 17:32 |
| djszapi | that would be a pity | 17:32 |
| djszapi | so that would defeat the robust system purpose. | 17:33 |
| slangasek | true, it would; and we've tried hard to avoid using sleep in our startup scripts because sleep only hides a race, it never fixes it | 17:33 |
| djszapi | we can agree upon this. | 17:34 |
| slangasek | this is exactly why you'll find resistance to the idea that SysV is doing anything right - it's not, it's just much, much slower ;) | 17:37 |
| djszapi | slangasek: only sleep helps | 17:38 |
| djszapi | I have put back everything except sleep | 17:38 |
| slangasek | clever | 17:39 |
| slangasek | that means there's a kernel bug | 17:39 |
| slangasek | because calling 'udevadm settle' following 'stopped udevtrigger' guarantees that the kernel's queue of coldplug events is empty and udev has processed them all | 17:40 |
| slangasek | actually, wait, it doesn't guarantee there's a kernel bug either, because USB in particular can have devices show up on the bus for the first time *after* coldplugging | 17:40 |
| slangasek | djszapi: I would suggest editing /etc/init/udevmonitor.conf to comment out the 'stop' rule, then reboot, then call 'service udevmonitor stop' by hand after boot | 17:42 |
| slangasek | then post /var/log/udev somewhere | 17:42 |
| djszapi | I do not have time for that, sorry. | 17:42 |
| slangasek | ... unless you prefer to stick with the 'sleep' option | 17:42 |
| slangasek | ok | 17:42 |
| djszapi | hacking the base system upside down is even worse than any sleep | 17:42 |
| slangasek | fundamentally, this scores one of the weaknesses of relying on any sort of a static event to tell you the devices are all up... because upstart can't actually be sure they are, because the kernel and udev aren't sure that they are | 17:43 |
| slangasek | s/scores/underscores/ | 17:43 |
| djszapi | tell me a better way | 17:43 |
| djszapi | which is working, really. | 17:43 |
| slangasek | which is why the tty-device-added would have been the better solution, but you ran into problems there | 17:43 |
| djszapi | that is broken | 17:43 |
| slangasek | and to understand why it wasn't work, I'd need to see a udev log | 17:43 |
| djszapi | give me a foobar.conf | 17:44 |
| djszapi | and command set | 17:44 |
| djszapi | I can spend half an hour with this | 17:44 |
| djszapi | not more. | 17:44 |
| djszapi | if you think that helps you, I can help | 17:44 |
| djszapi | but I do not have more time, sorry. | 17:44 |
| slangasek | if you have a solution that works for you, let's not spend any more time on it | 17:44 |
| djszapi | sleep 30 -> this is the current solution | 17:45 |
| djszapi | but super fragile. | 17:45 |
| slangasek | the only way it would help me is to give me the satisfaction of knowing your job was written the Right Way ;) | 17:45 |
| djszapi | there is no right way | 17:45 |
| slangasek | but to make any progress I definitely need to see a complete udev log | 17:45 |
| djszapi | we went through those, none of them worked. | 17:45 |
| djszapi | give me a start line | 17:46 |
| djszapi | I can spend half an hour | 17:46 |
| djszapi | warning: not more | 17:46 |
| djszapi | /etc/init/udevmonitor.conf -> stop rule: commented | 17:46 |
| slangasek | right | 17:47 |
| slangasek | then reboot | 17:47 |
| djszapi | no matter what start line ? | 17:47 |
| slangasek | yes | 17:47 |
| djszapi | in my job ? | 17:47 |
| djszapi | yes what ? | 17:47 |
| djszapi | start on runlevel [23] and stopped udevtrigger | 17:48 |
| djszapi | this is the current start line | 17:48 |
| slangasek | then, once booted and you can confirm that your tty is present in /dev/, run 'service udevmonitor stop' and post /var/log/udev | 17:48 |
| slangasek | yes - to give you a better start line for your job, I first need the debugging info from udev | 17:48 |
| slangasek | which requires a reboot just to get that | 17:48 |
| slangasek | so ignore your own job for now, we just need the complete udev log | 17:49 |
| djszapi | I am paid for this job, I cannot ignore ;) | 17:49 |
| slangasek | the purpose of this reboot is to *just* get the udev log | 17:49 |
| slangasek | whether the job starts or not on this reboot is irrelevant to this question | 17:50 |
| djszapi | root@linaro-ubuntu-desktop:~# service udevmonitor stop | 17:50 |
| djszapi | udevmonitor stop/waiting | 17:50 |
| djszapi | root@linaro-ubuntu-desktop:~# | 17:50 |
| djszapi | you got I was joking right ? | 17:50 |
| slangasek | heh... sorry, sometimes it's hard to get the humor on IRC | 17:50 |
| djszapi | ->/var/log/udev is HUGE | 17:51 |
| * djszapi is intalling wgetpaste | 17:51 | |
| djszapi | heh not available, darn... | 17:51 |
| slangasek | pastebinit :) | 17:51 |
| djszapi | how ? | 17:51 |
| djszapi | scrolling over a large file is not possible | 17:52 |
| djszapi | time and buffer wise | 17:52 |
| slangasek | there's a "pastebinit" command in the Ubuntu archive | 17:52 |
| djszapi | here you go anyway: http://paste.pocoo.org/show/584182/ | 17:52 |
| djszapi | done by wgetpaste from the host | 17:52 |
| djszapi | after scp'ing the file in question | 17:52 |
| slangasek | ok | 17:52 |
| djszapi | pastebinit is not a vailable on my linaro ubuntu for the pandaboard, sorry. | 17:53 |
| slangasek | well, it's in the Ubuntu archive ;) but ok | 17:53 |
| slangasek | are you using an initramfs when booting? | 17:53 |
| djszapi | no clue, sorry. | 17:54 |
| slangasek | ok | 17:54 |
| slangasek | I'll assume you are then | 17:54 |
| slangasek | udev starts at 9.82s after boot. kernel sees ttyUSB0 at 13.35s after boot. That may or may not be enough time that coldplugging has missed the event | 17:56 |
| djszapi | dmesg | grep initramfs | 17:56 |
| djszapi | [ 0.372070] Trying to unpack rootfs image as initramfs... | 17:56 |
| * slangasek nods | 17:56 | |
| djszapi | what next ? | 17:57 |
| slangasek | so I would expect 'start on tty-device-added DEVNAME=ttyUSB0' to do the right thing | 17:57 |
| slangasek | is that one that you tried? | 17:57 |
| djszapi | nope | 17:57 |
| djszapi | tty-device-added DEVPATH=*ttyUSB0 | 17:58 |
| djszapi | I tried that one. | 17:58 |
| djszapi | Note the star. | 17:58 |
| slangasek | yeah | 17:58 |
| slangasek | that should *also* have worked | 17:58 |
| djszapi | then yep, I tried. | 17:58 |
| djszapi | went nowhere usable. | 17:58 |
| djszapi | can I restore the stop rule in here: /etc/init/udevmonitor.conf ? | 17:59 |
| slangasek | yes | 17:59 |
| djszapi | http://paste.kde.org/460154/ -> this essentially right ? | 17:59 |
| slangasek | oh, actually, I see that the tty subsystem event comes before the usb-serial subsystem event | 18:00 |
| djszapi | oh ? | 18:00 |
| djszapi | PL2303 usb-serial converter | 18:00 |
| djszapi | that resides between the pandaboard and the modem. | 18:00 |
| djszapi | because the pandaboard and the modem both have male serialport connection | 18:01 |
| djszapi | and I have not bothered with fixing that. | 18:01 |
| djszapi | since I had a usb-serial converter by off-hand. | 18:01 |
| djszapi | both should work anyway... | 18:01 |
| djszapi | so what can we do if any ? | 18:02 |
| slangasek | whoops, no, we don't get a usb-serial udev event anyway, only a kernel event | 18:02 |
| slangasek | and that udev event is emitted after both the kernel events | 18:02 |
| djszapi | well | 18:03 |
| djszapi | I am now trying the start on tty-device-added DEVNAME=ttyUSB0 line | 18:03 |
| djszapi | let me know if you need any logs. | 18:03 |
| djszapi | after a boot | 18:03 |
| slangasek | no logs, though I'm interested to know if that works | 18:03 |
| djszapi | lol | 18:03 |
| slangasek | oh wait | 18:03 |
| slangasek | DEVNAME=/dev/ttyUSB0 | 18:03 |
| djszapi | yeah ? | 18:03 |
| slangasek | so DEVNAME=ttyUSB0 will definitely fail | 18:03 |
| slangasek | sorry | 18:04 |
| djszapi | right, that is why I have been recommended by the stars | 18:04 |
| djszapi | though hard coding is not that bad in this special case | 18:04 |
| djszapi | since it is always like that | 18:04 |
| djszapi | ttyUSB0 is right under /dev | 18:04 |
| djszapi | if not, many stuff will break in the world :D | 18:04 |
| slangasek | yeah; either DEVNAME=*/ttyUSB0 or DEVNAME=/dev/ttyUSB0 should work | 18:04 |
| slangasek | and if those don't work, I think this is a kernel driver bug | 18:05 |
| djszapi | now: start on tty-device-added DEVNAME=/dev/ttyUSB0 | 18:05 |
| djszapi | phantastic... | 18:05 |
| slangasek | because we should not be seeing these events before the driver is initialized and ready for use | 18:05 |
| djszapi | there is already a pl2303 kernel bug | 18:05 |
| djszapi | I did not even bother to report it | 18:05 |
| djszapi | since I have no clue where to report that | 18:05 |
| djszapi | and I do not wanna spend hours for finding where to report | 18:05 |
| slangasek | I could tell you where based on 'uname -r' | 18:06 |
| djszapi | 3.1.1-26-linaro-lt-omap | 18:06 |
| djszapi | linaro just wraps upstream IMO | 18:07 |
| slangasek | in a manner of speaking | 18:07 |
| slangasek | in the case of the pl2303 bug, that's probably true | 18:08 |
| slangasek | this bug may be an omap-specific usb bug though | 18:08 |
| djszapi | perhaps | 18:08 |
| djszapi | but the other bug was appearing on my Lenovo Thinkpad 510 laptop | 18:08 |
| djszapi | two connected usb-serial | 18:08 |
| djszapi | second did not work | 18:08 |
| djszapi | not even with stty -F :) | 18:09 |
| djszapi | in any case | 18:09 |
| slangasek | https://bugs.launchpad.net/linux-linaro to report issues with the omap kernel | 18:09 |
| djszapi | my binary is not even run (according to "ps aux | grep foobar") after the start on ... line. | 18:09 |
| slangasek | hmm, really? | 18:09 |
| djszapi | really. | 18:09 |
| djszapi | that is what I said above as well | 18:10 |
| slangasek | I think you should just revert to the 'sleep' for now then, sorry | 18:10 |
| djszapi | http://paste.kde.org/460160/ | 18:10 |
| slangasek | hmm | 18:10 |
| slangasek | I don't know why that's not working | 18:11 |
| djszapi | I wonder how long sleep I should put in there. | 18:11 |
| djszapi | not to get a brittle system | 18:11 |
| slangasek | nor do I | 18:12 |
| djszapi | start on runlevel [23] and stopped udevtrigger | 18:16 |
| djszapi | do I need both before a sleep ? | 18:16 |
| djszapi | or just the second ? | 18:16 |
| slangasek | probably the second is enough | 18:16 |
| djszapi | let me try. | 18:17 |
| djszapi | sleep 20 is now what I do | 18:17 |
| djszapi | trying atm with 10 secs. | 18:17 |
| djszapi | I just wonder what the border is. :-) | 18:18 |
| djszapi | I will not use this low value for sure. | 18:18 |
| djszapi | (in the end) | 18:18 |
| djszapi | slangasek: second is enough, yeah. | 18:27 |
| djszapi | slangasek: what should be the stop line ? | 18:27 |
| djszapi | jodh, SpamapS and slangasek: thank you for your help | 18:35 |
| slangasek | stop line> I don't know, when do you want it to stop? :) 'stop on runlevel [016]' would be typical | 18:46 |
| marcoceppi | I've written an upstart script, and the script requires a HOME environment, I have a user for the daemon to run as, how do I let upstart script know where HOME is and pass that env on to the exec command? | 22:57 |
| marcoceppi | I tried adding evn HOME="/home/user" to the upstart script with no luck | 22:58 |
| slangasek | s/evn/env/ ? | 22:58 |
| marcoceppi | slangasek: yes typo in chat, not a typo in the config | 22:59 |
| slangasek | ok, just checking | 22:59 |
| marcoceppi | here is the current upstart script | 22:59 |
| marcoceppi | (if it helps) | 22:59 |
| marcoceppi | http://paste.ubuntu.com/937599/ | 22:59 |
| slangasek | it's possible you also need to 'export HOME' | 23:03 |
| slangasek | I'm not sure what the semantics of env vs. export are, honestly | 23:03 |
| slangasek | I'm not convinced the manpage describes the current behavior accurately | 23:03 |
| slangasek | hmm... but I see other jobs on the system that use that just fine | 23:04 |
| marcoceppi | I'll give export a quick try | 23:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!