Bug 736988 - Provide native systemd service file
Summary: Provide native systemd service file
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: zoneminder
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 755301 (view as bug list)
Depends On:
Blocks: SysVtoSystemd
TreeView+ depends on / blocked
 
Reported: 2011-09-09 09:04 UTC by Jóhann B. Guðmundsson
Modified: 2012-12-16 15:42 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-26 00:57:20 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
tmpfile for zonemanager (33 bytes, text/plain)
2011-09-09 09:08 UTC, Jóhann B. Guðmundsson
no flags Details
logrotate file for zoneminder (164 bytes, text/plain)
2011-09-09 09:49 UTC, Jóhann B. Guðmundsson
no flags Details

Description Jóhann B. Guðmundsson 2011-09-09 09:04:49 UTC
Description of problem:

Let's get the ball rolling on this one...

http://fedoraproject.org/wiki/Features/SysVtoSystemd

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Jóhann B. Guðmundsson 2011-09-09 09:08:54 UTC
Created attachment 522279 [details]
tmpfile for zonemanager

Takes care off....

        #Make sure the directory for our PID folder exists or create one.
        [ ! -d $pidfile ] \
                && mkdir -m 774 $pidfile \
                && chown $ZM_WEB_USER:$ZM_WEB_GROUP $pidfile
        #Make sure the folder for the socks file exists or create one

Comment 2 Jóhann B. Guðmundsson 2011-09-09 09:19:29 UTC
Ok so first bug found.. 

Sep  9 08:00:34 valhalla systemd[1]: zoneminder.service: main process exited, code=exited, status=255
Sep  9 08:00:35 valhalla zmdc.pl[12902]: Bareword "PROT_READ" not allowed while "strict subs" in use at /usr/share/perl5/vendor_perl/ZoneMinder/Memory/Mapped.pm line 91.
Sep  9 08:00:35 valhalla zmdc.pl[12902]: Bareword "PROT_WRITE" not allowed while "strict subs" in use at /usr/share/perl5/vendor_perl/ZoneMinder/Memory/Mapped.pm line 91.
Sep  9 08:00:35 valhalla zmdc.pl[12902]: Bareword "MAP_SHARED" not allowed while "strict subs" in use at /usr/share/perl5/vendor_perl/ZoneMinder/Memory/Mapped.pm line 91.
Sep  9 08:00:35 valhalla zmdc.pl[12902]: Compilation failed in require at /usr/share/perl5/vendor_perl/ZoneMinder/Memory.pm line 120.
Sep  9 08:00:35 valhalla zmdc.pl[12902]: Compilation failed in require at /usr/share/perl5/vendor_perl/ZoneMinder.pm line 37.
Sep  9 08:00:35 valhalla zmdc.pl[12902]: BEGIN failed--compilation aborted at /usr/share/perl5/vendor_perl/ZoneMinder.pm line 37.
Sep  9 08:00:35 valhalla zmdc.pl[12902]: Compilation failed in require at /usr/bin/zmdc.pl line 51.
Sep  9 08:00:35 valhalla zmdc.pl[12902]: BEGIN failed--compilation aborted at /usr/bin/zmdc.pl line 51.
Sep  9 08:00:35 valhalla systemd[1]: zoneminder.service: control process exited, code=exited status=255
Sep  9 08:00:35 valhalla systemd[1]: Unit zoneminder.service entered failed state.

/usr/share/perl5/vendor_perl/ZoneMinder/Memory.pm

Changing line 118 

if ( "yes" eq 'yes' ) # 'yes' if memory is mmapped

to

if ( "no" eq 'yes' ) # 'yes' if memory is mmapped

Fixes that...

Comment 3 Jóhann B. Guðmundsson 2011-09-09 09:48:55 UTC
Second bug found 

Can't open log file '/var/log/zm/zmupdate.log': No such file or directory at /usr/share/perl5/vendor_perl/ZoneMinder/Debug.pm line 279.

You should add to rsyslog.conf

# Save ZoneMinder messages to zm.log
local1.*                        /var/log/zm/zm.log

and either add or make note of adding local1.!* to /var/log/messages line to ensure all messages go into that log file ( as opposed to both places ) 

*.info;local1.!*;mail.none;news.none;authpriv.none;cron.none     /var/log/messages

for some reason there exist zonemanager directory in /var/log which is probably meant to be zm not zonemanager

Comment 4 Jóhann B. Guðmundsson 2011-09-09 09:49:25 UTC
Created attachment 522287 [details]
logrotate file for zoneminder

Comment 5 Jóhann B. Guðmundsson 2011-09-09 10:38:39 UTC
Now two things 

The legacy init scripts calls zmpkg.pl we doing that results in the systemd shutting down again allthou that might be because I dont have any camera hooked up to the system?

As in the current unit file i'm using results in

