motion fails to start because /var/run/motion is missing

Bug #294852 reported by Grant Murray
48
This bug affects 7 people
Affects Status Importance Assigned to Milestone
motion (Ubuntu)
Confirmed
Undecided
Unassigned
Nominated for Hardy by juancarlospaco
Nominated for Intrepid by juancarlospaco
Nominated for Jaunty by juancarlospaco
Nominated for Karmic by Mike Pelley
Nominated for Lucid by Kioan

Bug Description

Binary package hint: motion

I'll describe a fix first from which you may derive the problem: her is the fix:

install --group=motion --owner=motion -d /var/run/motion

once I did this then the init script would start motion.

Some other observations:

In the init script the "-b" flag to start-stop-daemon seems like the wrong thing to do, since motion can detach all by itself just fine and it is controlled in its config file. And actually using the config file setting causes problems with the -b flag here.

I could set the pidfile to /var/run/motion.pid but since motion runs as user motion this does not work.

This has actually been here since hardy, but I just upgraded to intrepid and see it still is here.

Revision history for this message
Grant Murray (email-grantmurray) wrote :

The -b flag to start-stop-daemon really causes problems and should be removed. When motion believes it is running in the foreground it does not write a PID file

Revision history for this message
juancarlospaco (juancarlospaco) wrote :

The same problem on Ubuntu 9.04 Jaunty 32bit, my work around is to launch like this:
sudo mkdir /var/run/motion ; motion

Revision history for this message
ingo (ingo-steiner) wrote :

Still present on Hardy-amd64 - I also had to fiddle out a workaround, a bit different, but same root cause:

motion (as daemon) runs as user=motion, group=motion which is correkt from point of security.
But this prohibits to place its PIDFILE in /var/run cause lack of permission.

ingo (ingo-steiner)
Changed in motion (Ubuntu):
status: New → Confirmed
Revision history for this message
torglut (torglut) wrote :

This bug still exists in 9.10

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.10
DISTRIB_CODENAME=karmic
DISTRIB_DESCRIPTION="Ubuntu 9.10"

This bug seams to be nearly the same as the one described here (for another package) :
https://bugs.launchpad.net/ubuntu/+source/zabbix/+bug/172775

- motion runs as uid "motion"
- /var/run is mounted as tmpfs
- /etc/motion/motion.conf defines "process_id_file /var/run/motion/motion.pid"
- /etc/init.d/motion defines "NAME=motion" and "PIDFILE=/var/run/$NAME.pid" (which is different)

A possible fix could be to modify /etc/init.d/motion to include :

(...)

case "$1" in
  start)
    if check_daemon_enabled ; then
        log_daemon_msg "Starting motion detection daemon : $NAME"
        ### BEGIN /var/run Fix
        MOTIONPIDDIR=/var/run/motion
        if test ! -d $MOTIONPIDDIR; then
            mkdir -p $MOTIONPIDDIR
            chown root:motion $MOTIONPIDDIR
            chmod 775 $MOTIONPIDDIR
        fi
        ### END /var/run Fix
        if start-stop-daemon --start --oknodo --exec $DAEMON -b --chuid motion ; then
            log_end_msg 0
        else
            log_end_msg 1
            RET=1
        fi
    fi
    ;;

(...)

I don't know wether "$PIDFILE", defined in /etc/init.d/motion is used anywhere or not.

Revision history for this message
JasonT (schnogg) wrote :

This does work around the issue, but why does /var/run/motion disappear in the first place?

Revision history for this message
Kioan (kioan-) wrote :

The bug also exists in Lucid 10.04.
By doing what torglut suggests in the comment #4 above everything works fine.

Revision history for this message
Mike Koss (mckoss) wrote :

Also occurring in Maverick 10.10. Torglut's solution #4 works for me (I use a slightly modified form in Bug #675694)

Revision history for this message
Dan Madere (danmadere) wrote :

This bug was still present for me in 11.10 and the fix #4 worked.

Revision history for this message
JaSauders (jasauders) wrote :

12.04 64 bit, seeing the same thing. At first I thought I was working around the issue by giving myself permission to /var/run/motion, until I realized it seems to disappear on itself.

I've also noticed if I run sudo /etc/init.d/motion restart, once motion is detected, the process disappears and no trace of motion is listed under ps -A. Is it possible they're related?

Revision history for this message
Darren Conway (darren-conway) wrote :

I have server version 12.04 installed with the same bug. I tried the fix in Post 4 and got the following results. Motion is started but then dies.

darren@alpha:~$ pgrep motion
darren@alpha:~$ sudo /etc/init.d/motion restart
[sudo] password for darren:
 * Restarting motion...
* Stopping motion detection daemon motion
No /usr/bin/motion found running; none killed.
                                                                                                                      [ OK ]
 * Starting motion detection daemon : motion
* Starting motion detection daemon motion [ OK ]
                                                                                                                      [ OK ]
darren@alpha:~$ pgrep motion
1245
darren@alpha:~$ pgrep motion

