Elias, Thanks for your opinion. The file "otrs.service" which I attached, has written to leverage files currently exists. The way you shows sounds better to take advantage of the features of systemd. It would be also good for the future. I'll also try to improve that. 2015-04-30 15:17 GMT+09:00 Elias Probst :

This service unit just executes as a oneshot "Cron.sh".

The IMHO proper solution would be instead to create "timer units" [1] which do whatever the old cron jobs did and to ingore Cron.sh (or only use it to enable the respective timer units) on systemd based systems.

The OTRS Scheduler would then be started as a regular (Type=simple) systemd service, for which a service unit still needs to be created.

On top of that, it might make sense to make the Scheduler "systemd aware" (using Systemd::Daemon), so the fragile PIDfile/timeout-based self-health check of the Scheduler could be disabled when running under systemd and the Scheduler could use Systemd::Daemon->notify() [2] instead to let systemd know about it's status (which is a nice addon on top of systemd's own process monitoring).

Another nice systemd-related addition could be support to log to journald [3] instead of SysLog/File.

[1] http://www.freedesktop.org/software/systemd/man/systemd.timer.html [2] http://www.freedesktop.org/software/systemd/man/sd_notify.html [3] http://0pointer.de/blog/projects/journalctl.html

Best regards Elias

On 12/30/2014 04:22 AM, Hisatoshi Onishi wrote:

...

Hi all,

I found the script file "/etc/init.d/otrs" won't work well which includes in RPM package for RHEL7/CentOS7.

For detail, value of $OTRS_USED_WEBSERVER_TEST in "/etc/sysconfig/otrs" is not effective. Because RHEL7/CentOS7 has changed to systemd, so output message also does.

Normal solution for this is modify script file to fit. But, most of Linux distributions might be shift too. I wrote very simple script file for systemd as a prototype. Because of focused only for start or stop (registering or deleting cron jobs of OTRS running user), functions below doesn't include. - Check existing/size for various files. - Web server running check if enabled. - DB server connecting check. - Cleanup spooled messages with sending mail.

It has omitted any other servers running check since it depends on the environment. But, it must require such as httpd+mariadb.

I'll attach in this mail because I don't know what repository this must be classified. Please place it under directory "/usr/lib/systemd/system". Permission for executing is not required.

If target ML is wrong, please notify.

-- Hisatoshi Onishi E-Mail: hisatoshi.onishi@gmail.com mailto:hisatoshi.onishi@gmail.com

_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev

_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev

-- Hisatoshi Onishi E-Mail: hisatoshi.onishi@gmail.com

Hello All, Also please consider that OTRS 5 will not use all the CronJobs as OTRS 4 and before, a new Scheduler daemon will take care to handle all this repetitive tasks like close pending tickets, escalations, delete old cache and sessions, etc. Only the a CronJob to make sure the Scheduler and other daemons are running will be executed. ((enjoy)) Carlos Rodríguez

On Apr 30, 2015, at 1:17 AM, Elias Probst wrote:

This service unit just executes as a oneshot "Cron.sh".

The IMHO proper solution would be instead to create "timer units" [1] which do whatever the old cron jobs did and to ingore Cron.sh (or only use it to enable the respective timer units) on systemd based systems.

The OTRS Scheduler would then be started as a regular (Type=simple) systemd service, for which a service unit still needs to be created.

On top of that, it might make sense to make the Scheduler "systemd aware" (using Systemd::Daemon), so the fragile PIDfile/timeout-based self-health check of the Scheduler could be disabled when running under systemd and the Scheduler could use Systemd::Daemon->notify() [2] instead to let systemd know about it's status (which is a nice addon on top of systemd's own process monitoring).

Another nice systemd-related addition could be support to log to journald [3] instead of SysLog/File.

[1] http://www.freedesktop.org/software/systemd/man/systemd.timer.html http://www.freedesktop.org/software/systemd/man/systemd.timer.html [2] http://www.freedesktop.org/software/systemd/man/sd_notify.html http://www.freedesktop.org/software/systemd/man/sd_notify.html [3] http://0pointer.de/blog/projects/journalctl.html http://0pointer.de/blog/projects/journalctl.html

Best regards Elias

On 12/30/2014 04:22 AM, Hisatoshi Onishi wrote:

...

Hi all,

I found the script file "/etc/init.d/otrs" won't work well which includes in RPM package for RHEL7/CentOS7.

For detail, value of $OTRS_USED_WEBSERVER_TEST in "/etc/sysconfig/otrs" is not effective. Because RHEL7/CentOS7 has changed to systemd, so output message also does.

Normal solution for this is modify script file to fit. But, most of Linux distributions might be shift too. I wrote very simple script file for systemd as a prototype. Because of focused only for start or stop (registering or deleting cron jobs of OTRS running user), functions below doesn't include. - Check existing/size for various files. - Web server running check if enabled. - DB server connecting check. - Cleanup spooled messages with sending mail.

It has omitted any other servers running check since it depends on the environment. But, it must require such as httpd+mariadb.

I'll attach in this mail because I don't know what repository this must be classified. Please place it under directory "/usr/lib/systemd/system". Permission for executing is not required.

If target ML is wrong, please notify.

-- Hisatoshi Onishi E-Mail: hisatoshi.onishi@gmail.com mailto:hisatoshi.onishi@gmail.com mailto:hisatoshi.onishi@gmail.com>

_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev http://lists.otrs.org/cgi-bin/listinfo/dev

_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev http://lists.otrs.org/cgi-bin/listinfo/dev

Hi David, Probably I didn’t get the point, the new architecture of OTRS will enable the scheduler to perform different kind of tasks that are currently delegated to Cron and other parts of OTRS itself, in OTRS 5 you will only need to monitor the process that controls the scheduler is up and running to make sure that the service will be working. For sure you still need to monitor you http server and your DB. You will get more details about the new scheduling mechanism and other new features when OTRS 5 Beta 1 gets GA. ((enjoy)) Carlos Rodríguez

On May 5, 2015, at 7:56 AM, David Boyes wrote:

*sigh*

This approach really makes it tedious to do comprehensive/predictive monitoring of the OTRS services from a central point. Do you *really* need to invent your own job scheduler? Yes, there are limitations to cron, but it’s one big piece of scripting to get Yet Another Workload Scheduler tied into a decent monitor.

Also please consider that OTRS 5 will not use all the CronJobs as OTRS 4 and before, a new Scheduler daemon will take care to handle all this repetitive tasks like close pending tickets, escalations, delete old cache and sessions, etc. Only the a CronJob to make sure the Scheduler and other daemons are running will be executed.

_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev http://lists.otrs.org/cgi-bin/listinfo/dev