Re: [Motion-user] Problem/Question With Daemon Mode

[Jason S. <jas...@gm...>]

Thank you for your response. I think I was actually overcomplicating the
entire scenario, mostly based on the fact that I was misunderstanding a lot
of how Motion was set up to work.

Ultimately, this is what I found out. I have no idea what the daemon
functionality is in motion.conf where it mentions background mode. No idea
there... so I left that alone. But what I did was I went into the Motion
IRC and some users helped me out there. The bottom line is, the daemon in
/etc/default/motion is the money shot... that's what I need... By
installing Motion, it also installs the user named simply "Motion" (which I
wasn't aware of at the beginning). On top of that, it plugs a new service
in the mix that automatically starts up *IF* /etc/default/motion is set to
"yes". Once I adjusted the daemon to "yes" and rebooted, things were
working, but I had no idea they were *actively* working since I was getting
no new feeds. Why? Because the user Motion didn't have the rights to save
to the target_dir. *Facepalm*

My problem was I was spending a lot of time trying to run Motion as a
NON-root user, such as myself. That's where I ran into the permissions
issues on /var/run/motion. Fun fact - /var/run in Ubuntu is a tmpfs, so
each time I reboot it gets wiped... therefore wiping whatever permissions
changes I made to /var/run/motion.

So once I realized that a user Motion existed and that's the user that is
"called on" when Motion starts up automatically, I was good to go. The
other curve ball is of course the save location (target_dir) that I
mentioned above. Once Motion had write access, I was golden. I also
realized that the Motion service is like any other service. I can simply do
a:

sudo /etc/init.d/motion restart

And Motion restarts accordingly. I had feared that maybe it would run as
root if I did that, but my feeds are coming down saved as motion:motion
with permissions open enough that even my user "jason" can read them to
view back the feeds just fine. If I recall, they're 644, but I'll have to
recheck. Doesn't really matter I suppose... Jason can access them which is
the goal. ;)

Sorry about the novel, but I figured it was important to explain what I
found as my fix, which was simply reading the manual and having a short
discussion with other Motion users. This program is working absolutely
beautifully now. I just had to slow it down and read the manual a little
more thoroughly. On a slightly funnier note, Motion has successfully
documented my slip and fall the other day with a full plate of just-made
hamburgers, and on top of that it has brought to my attention that I have 3
kittens living under my ground level deck... Anybody in PA, USA want a
little furry kid? ;)

Thanks again guys! I really appreciate it.

On Wed, May 30, 2012 at 1:33 PM, Jason Sauders <jas...@gm...> wrote:

> I was tinkering with Motion this afternoon on my Ubuntu 12.04 64 bit
> server and noticed something weird. I wanted to enable daemon mode so I can
> kill the process and restart it if need be without restarting the server.
>
> Currently /etc/default/motion is set to "yes" for daemon mode, and
> /etc/motion/motion.conf is set to "off" for daemon mode. Within startup
> applications I have a custom job that auto launches Motion when my user
> logs in. It works great with no issue.
>
> If I enable the daemon mode entry in /etc/motion/motion.conf, it comes
> back with a permission denied error regarding the PID. By looking in the
> path, /var/run/motion is 755 motion:motion, so I have to assume I'm trying
> to launch it as a regular user (myself) which is causing it to foul up.
>
> Is this typical behavior? Is it intended to have the daemon mode entry in
> motion.conf yet you still have to edit permissions in order to actually
> initialize the motion process? Granted I suppose I could add my user to the
> Motion group and 775 it to get it to work, but I just wanted to make sure
> what I'm looking at is intentional and not some sort of a bug or problem.
>
> Thanks guys!
>