motion starts on install and stalls upgrades

Thanks for reporting this bug.

To help diagnose the problem please attach the files in the directory /var/log/dist-upgrade/
Specifically:
 * main.log
 * apt.log
 * term.log

Thanks!

After killing motion, the process goes on normally then the running wine-doors reports an error and quits, right after that and after update-initramfs, the upgrade reports an "error where encountered while processing: motion" and stalls at "IOError: [Errno 9] Bad file descriptor". I waited and then pressed ctrl-c and the upgrade continued. It is currently cleaning up.

I am including the logs up to this point.

It happens too on 8.04 downloading and installing it via synaptic.

I also had to kill motion - it was in a continuous loop of grabbing pictures from the web cam. Once I killed it the dist-upgrade from 7.10 to 8.04 seems to have gone OK. But I'm just going to reboot now...

From the attached main.log:
2008-04-25 08:53:43,580 WARNING no activity on terminal for 240 seconds (Configuring motion)
2008-04-25 09:29:01,568 ERROR got an error from dpkg for pkg: 'motion': 'subprocess post-installation script killed by signal (Interrupt)

It was indeed running for a while without response. Attached here (as motion.log) is the relevant portion of the term.log

I did not have an issue of installing it in Hardy, but I do not have a webcam attached to this computer.

From one of the duplicates:
-----
Geoff Hickey:
I ran into this also. You can reproduce it without running an upgrade though: just install motion with a webcam plugged in. If the default settings in the new /etc/motion.conf script installed with the package will work with the webcam, the process won't return. It looks like the default should be changed to "daemon yes".

This borked my upgrade as well on a HP Pavillion dv2410us laptop with built-in webcam.

I'd suggest that the upgrade check first and refuse to install if this package is installed.

The upgrade manager issue a warning about the system being potentially unstable and it attempting to roll back, just before it died. Since this isn't a hypercritical partition, I just rebooted and the system seems basically usable, but I have no way of telling what problems are lurking.

BTW, the config process seems to be starting the normal video motion detection server. For folks who don't have anything plugged in to their video port (or have their built-in cam covered or turned off), it will look like it's just hung, but on mine whenever I moved, it spit out JPEG frames to the tmp directory.

It happened to me on 8.04 installing it via synaptic (I was not upgrading Ubuntu, just installing the package). It hangs in the postinst script. There is no pid file created. motion does not daemonize.

Subscribing motu-sru for their approval.

This bug is closely related to #235599, where the question is raised whether motion should start as a server on startup without telling the user.

I updated motion for this bug. Attached is the debdiff. When this is applied, motion will by default daemonize. That way an upgrade won't be halted anymore.

Changelog:

