From: Joachim B H. <cj...@fy...> - 2005-11-10 22:13:15
|
I suspect that self-tests will not be run reliably if --interval is greater than 1 hour. Only if smartd happens to wake up at the right time. Is that correct? If this is the case then a warning would be good. Also, if you forgive this drive-by-shooting (I installed smartmontools today so I don't know the history or rationale behind it), wouldn't a more crontab-like time specification be less brittle than regexps? It's easy to screw up a regexp, and the current checking of allowed characters only catches a few of these. -j. |
From: Bruce A. <ba...@gr...> - 2005-11-17 23:07:59
|
> I suspect that self-tests will not be run reliably if --interval is > greater than 1 hour. Only if smartd happens to wake up at the right > time. Is that correct? Yes. The smartd man page says: "Scheduled tests are run immediately following the regularly-scheduled device polling, if the current local date, time, and test type, match REGEXP. By default the regularly-scheduled device polling occurs every thirty minutes after starting smartd. Take caution if you use the '-i' option to make this polling interval more than sixty minutes: the poll times may fail to coincide with any of the testing times that you have specified with REGEXP, and so the self tests may not take place as you wish." > If this is the case then a warning would be good. Agreed. I need to put a warning into the code, not just in the man page. > Also, if you forgive this drive-by-shooting (I installed > smartmontools today so I don't know the history or rationale > behind it), wouldn't a more crontab-like time specification be > less brittle than regexps? It's easy to screw up a regexp, and > the current checking of allowed characters only catches a few of > these. I originally wanted to do this. But I didn't have the time/energy to code a crontab like parser (or rip it off from the crontab code) and scheduling code to wake up smartd at the right time. So I did it using regexps instead. Pure laziness on my part. Cheers, Bruce |
From: Volker K. <lis...@pa...> - 2005-11-17 23:37:19
|
> >wouldn't a more crontab-like time specification be > >less brittle than regexps? Yes, IMHO > I originally wanted to do this. But I didn't have the time/energy to code > a crontab like parser (or rip it off from the crontab code) and scheduling > code to wake up smartd at the right time. Why not use cron? Create a file /etc/cron.d/smartmontools. This would need something like a smartd option --checkalerts which is much easier to implement, and dealing with the kept disk states. One solution would be for smartd --checkalerts to hunt down its running alter ego for a signal exchange, or however that works. However I think it would be better to keep the disk states in a file in /var/cache/, which would also be robust against restarting smartd. Actually, perhaps it would be a better/possible/etc approach to not have a permanently running smart daemon, but instead to only invoke it from cron periodically? How much change would be required to change smartd from a permanent-process structure to a timer-driven structure? Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. |
From: Bruce A. <ba...@gr...> - 2005-11-18 02:22:10
|
Hi Volker, All the changes you suggest are trivial ones to implement -- under any given Linux distribution. The hard part is to document and then support them on multiple Unix platforms, multiple Linux distributions, and the whole zoo of operating systems that smartmontools now supports. All of these have different locations for files, different versions of tools such as cron, etc. All this is too much for me to manage or support. Hence the simple approach that I picked. I think it works OK for 99% of users. Cheers, Bruce On Fri, 18 Nov 2005, Volker Kuhlmann wrote: >>> wouldn't a more crontab-like time specification be >>> less brittle than regexps? > > Yes, IMHO > >> I originally wanted to do this. But I didn't have the time/energy to code >> a crontab like parser (or rip it off from the crontab code) and scheduling >> code to wake up smartd at the right time. > > Why not use cron? Create a file /etc/cron.d/smartmontools. This would > need something like a smartd option --checkalerts which is much easier > to implement, and dealing with the kept disk states. One solution would > be for smartd --checkalerts to hunt down its running alter ego for a > signal exchange, or however that works. However I think it would be > better to keep the disk states in a file in /var/cache/, which would > also be robust against restarting smartd. Actually, perhaps it would be > a better/possible/etc approach to not have a permanently running smart > daemon, but instead to only invoke it from cron periodically? How much > change would be required to change smartd from a permanent-process > structure to a timer-driven structure? > > Volker > > -- > Volker Kuhlmann is possibly list0570 with the domain in header > http://volker.dnsalias.net/ Please do not CC list postings to me. > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. Get Certified Today > Register for a JBoss Training Course. Free Certification Exam > for All Training Attendees Through End of 2005. For more info visit: > http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click > _______________________________________________ > Smartmontools-support mailing list > Sma...@li... > https://lists.sourceforge.net/lists/listinfo/smartmontools-support > |
From: Volker K. <lis...@pa...> - 2005-11-18 04:25:36
|
Bruce, > All the changes you suggest are trivial ones to implement -- under any > given Linux distribution. The hard part is to document and then support > them on multiple Unix platforms, multiple Linux distributions, and the > whole zoo of operating systems that smartmontools now supports. All of > these have different locations for files, different versions of tools such > as cron, etc. I can see this being an issue, but other software projects are managing this too. The GNU configure mechanism takes care of all the *ix at least. Different cron versions are a non-issue, they're taken care of by $sysadmin and/or $distrovendor, which in any case isn't more demanding than the current situation. I'd be prepared to put some time into this, but I only use Linux. It's a public project afterall, users of other OSes should chip in (and have in the past). Personally I have no interest in being held back by the least common denominator, Microsoft (just as example) doesn't wait either if *ix is one step behind. If any contribution has to work on all platforms then that cuts me out, I don't have access to commercial *ix and no time for other free *ix. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. |