Bug 216466 - Incorrect rc.d startup script for multimedia/motion
Summary: Incorrect rc.d startup script for multimedia/motion
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Jason E. Hale
Depends on:
Reported: 2017-01-25 21:25 UTC by bakhur
Modified: 2017-02-18 15:18 UTC (History)
3 users (show)

See Also:

motion rc.d startup script (529 bytes, text/plain)
2017-01-27 09:31 UTC, bakhur
no flags Details
Fix motion.conf location & add netcam only support (4.64 KB, patch)
2017-01-28 11:47 UTC, Jason E. Hale
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description bakhur 2017-01-25 21:25:55 UTC
Good day.
FreeBSD 11.0-Release-p1

The "motion" daemon didn't use the config file "/usr/local/etc/motion.conf" after default package installation.
If you set motion_enable="YES", "motion" uses default settings, and OS failed to boot if there is no /dev/bktr0 device in the system, because "motion" permanently trying to get access to /dev/bktr0.
You have to add: command_args="-c /usr/local/etc/motion.conf" in rc.d startup script to fix this error.
Also there is no possibilities to compile "motion" from ports without using BKTR or PWCBSD capture drivers. You get an error message about wrong config. But it would be necessary for using "motion" only with network cameras.
Comment 1 bakhur 2017-01-25 21:31:43 UTC
P.S.: I am using motion to capture video from rtsp stream to mpeg video files.
Comment 2 bakhur 2017-01-27 08:01:38 UTC
Also I would note that adding command_args="-c /usr/local/etc/motion.conf" to the rc.d startup script won't prevent to fail OS boot if you won't comment "videodevice /dev/bktr0" in the motion.conf in situation when you have no real connected hardware camera device. I think it would be nice to comment this string in the motion.conf by default and let to choose camera device to user after motion installation.
Comment 3 bakhur 2017-01-27 09:31:09 UTC
Created attachment 179349 [details]
motion rc.d startup script
Comment 4 Jason E. Hale freebsd_committer 2017-01-28 11:47:50 UTC
Created attachment 179369 [details]
Fix motion.conf location & add netcam only support

Does this patch fix your issue?

1. Adjust the installation location of the motion.conf file to ${PREFIX}/etc/motion/motion.conf. I think it makes more sense there since motion can make use of multiple camera configs that should be stored there as well. I'll compose an UPDATING message to tell users to move their current configs.

2. Switch the video driver options to OPTIONS_RADIO so that they can all be disabled which would allow for netcam only support.

3. Merged in a patch from bug #216189 to fix a netcam connection issue.

4. There was some bad logic in configure.ac that was not enabling V4L for the PWCBSD driver.
Comment 5 bakhur 2017-01-29 09:47:18 UTC
Good day.
Separate motion config location and enabling netcam-only support sounds great. Thanks!
What about rc.d startup script? As I told, the "motion" daemon didn't use the config file "/usr/local/etc/motion.conf" after default package installation? Anyway I have this trouble in my installation.
Comment 6 Jason E. Hale freebsd_committer 2017-01-29 10:08:28 UTC
(In reply to bakhur from comment #5)

My understanding is that motion.conf should go in ${LOCALBASE}/etc/motion/ and I adjusted the rc.d script to look for the file there. You should move your motion.conf to the new location.
Comment 7 Tim Bishop freebsd_committer 2017-01-29 10:12:57 UTC
(In reply to Jason E. Hale from comment #6)

I was wondering whether the rc.d script and installation should be changed to point to ${LOCALBASE}/etc/motion/motion.conf, or whether motion should be changed to look for ${LOCALBASE}/etc/motion.conf.

The first would go with what motion expects and probably be more inline with other operating systems.

The second would be consistent with how the motion port worked in the past which would avoid breaking installations for existing users. Assuming a 3.x config works on 4.x?
Comment 8 Jason E. Hale freebsd_committer 2017-01-29 10:37:34 UTC
(In reply to Tim Bishop from comment #7)

I think option 1 makes the most sense considering multiple camera configs can be used and it would be best to have everything grouped neatly in a subdirectory. It is more inline with what other ports do. I realize it would somewhat break existing installations, but I don't think forcing old behavior is correct. An UPDATING entry should suffice.
Comment 9 Tim Bishop freebsd_committer 2017-01-29 10:48:01 UTC
(In reply to Jason E. Hale from comment #8)

Yes, I think you're right. I had a patch to that effect, but I hesitated when I thought about the other option. Your patch looks good to me.
Comment 10 commit-hook freebsd_committer 2017-01-30 00:10:10 UTC
A commit references this bug:

Author: jhale
Date: Mon Jan 30 00:09:54 UTC 2017
New revision: 432815
URL: https://svnweb.freebsd.org/changeset/ports/432815

  - Fix an issue where netcams were not connecting [1]
  - When motion was updated to 4.x, it was overlooked that the default
    search path for the configuration files was changed. This was causing
    existing configurations to not be read. Fix the port to install
    default configuration in correct location and add an UPDATING message
    giving users the proper instructions on where to place their existing
    conf files. [2]
  - Create an empty ${ETCDIR}/conf.d directory that can optionally be used
    to dump camera configs in instead of creating separate lines for each
    one in motion.conf
  - Add some missing PORTDOCS and install with the correct mode
  - Make the VIDEO options OPTIONS_RADIO instead of OPTIONS_SINGLE to
    allow for netcam only support (suggested in [2])
  - Fix bad logic in configure.ac that was causing V4L to not be dectected
    when the PWCBSD option was enabled

  PR:		216189 [1]
  Reported by:	Charles P <charlespigott@googlemail.com>
  Patched by:	<anthony@ury.org.uk>
  Obtained from:	upstream
  PR:		216466 [2]
  Reported by:	<bakhur@inbox.ru>, tdb@
  Pointy hat to:	jhale
  MFH:		2017Q1 (blanket)

Comment 11 Jason E. Hale freebsd_committer 2017-02-18 15:18:52 UTC
No further feedback received after r432815. Closing.