motion (3.2.9-1ubuntu1) hardy; urgency=low

  * motion now starts in daemon mode (LP: #198292)
  * creation of PID file now successful (LP: #198292)
  * bump to compat version 6
  * Set Maintainer to Ubuntu Core Developers and move original
    Maintainer to XSBC-Original-Maintainer

Attached is the same debdiff, but this time with a more appropriate version number (3.2.9-1ubuntu0.1). For the development release I will not supply a debdiff. The bug is fixed upstream in the versions concerned (Debian bug 461763).

Hello,

This bug report requires further work before it can be approved for a stable release update.

1. The patch must only make the minimal changes necessary to fix the bugs that meet the SRU criteria. So, for example you won't bump the standards version.
2. You don't need to list the bug number twice in the changelog or did you mean one to be Bug #235599?
3. Your changelog needs to be more descriptive (such as listing the file each change affects and what you're actually changing in addition to what the change does).
4. How does the two changes you made fix this bug? Please post a comment here in this bug with a *verbose* description.
5. What is the regression potential? Have you tested that your changes build in hardy. the package you produce installs, and the bug is fixed?
6. The test case is unclear.

"TEST CASE:
1. install hardy"
>> You have to install Hardy from scratch to reproduce this bug?

"2. get a supported webcame that shows as /dev/video0"
>> Do you plug it in? Do you have to configure it? How do you verify it shows as '/dev/video0'?

"3. run "sudo apt-get install motion"
4. watch it hang

5. repeat steps 1-3
6. verify that it does not hang after step 3"
>> You don't have to apply the patch to fix the issue - just install a second time?

Thanks for the responses.

I uploaded a fix for this a couple of days ago, but failed to set the bugreport to fix commited (sorry for that). It was waiting in the unapproved queue since. I attach the debdiff for the upload now.

@Cody: Thanks for reviewing the verification instructions, those are indeed not good, I will update them.

I updated the test case to the best of my knowledge, I don't have the required hardware but I think its enough to plug the webcam in.

Accepted motion/3.2.9-1ubuntu1 into hardy-proposed, please test.

I grabbed 3.2.9-1ubuntu1 from hardy-proposed, but I ran into a couple of problems.

First, if I install it after purging the old version (3.2.9-1), it works ok, except that it still fails to create a PID file in /var/run. I'm not sure why. But the process does daemonize and I verified that it's working, i.e., detecting motion and producing jpgs and swfs in /tmp/motion. Also /etc/init.d/motion can stop and restart it properly.

Second, if I upgrade from 3.2.9-1 without uninstalling the old version, it doesn't restart the motion process. This is because the old /etc/init.d/motion script fails to shut down the old daemon, because the PID file never got created. Here's the output from the upgrade:

Preparing to replace motion 3.2.9-1 (using .../motion_3.2.9-1ubuntu1_i386.deb) ...
Stopping motion detection : motion
No /usr/bin/motion found running; none killed.
.
Unpacking replacement motion ...
Setting up motion (3.2.9-1ubuntu1) ...
Installing new version of config file /etc/init.d/motion ...
Starting motion detection : motion
/usr/bin/motion already running.
.

Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done

I'm happy to do more testing if it will help.

I install ubuntu 8.04 from scratch and I realized that motion cannot create pid file because it run with user "motion" not root so it has not the privilegies to create a file in directory /var/run.

So I modified the init script adding the following line before to start the daemon:

touch $PIDFILE && chown motion $PIDFILE

it create the pidfile and give motion the ability to modify it with its pid.

I think it is the simplest and effective fix.

I think that the fix proposed by Michael Vogt is bad because it eliminates the pidfile. It limits the powerful of the script (status is drop off)

Best Regards

Michael Vogt's fix is a quick-and-dirty hack which I think is good, because:

- it is the minimal solution as required for SRU fixes
- it resembles the (agreed: dirty) fix done in upstream future versions and queued for Intrepid.

Geoff Hickey mentions an upgrade problem (3.2.9-1 to Michael Vogt's 3.2.9-1ubuntu1): there is no restart. I'm not sure whether that need be solved here (please confirm). Most important is: installation and upgrade do not hang. Michael Vogt's fix makes it so by simply forcing daemonization from the init script.

I tested the fix on Hardy for:
a. install from hardy-proposed after purge
b. upgrade from 3.2.9-1 while it runs in background
c. upgrade from 3.2.9-1 while it does not run
Result: no hang in either case.

So I probably Michael's is a good fix for SRU.

The init script problems (pid file / restart problems) should be ideally be done upstream (please confirm).

Yeah, stepan, your fix would work just fine, but I'd much rather motion start as its own user. From a security standpoint, it just makes sense.

I customized the init script on my install for motion, and it more or less does what mouz's patches do, so it wouldn't be appropriate for SRU. In other words, motion can still start as its own user, but it has its own /var/run/motion directory to write to for its pid file so that it doesn't have to run as root (a little like how Tor is setup).

The other thing that I did (which is different from mouz's patch) was that I created a separate config file for motion as a startup daemon in /etc/motion/motiond.conf. This way, individual users can still run motion normally (i.e. not as a daemon), and thus allaying any unintended side effects for that use case.

I think that these kind of fixes are the most appropriate for the long term.

Given that the original bug report was about an upgrade from 7.10, I don't think the test case here is correct because it only tests upgrades from the hardy to the hardy-proposed version, not from the gutsy to the hardy-proposed version. Given that there are reports that the hardy->hardy-proposed upgrade does *not* work, and no reports about the gutsy upgrade, I'm dropping the 8.04.1 milestone here - the package can be copied to hardy-updates once someone can verify it.

The revised package appears to still have problems.

However, there is a newer upstream version available. I've taken the opportunity to repackage and bug-fix it. It is available from my PPA for Intrepid, Hardy, Gutsy and Feisty:

http://ppa.launchpad.net/intuitivenipple/ubuntu

motion (3.2.10.1-0ubuntu1~ppa3) hardy; urgency=low

  * Fixed init script not running process in background (default /etc/motion/motion.conf
     had "daemon off" via an inherited debian/rules command
  * Fixed init script override for location of PID file running as non-root (/var/run/motion)
     so it doesn't rely on the init script location coinciding with the setting in
     /etc/motion/motion.conf

 -- TJ <email address hidden> Sun, 20 Jul 2008 16:30:00 +0100

motion (3.2.10.1-0ubuntu1~ppa2) hardy; urgency=low

  * Fixed 64-bit pointer-to-int conversions using C99's LP64 convention
  * Do not start daemon during installation
  * Converted package to use CDBS and simple-patchsys

 -- TJ <email address hidden> Sun, 20 Jul 2008 15:00:00 +0100

TJ, for the purpose of driving forward this bug fix, did you test that the version currently in hardy-proposed works for gutsy upgrades? If that's the case, we should move it to hardy-updates and start another SRU for the remaining problems you noticed.

If the "remaining problems" you had still apply to the gutsy->hardy-proposed upgrade, please be more specific. Thanks!

P.S. "Convert package to CDBS" -> not a change adequate for an SRU

@Martin:

Did not test a Gutsy upgrade. Tested hardy-proposed clean install to hardy (x86_64).

The proposed 'fix' of adding the -b (--background) switch to start-stop-daemon in /etc/init.d/motion for its 'start' case will only force the daemon to background the motion shell process - it doesn't deal with motion's specific behaviour of forking itself, which is what *should* happen.

The problem that causes motion to launch during installation is caused by the debian/rules binary-arch: "dh_installinit" statement which would need to pass the "--no-start" argument to avoid motion starting during install. This is a *good thing* to do since the generic '/etc/motion/motion.conf' may not be configured correctly for the system's video devices. Install will succeed when motion.conf is *incorrect* since motion will exit immediately.

The *reason* motion doesn't fork itself into the background is the debian/rules install: statement which uses sed to change the installed '/etc/motion/motion.conf' statement "daemon on" to "daemon off"

I packaged 3.2.10-1 (a security bug-fix release) simply because I wanted the latest version and found the latest 3.2.10-1 motion-supplied package suffers the same problems as this current Ubuntu package. At that time I didn't know about this bug. I found it here only after I'd finished packaging and building the new version.

I wasn't suggesting my changes/package were candidates for SRU but they're there if someone wants them.

Although adding CDBS on its own may not be a reason for an SRU, I'd suggest it *is* if it is needed to apply patches to the original source when the package currently has *no* patch system at all, and source-code patches need to be applied.

In this case I needed to fix a pointer-to-int conversion bug for 64-bit builds because motion makes extensive use of pointers converted to relative offsets of struct members in various 'struct context' memory spaces.

All the fixes I've done are fully described in my previous comment in the Changelog quotes.

On Mon, Jul 21, 2008 at 09:48:33AM -0000, TJ wrote:
> Although adding CDBS on its own may not be a reason for an SRU, I'd
> suggest it *is* if it is needed to apply patches to the original source
> when the package currently has *no* patch system at all, and source-code
> patches need to be applied.

No, there are much less intrusive ways to introduce patch systems in an SRU
that don't involve rewriting debian/rules. I don't think we would ever want
to accept such a deep package change in SRU.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

I tested the mvo's version in hardy-proposed (3.2.9-1ubuntu1) and found that it fixes the bug.

cool!

--- On Thu, 7/31/08, mouz <email address hidden> wrote:
From: mouz <email address hidden>
Subject: [Bug 198292] Re: Hardy upgrade - motion halts upgrade
To: <email address hidden>
Date: Thursday, July 31, 2008, 3:19 PM

I tested the mvo's version in hardy-proposed (3.2.9-1ubuntu1) and found
that it fixes the bug.

--
Hardy upgrade - motion halts upgrade
https://bugs.launchpad.net/bugs/198292
You received this bug notification because you are a direct subscriber
of the bug.

Fixed in Intrepid.

Copied to hardy-updates.