Motioin died after about 10-15 seconds.
No images are produced so Motion doesn't get very far before disappearing.
The original /etc/init.d/motion file included the following:

case "$1" in
  start)
    if check_daemon_enabled ; then
        if ! [ -d /var/run/motion ]; then
                mkdir /var/run/motion
        fi
        chown motion:motion /var/run/motion

        log_daemon_msg "Starting $DESC" "$NAME"
if start-stop-daemon --start --oknodo --exec $DAEMON -b --chuid motion ; then
            log_end_msg 0
        else
            log_end_msg 1
            RET=1
        fi
    fi
    ;;

The modified file (based on posting 4) looks like the following:

case "$1" in
  start)
    if check_daemon_enabled ; then
        log_daemon_msg "Starting motion detection daemon : $NAME"
        ### BEGIN /var/run Fix
        MOTIONPIDDIR=/var/run/motion
        if ! [ -d $MOTIONPIDDER ]; then
             mkdir -p $MOTIONPIDDER
        chown root:motion /var/run/motion
        chmod 775 $MOTIONPIDDIR
        fi

        ### END /var/run Fix
        log_daemon_msg "Starting $DESC" "$NAME"
if start-stop-daemon --start --oknodo --exec $DAEMON -b --chuid motion ; then
            log_end_msg 0
        else
            log_end_msg 1
            RET=1
        fi
    fi
    ;;

I tried running the script with the chmod and chown outside the < if start..... if> but that didn't work.

Revision history for this message
Darren Conway (darren-conway) wrote :
Download full text (6.0 KiB)

It appears that I have solved the problem related to permissions for /var/run/motion. Further investigation shows that Motion seems to start OK and then crashes. This crash does not appear to be related to this bug 294852. I am running 2 cameras so it may be related to bug 604169.

When I configure Motion to run as a daemon, it dies soon after starting. I am running a headless Ubuntu server which is being used to transfer images to an ftp server.

I am running Ubuntu server LTS Maverick v10.10. and Motion (3.2.12) installed with apt-get.

To get motion to run under daemon mode I did the following: 1. edit motion.conf to turn on daemon mode 2. edit /etc/init.d/motion to ensure motion has wr permissions to the /var/run/motion directory for the PID (Launchpad bug 294852) 3. edit /etc/default/motion to enable daemon (=yes).

When run <sudo /etc/init.d/motion restart> everything appears to work OK. Motion starts, <pgrep motion> shows a PID is assigned. I don't get an error message related to write permissions to the /var/run/motion directory. The program appears to go to daemon mode normally, then about 10 seconds later it dies with a segmentation fault.

This bug is consistent and repeatable so if you need more information from me, just ask. This bug does not materialise when motion is run from the command line.

I have had another server running Motion with a single camera and a different version of Ubuntu for about a year. I had similar problems trying to run Motion as a daemon process. I ended up running it as a user process with a crontab task setup as a deadman timer to restart Motion if it stopped. Not an entirely satisfactory solution.

The launchpad bug reports above imply that others may have this bug.

The syslog reported the following:

Jan 17 23:10:49 alpha motion: [0] Processing thread 0 - config file /etc/motion/motion.conf
Jan 17 23:10:49 alpha motion: [0] Processing config file /etc/motion/trackcam1.conf
Jan 17 23:10:49 alpha motion: [0] Processing config file /etc/motion/trackcam2.conf
Jan 17 23:10:49 alpha motion: [0] Motion 3.2.12 Started
Jan 17 23:10:49 alpha motion: [0] Created process id file /var/run/motion/motion.pid. Process ID is 5440
Jan 17 23:10:49 alpha motion: [0] Motion running as daemon process
Jan 17 23:10:49 alpha motion: [0] ffmpeg LIBAVCODEC_BUILD 3482112 LIBAVFORMAT_BUILD 3478528
Jan 17 23:10:49 alpha motion: [0] Thread 1 is from /etc/motion/trackcam1.conf
Jan 17 23:10:49 alpha motion: [0] Thread 2 is from /etc/motion/trackcam2.conf
Jan 17 23:10:49 alpha motion: [2] Thread 2 started
Jan 17 23:10:49 alpha motion: [2] cap.driver: "uvcvideo"
Jan 17 23:10:49 alpha motion: [2] cap.card: "UVC Camera (046d:0807)"
Jan 17 23:10:49 alpha motion: [2] cap.bus_info: "usb-0000:01:07.0-1"
Jan 17 23:10:49 alpha motion: [2] cap.capabilities=0x04000001
Jan 17 23:10:49 alpha motion: [1] Thread 1 started
Jan 17 23:10:49 alpha motion: [2] - VIDEO_CAPTURE
Jan 17 23:10:49 alpha motion: [2] - STREAMING
Jan 17 23:10:49 alpha motion: [2] Test palette MJPG (960x720)
Jan 17 23:10:49 alpha motion: [2] Adjusting resolution from 960x720 to 800x600.
Jan 17 23:10:49 alpha motion: [2] Using palet...

Read more...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.