Loading a most stubborn application at startup

anstmich · 2011-04-12 08:13:51

Hi all,

I received quite a bit of help on irc, however I have nonetheless been unsuccessful in making this work. Essentially I have written some software that manages various usb devices as well as a script that runs the application and then logs the output from stdout and stderr. Running this application from the cli after logging in works great. Attempting to run the application during boot however does not work (it segfaults).

I have tried many things: writing a bash script and running it from rc.d (via daemons in rc.conf), attempting to run the script directly from rc.local, attempting to run the script using screen from rc.local, performing various modifications to my /etc/inittab such as using this command as described in the wiki x:5:once:/bin/su - -- PREFERRED_USER -l -c 'EXECUTE SCRIPT HERE', etc.

None of these worked. I figured that, before I quit entirely, I might ask the community to see if anyone else had any ideas. Any help is greatly appreciated!!!

lives2evil · 2011-04-12 10:52:19

If it's a programming related I think you've post at the wrong place.

Well, try running your application manually at console (NO X running), debug it with gdb. And perhaps methods you used could help diagnosis (what libraries you used for instance).

anstmich · 2011-04-12 13:31:34

As I said, running the application from the cli after logging in works without a problem, so I dont see how it could be a bug, although it is possible I guess. As far libraries go, beyond the standard c libraries, I use libusb (which I am guessing is related to my problem).

lives2evil · 2011-04-12 13:53:15

Does your application work when you put it in .xinit?

anstmich · 2011-04-12 14:39:04

lives2evil wrote:

Does your application work when you put it in .xinit?

I dont have X installed on that machine. Something to note, however, is that the program fails when run in the background (i.e. "/home/user/app &")

ewaller · 2011-04-12 14:48:39

I agree with lives2evil,

This will get a lot more visibility from the coders over at Programming. Moving....

I would wager real money you are using dereferencing null pointer some place. Maybe some function that fails because the USB in question is not yet set in time for your script? Set up some logging and pour a bunch of telemetry out to the debug log to see what is happening.

You might want to put the source up on pastebin and provide a link.

rowdog · 2011-04-12 15:19:50

anstmich wrote:

Something to note, however, is that the program fails when run in the background (i.e. "/home/user/app &")

Why? That's probably the first issue to track down. Is this "software" a program that you wrote? What language?

Long running processes are normally written as daemons. Wikipedia has an overview of the usual approach at
http://en.wikipedia.org/wiki/Daemon_%28 … of_daemons

anstmich · 2011-04-12 16:36:01

rowdog wrote:

anstmich wrote:
Something to note, however, is that the program fails when run in the background (i.e. "/home/user/app &")
Why? That's probably the first issue to track down. Is this "software" a program that you wrote? What language?
Long running processes are normally written as daemons. Wikipedia has an overview of the usual approach at
http://en.wikipedia.org/wiki/Daemon_%28 … of_daemons

Yes this is an application that I wrote in C. I tried daemonizing it and that did not work, which I am guessing somehow relates to the fact that it doesnt like being run as a background prcoess. Beyond using libusb, the only other "libraries" used are those provided standard with C (i.e. string.h, stdio.h, stdlib.h). Also, when I did daemonize it, if I called /etc/rc.d/app start it would work just fine, just not during boot, however. I will do some reading though, thanks!

I agree with lives2evil,
This will get a lot more visibility from the coders over at Programming. Moving....
I would wager real money you are using dereferencing null pointer some place. Maybe some function that fails because the USB in question is not yet set in time for your script? Set up some logging and pour a bunch of telemetry out to the debug log to see what is happening.
You might want to put the source up on pastebin and provide a link.

I doubt it is a null pointer (I do quite a bit of error checking for this). My guess, though, is that you are right about the USB. There must be something that libusb needs -- an environment variable or something.

If I try putting in a long delay (30+ seconds) in the python (or bash) script that runs my application, although it pauses successfully, the application called still fails. Furthermore, if I immediately log in and run the script manually, everything works fine. This would lead me to believe that there is perhaps a problem detaching the kernel USB driver? Im not sure what else could be different before and after logging in.

Thanks for the help!

anstmich · 2011-04-12 16:42:17

Here is the code that manages all things USB: http://pastebin.com/dUbVM42V

anstmich · 2011-04-12 17:30:07

Ok, so I have a temporary, albeit far from ideal, solution. Using rungetty + inittab, I had it autologin as root and then setup my .bash_profile to load the python script. Far from elegant, but it at least works. Sigh

ngoonee · 2011-04-13 01:21:13

anstmich wrote:

Ok, so I have a temporary, albeit far from ideal, solution. Using rungetty + inittab, I had it autologin as root and then setup my .bash_profile to load the python script. Far from elegant, but it at least works. Sigh

Talk about overkill . I don't have any better suggestions though, unfortunately. Hope you trust your code.

lives2evil · 2011-04-13 11:37:22

Well, I was going to suggest some thing similiar. My idea was to run it as normal user (.bashrc), but allow it to run only once (I think a lock file is pretty simple).
Glad you got it working then.

tavianator · 2011-04-13 21:48:54

Use valgrind to track down the bug. I'd help, but you didn't post all the code (it's missing the main() routine at least).

anstmich · 2011-04-17 22:45:45

I dont have too much time at the moment to do any debugging, however out of curiosity, what kind of bug could prevent an application from being run in the background? What changes internally when this is done?

Arch Linux

#1 2011-04-12 08:13:51

Loading a most stubborn application at startup

#2 2011-04-12 10:52:19

Re: Loading a most stubborn application at startup

#3 2011-04-12 13:31:34

Re: Loading a most stubborn application at startup

#4 2011-04-12 13:53:15

Re: Loading a most stubborn application at startup

#5 2011-04-12 14:39:04

Re: Loading a most stubborn application at startup

#6 2011-04-12 14:48:39

Re: Loading a most stubborn application at startup

#7 2011-04-12 15:19:50

Re: Loading a most stubborn application at startup

#8 2011-04-12 16:36:01

Re: Loading a most stubborn application at startup

#9 2011-04-12 16:42:17

Re: Loading a most stubborn application at startup

#10 2011-04-12 17:30:07

Re: Loading a most stubborn application at startup

#11 2011-04-13 01:21:13

Re: Loading a most stubborn application at startup

#12 2011-04-13 11:37:22

Re: Loading a most stubborn application at startup

#13 2011-04-13 21:48:54

Re: Loading a most stubborn application at startup

#14 2011-04-17 22:45:45

Re: Loading a most stubborn application at startup

Board footer