https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291025
--- Comment #3 from Alex Soto Aguilera <[email protected]> --- (In reply to Alex Soto Aguilera from comment #2) I did some more checks to better understand what is going on in this environment. Release tree used by Bastille The base tree that Bastille uses for jails is located at: /usr/local/bastille/releases/14.3-RELEASE/ In that tree, the periodic defaults and directories are exactly as in a stock 14.3-RELEASE installation. In particular: /etc/defaults/periodic.conf contains: periodic_conf_files="/etc/periodic.conf /etc/periodic.conf.local ${_localbase}/etc/periodic.conf" local_periodic="${_localbase}/etc/periodic" and it defines _localbase as: _set_localbase() { _localbase=/sbin/sysctl -n user.localbase 2> /dev/null : ${_localbase:="/usr/local"} } _set_localbase So by default local_periodic resolves to /usr/local/etc/periodic. There is no /etc/periodic.conf in that release tree, which matches expectations for a clean system. /etc/periodic/{daily,weekly,monthly,security} contains only the standard base scripts from 14.3. There is no /usr/local/etc/periodic in the release tree (no local periodic scripts by default). user.localbase inside the jail Inside the affected jails (e.g. the qbittorrent jail), sysctl user.localbase works and returns /usr/local, for example: root@qbittorrent:~ # sysctl user.localbase user.localbase: /usr/local root@qbittorrent:~ # sysctl -n user.localbase /usr/local This means that inside the jail _localbase is correctly set to /usr/local by the code in defaults/periodic.conf, and therefore the default value of local_periodic is also /usr/local/etc/periodic inside the jail, same as on the host. Summary of the situation The base release tree used by Bastille has the expected defaults: user.localbase → _localbase=/usr/local → local_periodic="/usr/local/etc/periodic". Inside the jails, sysctl user.localbase correctly reports /usr/local. On the host, periodic runs daily/weekly without duplicate output. Inside the jails, before adding any overrides, periodic weekly and periodic security were producing duplicated security blocks in a single run. Explicitly setting in /etc/periodic.conf inside the jail: local_periodic="/usr/local/etc/periodic" stops the duplication and makes periodic behave as expected. So from what I can see: The defaults in /etc/defaults/periodic.conf are correct and user.localbase is correct in both host and jails. The duplicate execution only manifested inside the jails until local_periodic="/usr/local/etc/periodic" was explicitly set in /etc/periodic.conf there. I am not sure yet why the explicit override in /etc/periodic.conf changes the behavior while the defaults already resolve to the same path, but it seems to be specific to running periodic inside these jails. I am leaving this note here in case it helps someone reproduce the environment or reason about the interaction between periodic_conf_files, local_periodic and the jail context. -- You are receiving this mail because: You are the assignee for the bug.
