I think even better would be to learn how to use the drop-in configuration stuff that systemd features. That way, your changes won't be overwritten, but if the default service file gets updates, those changes will be reflected in what you are running.
I've wondered about this but what if a change is made which is not compatible with the change you've made? That is, using that functionality silently changes the configuration in ways which may or may not be consistent with my customisation. So I worry somewhat about this option even though I can see the attractions.
]]>The right way to do it is to copy cronie.service to /etc/systemd/system/cronie.service and edit the copy. That way, your changes will not be overwritten next time the package is updated.
I will do that instead then - thank you.
]]>Actually there is probably a newer, better way involving including the standard file but I've not figured out how to do that yet or what the dangers might be so I'm still using the /etc override method.
For example, I use:
$ cat /etc/systemd/system/cronie.service
[Unit]
Description=Periodic Command Scheduler
[Service]
ExecStart=/usr/bin/crond -n -s -m off
ExecReload=/usr/bin/kill -HUP $MAINPID
KillMode=process
Restart=always
[Install]
WantedBy=multi-user.target
Obviously you need to reenable and/or restart the service as appropriate after this.
]]>I am curious about how to edit the config that systemd is referencing for cronie. Currently trying to figure this out by reading https://wiki.archlinux.org/index.php/Cron .
Easy enough, just need to edit the `ExecStart` line found in /usr/lib/systemd/system/cronie.service directly, as follows:
kjones /usr/lib/systemd/system $ cat cronie.service
[Unit]
Description=Periodic Command Scheduler
[Service]
ExecStart=/usr/bin/crond -S
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always
[Install]
WantedBy=multi-user.target
and then
kjones /usr/lib/systemd/system $ sudo systemctl reload cronie
Now upon start I just have:
Jul 04 02:27:19 li431-203 systemd[1]: Started Periodic Command Scheduler.
Jul 04 02:27:19 li431-203 crond[6100]: (CRON) INFO (running with inotify support)
Jul 04 02:27:19 li431-203 crond[6100]: (CRON) INFO (@reboot jobs will be run at computer's startup.)
https://bugs.archlinux.org/task/31231
https://bugs.archlinux.org/task/30408
Does the /etc/conf.d/crond file has any effect at all when using systemd? The service file:
root@horus /usr/lib/systemd/system # cat cronie.service [Unit] Description=Periodic Command Scheduler [Service] ExecStart=/usr/sbin/crond -n ExecReload=/bin/kill -HUP $MAINPID Restart=always [Install] WantedBy=multi-user.target
No EnvironmentFile is set.
Osiris - I don't think do.
I have tried starting cronie with both the '-s' and -S' arguments, and seen no change in the output of my execution of `cat cronie.service`:
kjones /usr/lib/systemd/system $ cat cronie.service
[Unit]
Description=Periodic Command Scheduler
[Service]
ExecStart=/usr/bin/crond -n
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=always
[Install]
WantedBy=multi-user.target
I am curious about how to edit the config that systemd is referencing for cronie. Currently trying to figure this out by reading https://wiki.archlinux.org/index.php/Cron .
]]>root@horus /usr/lib/systemd/system # cat cronie.service
[Unit]
Description=Periodic Command Scheduler
[Service]
ExecStart=/usr/sbin/crond -n
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
[Install]
WantedBy=multi-user.target
No EnvironmentFile is set.
]]>riccardo wrote:cfr wrote:/etc/syslog-ng.conf?
apropos syslog
yes
does this file "decide" all level log of the system?
apropos syslog
understood
Thank you.
Riccardo
EDIT just checked and yes, I'm using dcron.
]]>cfr wrote:/etc/syslog-ng.conf?
apropos syslog
yes
does this file "decide" all level log of the system?
apropos syslog
Is it possible that we are using different implementations? That is, I'm using cronie but dcron also provides crond.
From man crond:
SYNOPSIS
crond [-n | -p | -s | -c | -m<mailcommand>]
crond -x [ext,sch,proc,pars,load,misc,test,bit]
and:
OPTIONS
-m This option allows you to specify a shell command to use for sending Cron mail output instead of using
sendmail(8) This command must accept a fully formatted mail message (with headers) on standard input and
send it as a mail message to the recipients specified in the mail headers. Specifying the string off (i.e.
crond -m off) will disable the sending of mail.
-n Tells the daemon to run in the foreground. This can be useful when starting it out of init.
-p Allows Cron to accept any user set crontables.
-c This option enables clustering support, as described below.
-s This option will direct Cron to send the job output to the system log using syslog(3). This is useful if
your system does not have sendmail(8), installed or if mail is disabled.
-x This option allows you to set debug flags.
I do use cron and "-S" is *not* in the man page. The man page gives the option as "-s" and that gets rid of the EXEC FAILED option in my case.
Interesting as both -s and -S are in my crond man page:
-s dir directory of system crontabs (defaults to /etc/cron.d)
-S log events to syslog, using syslog facility LOG_CRON and identity `crond' (this is the default behavior).
/etc/syslog-ng.conf?
apropos syslog
yes
does this file "decide" all level log of the system?
thank you
riccardo
apropos syslog