Embedded Linux: shutdown from program started up with systemd?

Hi guys,

I have a program which has the possibility of doing a shutdown or reboot remotely by doing a popen("reboot") or popen("halt") call after doing some cleanup.

I have found that if I execute the application directly from the command line, this works and the shutdown or reboot takes place immediately.
However if I try it when the program has been automatically executed on startup through a systemd script, there is a really long delay (a little more than one minute) before it works.

Does anybody here know why this might be, and if there is any way to work around it? Or is this a question I should ask on a Linux group somewhere rather than here?

Am 21.04.2015 um 18:22 schrieb sbattazzo@gmail.com:

> I have a program which has the possibility of doing a shutdown or
> reboot remotely by doing a popen("reboot") or popen("halt") call
> after doing some cleanup.

Strictly speaking, that can't be entirely true, because those are not 
correct calls of popen() to begin with.  They're lacking the "w" or "r" 
argument.  And you shouldn't have to call popen() instead of the simpler 
system() if you didn't actually need to talk to those sub-programs, or 
receive information from them.

Generally speaking, I'm not so sure that calling another program to do 
those things is the right approach.

> I have found that if I execute the application directly from the
> command line, this works and the shutdown or reboot takes place
> immediately. However if I try it when the program has been
> automatically executed on startup through a systemd script, there is
> a really long delay (a little more than one minute) before it works.

This could very well be related to the fact you're using popen().  One 
difference between systemd and an interactive session is that the shell 
runs in a console session, with access to display output and keyboard 
input.  One end of a popen() is supposed to inherit one of those 
connections from the parent.  If that's not there to be inherited, the 
subprocess may well behave differently.  For a closer approximation of 
what happens if your program is run by systemd, you might want to run it 
in the background, i.e.

  yourprogram &

> Does anybody here know why this might be, and if there is any way to
> work around it? Or is this a question I should ask on a Linux group
> somewhere rather than here?

Yes, it is, because there's really nothing embedded-specific about it.

On Tuesday, April 21, 2015 at 1:27:43 PM UTC-7, Hans-Bernhard Br�ker wrote:
> Am 21.04.2015 um 18:22 schrieb sbattazzo@gmail.com:
> 
> > I have a program which has the possibility of doing a shutdown or
> > reboot remotely by doing a popen("reboot") or popen("halt") call
> > after doing some cleanup.
> 
> Strictly speaking, that can't be entirely true, because those are not 
> correct calls of popen() to begin with.  They're lacking the "w" or "r" 
> argument.  And you shouldn't have to call popen() instead of the simpler 
> system() if you didn't actually need to talk to those sub-programs, or 
> receive information from them.
> 

Yes, I had the "r" or "w" there in the actual source code, just omitted it here. And yes, you're right that I don't need to pipe anything in or out of that call, but I think I used something like "re" so that hopefully the popen call would wait until the program was finished executing. I wasn't sure if I could get that behavior out of system(). I could try system() anyway.


> > Does anybody here know why this might be, and if there is any way to
> > work around it? Or is this a question I should ask on a Linux group
> > somewhere rather than here?
> 
> Yes, it is, because there's really nothing embedded-specific about it.

Fair enough, thanks for the help anyway!

Just to give an update, using system() instead of popen() fixed the issue for me, so it was pretty much as you suggested.

I guess I should have known to try that.. thanks for the hint though!