Timeline for Ensure that cron daemon stays running
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 24, 2016 at 11:37 | comment | added | Otheus |
JdeBP Regardless of what year it is, a working system that works is valuable when the alternatives offer very little benefit and require an additional learning curve on the part of the user. In this case, for only ensuring crond, using the existing sysvinit is more useful than installing a more complex system which the user has no experience with, or a script which itself may be buggy and turn into a resource hog. An upgrade to a non-sysvinit based system will surely solve his crond problem, but then create numerous other transition challenges.
|
|
| May 24, 2016 at 11:24 | comment | added | Otheus |
@rubo77 I claim no knowledge of Debian's update path, but as long as your system is running sysvinit, it is update-safe. If you upgrade versions of Debian, chances are it will come packaged with a more advanced process management system, such as upstart or systemd. At least with systemd, this problem will solve itself -- it will make sure crond stays running for you (at least, that's a capability systemd offers).
|
|
| May 21, 2016 at 10:45 | comment | added | JdeBP |
Favouring /etc/inittab over proper service management is rather foolish in 2016. /etc/inittab is a thing of the past; and, for the reasons that rubo77 alludes to, using it won't even survive an upgrade to the current Debian 8. The ever-growing logfile is equally as bad an idea in 2016. We've long-since learned better than that, too.
|
|
| May 18, 2016 at 11:54 | comment | added | rubo77 | Will this be update safe? | |
| May 18, 2016 at 11:48 | history | answered | Otheus | CC BY-SA 3.0 |