Hi there,
I've got an updated code review of this wad at
https://cr.opensolaris.org/action/browse/pkg/timf/periodic-recv-2/
On 02/12/13 11:38 AM, david.co...@oracle.com wrote:
so svc:/application/pkg/repositories-setup seems fine.
..
.
I think either works although I'd prefer to see it under
/application/pkg since it is pkg(5) specific.
No problem, I've gone with svc:/application/pkg/repositories-setup
I'm still open to suggestions, but think that exposing the crontab to the
user is the least worst solution here :-/
I don't have a good alternate suggestion here and certainly crontab(1)
is well understood from a sysadmin perspective so I'll withdrawn my
concern. I do appreciate the data from the experiences with
zfs-auto-snapshot - it is a similar sort of service we're talking about
here.
Ok. I've left that as is, and included a comment in the method script to
state that this service creates a crontab for pkg5srv.
The only other change, is from a suggestion Bart made today, which was
to make the pkgrecv happen as part of the "refresh" SMF method, so a
crontab entry now looks like:
30 2 4 * * /usr/sbin/svcadm refresh svc:/application/pkg/mirror:default
^-- this date is randomly chosen
at service start, though it only
gets applied to the running SMF
instance when the service refreshes[1]
(ie. the cron job fires)
The advantage is that we get better service visibility in the SMF log as
a result of the cron job firing, and it seems slightly more logical to do:
"svcadm refresh pkg/mirror"
to cause the service to manually update the mirror, than before this
change, where you needed to call the method script with the SMF_FMRI as
the first argument.
Rich pointed out a disadvantage, which is that this slightly grates with
the usual semantics of "svcadm refresh" which is to refresh the running
SMF snapshot with the current service properties, rather than
potentially kicking off a long-running job. I still think it's a
worthwhile change.
I'm keeping the majority of the logging in /var/log/pkg/mirror because I
think there'd be potentially a lot of log output in SMF log otherwise.
If the service does fail while doing a pkgrecv, and drops to maintenance
we leave now a message in the SMF log pointing to the logs in
/var/log/pkg/mirror/.
cheers,
tim
[1] which can be slightly confusing
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
