Timeline for Application lags if started from init.d?
Current License: CC BY-SA 3.0
27 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 2, 2014 at 10:32 | comment | added | Paul | @Graeme It did fix it, it was rather unintuitive as you suggest. Apparently it having more cpu cycles was a bad thing, must have been slowing down whatever was in charge of printing information to the screen by hogging resources? 19 would like a charm, solved, thanks a lot for your help btw | |
| Apr 2, 2014 at 10:12 | comment | added | Graeme | @Paul, could well be it, but -N 19 will only make the program go slower! A negative number is more favourable to the process. Also consider renice before you connect to it if it is running all the time. | |
| Apr 2, 2014 at 9:33 | comment | added | Paul | So the issue here is different default nice levels for users. | |
| Apr 2, 2014 at 9:17 | comment | added | Paul | @Graeme I think I solved it, just testing. Apparently starting it from python set a nice level of 19, but starting it from boot/root sets it as 0, which seems to slow the whole system down for some reason, adding -N 19 to boot should work when I try | |
| Apr 1, 2014 at 16:36 | comment | added | Graeme | How about this: start-stop-daemon -q -p application_pidfile -m -b -x /usr/bin/stdbuf -S -- -oL -eL /bin/application. Running this command from a shell should stop the issue if it is buffering. | |
| Apr 1, 2014 at 16:15 | comment | added | Graeme | I'm confused, how exactly did you recreate the issue? If you have the problem when running from a root shell, but nothing when running the exact same command from a normal user shell, then the problem is likely caused by environmental variables and nothing to do with buffering. | |
| Apr 1, 2014 at 16:11 | comment | added | Paul | whenever I call it with any command froma shell this issue occurs, so i guess it may not be associated with booting and is associated with start-stop-daemon. I'm not sure why calling start-stop-daemon with python was masking this issue and making everything work well. I am using clish to call the python btw | |
| Apr 1, 2014 at 16:00 | comment | added | Paul | @Graeme I will test again maybe I messed up. i have noticed something odd, I generally start it with a python script calling start-stop-daemon and there is no delay. but when I tried from a root shell with the same command the issue occurs! like Mikel asked me to check about. I'll try your posts now | |
| Apr 1, 2014 at 15:52 | comment | added | Graeme | ? start-stop-daemon should do the equivalent of this anyway if you use the -b option or else it can't be detached from the terminal. I was wondering if it still inherited its buffering from start-stop-daemon. Try stdbuf -o4096 -e4096 start-stop-daemon -q -p application_pidfile -S -m -b -x /bin/application in there terminal, maybe this will reproduce the problem. Also, can you tell us which program you are using? | |
| Apr 1, 2014 at 15:41 | comment | added | Paul | @Graeme that just directs all lines to null so when I connect I see nothing :) | |
| Apr 1, 2014 at 15:21 | comment | added | Graeme | Try start-stop-daemon -q -p application_pidfile -S -m -b -x /bin/application &>/dev/null </dev/null and see if you have the issue | |
| Apr 1, 2014 at 15:20 | comment | added | Paul | @Graeme I am able to connect to the cli of the software router via a session id, bring it to the foreground. The lines are printed out to my terminal. It looks to buffering very slowly yes, I just dont know why. Especially as this only happens if I start it from boot. Any time after boot and it behaves like a normal router console | |
| Apr 1, 2014 at 15:15 | comment | added | Paul | @Mikel I have a python command that starts it from start-stop-daemon after boot and that works completely fine. I will try doing it from a root shell and get back to you, but I imagine it works perfectly. | |
| Apr 1, 2014 at 14:55 | comment | added | Mikel | What happens if you start it using start-stop-daemon from a root shell after boot? | |
| Apr 1, 2014 at 14:55 | comment | added | Graeme | 'If there is information being printed to the screen for example, it will be printed out in chunks.' This sounds like the normal buffering you get when a program doesn't output to a terminal. Perhaps you are just looking for the program to be line buffered so that each line is output immediately (or completely unbuffered). Maybe the reason you think it is slow is just because the output is left in buffer for a while. How is it that you see output when the program is started by an init script? | |
| Apr 1, 2014 at 14:31 | history | edited | Paul | CC BY-SA 3.0 | added 329 characters in body |
| Apr 1, 2014 at 14:27 | history | edited | goldilocks | edited tags | |
| Apr 1, 2014 at 14:20 | comment | added | Paul | @Mikel The line in init.d calls the python script I have edited above. This runs in the background, I can connect to the application when it is running. The application is a software router. I connect to it's console. Here is where all the slow output is observed | |
| Apr 1, 2014 at 14:19 | answer | added | goldilocks | timeline score: 1 | |
| Apr 1, 2014 at 14:18 | history | edited | Paul | CC BY-SA 3.0 | added 303 characters in body |
| Apr 1, 2014 at 14:17 | comment | added | Mikel | @TAFKA Sure. But how it prints to the screen could be an important piece of the puzzle. Does it print to /dev/console? Directly or via syslog for example? What does it try to print and when? We don't have any information. | |
| Apr 1, 2014 at 14:10 | comment | added | goldilocks | Obviously this is not the case for other init process, and since it is also not the case in general for others, you need to provide a reproducible example if you want an answer. @Mikel Note he used that "for example" -- even if the process does print to the screen, it should not be slowed down particular except to the extent that it is interleaved with other processes. | |
| Apr 1, 2014 at 14:05 | comment | added | Mikel | You start it from init, yet it produces output to the screen? Processes started via init should be daemons and produce no output. Can you explain more about where the output goes, when, and why? And please include your init script. | |
| Apr 1, 2014 at 14:03 | history | edited | Mikel | CC BY-SA 3.0 | edited title |
| Apr 1, 2014 at 13:46 | review | First posts | |||
| Apr 1, 2014 at 13:55 | |||||
| Apr 1, 2014 at 13:41 | history | edited | Paul | CC BY-SA 3.0 | added 21 characters in body |
| Apr 1, 2014 at 13:30 | history | asked | Paul | CC BY-SA 3.0 |