09/09/2011 10:28:32.485464 zmdc[16205].INF [Server starting at 11/09/09 10:28:32]
09/09/2011 10:28:35.673063 zmdc[16205].INF ['zmfilter.pl' starting at 11/09/09 10:28:35, pid = 16232]
09/09/2011 10:28:35.844888 zmdc[16205].INF ['zmaudit.pl -c' starting at 11/09/09 10:28:35, pid = 16239]
09/09/2011 10:28:35.996401 zmdc[16205].INF ['zmwatch.pl' starting at 11/09/09 10:28:35, pid = 16248]
09/09/2011 10:28:36.161502 zmdc[16205].INF ['zmupdate.pl -c' starting at 11/09/09 10:28:36, pid = 16255]
09/09/2011 10:28:36.317200 zmdc[16205].INF ['zmfilter.pl ' stopping at 11/09/09 10:28:36]
09/09/2011 10:28:36.320619 zmdc[16205].INF ['zmfilter.pl ' exited, signal 14]
09/09/2011 10:28:36.320828 zmdc[16205].INF ['zmwatch.pl ' stopping at 11/09/09 10:28:36]
09/09/2011 10:28:36.322448 zmdc[16205].INF ['zmwatch.pl ' exited, signal 14]
09/09/2011 10:28:36.322665 zmdc[16205].INF ['zmaudit.pl -c' stopping at 11/09/09 10:28:36]
09/09/2011 10:28:36.324425 zmdc[16205].INF ['zmaudit.pl -c' exited, signal 14]
09/09/2011 10:28:36.324604 zmdc[16205].INF ['zmupdate.pl -c' stopping at 11/09/09 10:28:36]
09/09/2011 10:28:36.326722 zmdc[16205].INF ['zmupdate.pl -c' exited, signal 14]
09/09/2011 10:28:46.533590 zmdc[16205].INF [Server shutdown at 11/09/09 10:28:46]


So we might be forced to create seperate unit files for each of the 

my @daemons = (
        'zmc',
        'zma',
        'zmf',
        'zmfilter.pl',
        'zmaudit.pl',
        'zmtrigger.pl',
        'zmx10.pl',
        'zmwatch.pl',
        'zmupdate.pl',
        'zmtrack.pl'
);

and tie it to an zoneminder target or zoneminder service wants directory's 

If the above is expected behaviour of non camera hooked up system then you can just ignore this.

Which leaves the second item on the list.. 

What's exactly happening here?

        [ ! -d $ZM_PATH_SOCK ] \
                && mkdir -m 774 $ZM_PATH_SOCK \
                && chown $ZM_WEB_USER:$ZM_WEB_GROUP $ZM_PATH_SOCK

Well it's pretty obvious what it does it calls fetches /tmp/zm and creates the directory and chowns it to apache but for what as in what kind of socket are we talking about here?

Comment 6 Jason Tibbitts 2011-09-09 16:45:36 UTC
You kind of picked the wrong time to do this; there are various things I am fixing with the package at this very moment which interfere with what you are doing.  I will consider this systemd stuff only after the package actually works properly.

Comment 7 Jóhann B. Guðmundsson 2011-09-09 17:00:20 UTC
Hum in what way is it interfering ?

Comment 8 Jason Tibbitts 2011-09-09 17:07:32 UTC
Things like the default log location being wrong because the package build process is overwriting modifications made in the spec.

Comment 9 Jason Tibbitts 2011-09-16 04:44:41 UTC
OK, the package has been updated to fix the extant issues so I can look at this.  It's possible that I've fixed some issues which interfered with your startup, so I would recommend starting over (including dropping the zm database, since I've made changes to the default configuration values loaded into the database) if you want to do further work on this.

zmpkg.pl is the intended way to start up the zoneminder daemons and I'd definitely not be comfortable in trying to bypass that.  I'm not sure why this means of starting up a set of daemons would be problematic, though.  Everything should start up just fine (and stay running) without any cameras configured.  The daemons stay running in the background and immediately fire off additional monitoring daemons as you configure cameras.  I do not think it would be reasonably possible to duplicate this arrangement without using the proper upstream method of spawning things.

The ZM_PATH_SOCK thing is somewhat annoying.  The directory is owned by the package and should have the proper permissions on install so it is indeed completely pointless for the initscript to create it.  It also doesn't hurt anything, and the initscript comes from upstream so we felt it was better to just leave it instead of introducing a pointless deviation from upstream.  But what makes it worse is that it's actually a runtime configurable, which is why the initscript pulls the value out of the database.

Honestly I'd be happy to just say that if the end user really wants to change the value, they're responsible for making sure that the directory exists.  They would have to fix up selinux contexts in any case (assuming that policy ever gets written).

There's also a /tmp/zm directory that zmpkg.pl makes; I need to look at what it would take to move that.  So far I've not seen anything in the system actually use it but it should really be in /var/lib/zoneminder/temp (which already exists).

Comment 10 Jason Tibbitts 2011-11-20 15:23:08 UTC
*** Bug 755301 has been marked as a duplicate of this bug. ***

Comment 11 Jason Tibbitts 2012-02-26 00:57:20 UTC
Current version in rawhide has been converted to systemd.  Turned out to be substantially trivial.

[Unit]
Description=Video security and surveillance system

[Service]
Type=forking
ExecStart=/usr/bin/zmpkg.pl start
ExecReload=/usr/bin/zmpkg.pl reload
PIDFile=/run/zoneminder/zm.pid

[Install]
WantedBy=multi-user.target

Not sure at this point if I should pull this all into F17.

Comment 12 Briago 2012-12-16 15:42:48 UTC
I suggest to pull into F17.  I did a fresh install on Fedora 17.  I used the yum install for zoneminder (not from source).  After enabling HTTPD, MYSQL, and Zoneminder for auto startup, Zoneminder is being run from init.d, while MYSQL is run from systemd.  As a result, mysql is not ready when zoneminder is started and zoneminder fails every time.
"ERROR 2002 *HY000): Can't connect to local MySQL server through socket ..."

After bootup, if I start manually after startup, there is no issue.


Note You need to log in before you can comment on or make changes to this bug.