David, Great you figured it out, I have never seen that issue.
The "/usr/sbin/restore-basic-conf" (Basic Restore) script should preserve file permissions (uses tar) and via our web interface PHP has sufficient privileges to set root permissions. As a test, I generated a basic config via the web interface, renamed /mnt/kd/crontabs/root and then did a "Restore Basic" via the System tab, resulting in: -- # ls -l /mnt/kd/crontabs/ total 4 -rw------- 1 root root 358 Jul 26 10:45 root -- The original (backup) file permissions were preserved. User 1000 is not a standard user, but probably a manual "adduser". > I wonder if there are any other files created by restore basic configuration > that are sensitive to ownership? Prosody (XMPP) is sensitive to file ownership in /mnt/kd/ . A few others have 0600 permissions. Lonnie > On Jul 26, 2019, at 1:53 PM, David Kerr <da...@kerr.net> wrote: > > > > Lonnie, > Found the problem. The file /mnt/kd/crontabs/root had owner of "1000" in > group "root" > It appears that crond is sensitive to the file owner, so I did a chown to > change the owner to "root" and things started to work. > > Looking at my /mnt/kd, I found dozens of files that have 1000 as the owner. > I am guessing that when I did a restore basic configuration from the web > interface all the files were created by user 1000. > > I wonder if there are any other files created by restore basic configuration > that are sensitive to ownership? > > David > > On Fri, Jul 26, 2019 at 11:47 AM Lonnie Abelbeck <li...@lonnie.abelbeck.com> > wrote: > Hmmm... > > Using either "crontab -e" or the Edit tab and "Reload Cron for root" add this > line: > -- > * * * * * /bin/date >/tmp/foo > -- > If you are not seeing it /var/log/messages see if /tmp/foo exists. > > If /tmp/foo is created then it may be some logging issue. > > This works for me. I can't image what you have incorrect. > > Lonnie > > > > > On Jul 26, 2019, at 10:30 AM, David Kerr <da...@kerr.net> wrote: > > > > Hi Lonnie. > > Yes, crontab -l shows what I expect... > > > > pbx ~ # crontab -l > > ## > > ## logrotate - Do not remove, comment-out to disable > > 00 04 * * * /usr/sbin/logrotate /etc/logrotate.conf >/dev/null 2>&1 > > > > ## > > ## Fossil daily auto-commit - Do not remove, un-comment to enable > > 55 23 * * * /usr/bin/fossil-commit >/dev/null 2>&1 > > <cut off the rest> > > > > and yes /ver/spool/cron/crontabs is symlinked over to /mnt/kd. And the > > crond process is running... > > > > Jul 26 09:55:17 pbx cron.info crond[1135]: crond (busybox 1.30.1) started, > > log level 8 > > But nothing is executing overnight ! > > > > Thanks > > David > > > > > > > > On Fri, Jul 26, 2019 at 10:39 AM Lonnie Abelbeck > > <li...@lonnie.abelbeck.com> wrote: > > Hi David, > > > > Busybox crond uses "/var/spool/cron/crontabs" > > -- > > # ls -l /var/spool/cron/crontabs > > lrwxrwxrwx 1 root root 16 Jul 23 17:42 > > /var/spool/cron/crontabs -> /mnt/kd/crontabs > > -- > > which is (should be) symlinked to "/mnt/kd/crontabs" > > -- > > # ls -l /mnt/kd/crontabs > > total 4 > > -rw------- 1 root root 358 Oct 29 2017 root > > -- > > > > Also see if "crontab -l" shows what you expect. > > > > BTW, Thanks, I did not know "/etc/cron.d" was being installed, we should > > remove that. > > > > Lonnie > > > > > > > > > On Jul 26, 2019, at 9:01 AM, David Kerr <da...@kerr.net> wrote: > > > > > > I just noticed since moving to a new system that my cron jobs are not > > > running. The configuration of the new system was established by doing a > > > "restore basic configuration" from the system tab. I cannot figure out > > > why it is not working. > > > > > > crond is running (ps | grep "crond") and startup is logged in syslog. > > > /var/spool/cron/crontabs exists, is link to... > > > /mnt/kd/crontabs > > > inside that is "root" which is file placed there by the restore > > > configuration. It has permissions 600 > > > /etc/cron.d also exists > > > inside that is "e2scrub_all" which has permissions 644 > > > > > > I tried changing permissions on "root" to 644 but that made no difference. > > > > > > What am I missing? > > > > > > Thanks > > > David > > > > > > > > > _______________________________________________ > > > Astlinux-users mailing list > > > Astlinux-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > > > Donations to support AstLinux are graciously accepted via PayPal to > > > pay...@krisk.org. > > > > > > > > _______________________________________________ > > Astlinux-users mailing list > > Astlinux-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via PayPal to > > pay...@krisk.org. > > _______________________________________________ > > Astlinux-users mailing list > > Astlinux-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > > > Donations to support AstLinux are graciously accepted via PayPal to > > pay...@krisk.org. > > > > _______________________________________________ > Astlinux-users mailing list > Astlinux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > pay...@krisk.org. > _______________________________________________ > Astlinux-users mailing list > Astlinux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/astlinux-users > > Donations to support AstLinux are graciously accepted via PayPal to > pay...@krisk.org. _______________________________________________ Astlinux-users mailing list Astlinux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/astlinux-users Donations to support AstLinux are graciously accepted via PayPal to pay...@krisk.org.
