Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I want to run a ppp connection when my USB modem is connected, so I use this udev rule:

ACTION=="add", SUBSYSTEM=="tty", ATTRS{idVendor}=="16d8",\
    RUN+="/usr/local/bin/newPPP.sh $env{DEVNAME}"

(My modem appears in /dev as ttyACM0)

newPPP.sh:

#!/bin/bash
/usr/bin/pon prov $1 >/dev/null 2>&1 &

Problem:

The udev event fires, and newPPP.sh is running, but newPPP.sh process is killed after ~4-5s. ppp does not have time to connect (its timeout is 10s for dial up).

How can I run a long time process, that will not be killed?

I tried using nohup, but it didn't work either.

System: Arch Linux

Update

I found a solution here, thanks to maxschlepzig.

I use at now to run my job detached from udev process.

But the one question remains unanswered: Why do nohup and & not work?

share|improve this question

migrated from serverfault.com Nov 20 '12 at 20:40

This question came from our site for professional system and network administrators.

add comment

4 Answers 4

If you run a decent distribution with systemd support, the easiest and technically safest way is to use a device unit.

This way, systemd will be in full control of the long-running script and will even be able to properly terminate the process once the device is shutdown/removed - detaching the process means you're giving up being in full control of the process state and its history.

Besides that, you'll be able to inspect the status of the device and it's attached service by running systemctl status my-ppp-thing.device.

See also this blog post for some more examples and details.

share|improve this answer
add comment

Shell has ability to run commands in background:

(

lots of code

) &

Commands grouped by the braces with ampersand after them will be executed asynchronously in a subshell. I use this to autoconnect when a USB modem is inserted and switched. It takes about 20 seconds and works fine under udev.

share|improve this answer
    
You might want to redirect stderr, stdout, and stderr in such a situation. –  mdpc Jul 2 '13 at 18:37
    
@mdpc hmm... why? I saw usb_modeswitch closes streams in this scenario: exec 1<&- 2<&- 5<&- 7<&- –  user42295 Jul 4 '13 at 10:38
add comment

I got it to work with setsid. My RUN part of the udev rule:

RUN+="/bin/bash script.sh"

then in the script:

#!/bin/bash
if [ "$1" != "fo_real" ]; then
  /usr/bin/setsid $(/usr/bin/dirname $0)/$(/usr/bin/basename $0) fo_real &
  exit
fi

Rest of script is here....

The first call to the script returns with exit status 0, but the second call to the script keeps running with PPID = 1.

share|improve this answer
add comment

Probably because its parent process is terminated and the termination signal propagates to its children, which don't block it (and in case of SIGKILL they even can't).

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.