Hi all. At the moment smartd is started from rc.M - by uncommenting the necessary lines. The problem with this is that every Slackware upgrade tends to disable smartd when it overwrites rc.M - which risks leaving it disabled if one doesn't remember to re-enable it. I find this quite important, as smartd is essential in warning of hdd failure - especially on servers.

I understand why it is commented out by default - but I was thinking that if the startup scripts would rely on starting it through a minimal rc.smartd script instead - it would mean that once enabled on a system (by making it executable), it would stay so throughout upgrade cycles - and not risk the situation where it has been disabled and left so by mistake. What do the others think?

Slackware's upgrade process does not overwrite your rc.M file. It is you who does this, consciously.
The upgrade will install a "rc.M.new" file and you need to inspect the differences between the currently installed and the new version before you decide to replace the original with the new file.

agree.

The logic behind what gets a separate rc.* and what doesn't on Slackware is a little hard to fathom. IMO there's a far stronger argument for having a rc.smartd than there is for the existence of rc.loop or rc.cpufreq which don't even have a daemon component to manage.

Personally, I think his suggestion has merit and that it's probably safer to not require users to customise rc.M (after all, isn't that what rc.local is for?)


If you don't get any joy on your suggestion, I'd recommend you use rc.local to start smartd rather than make changes to rc.M.

6 members found this post helpful.

@Alien Bob - that is true - but I don't seem to have stumbled over any other setting which requires customising one of the core startup scripts. To me it would seem to fit in with the philosophy used by Slackware elsewhere to not require users to modify the core startup scripts. But I can live with it if it isn't implemented :-)

@GazL - thank's for the suggestion - I think I will do so in the meanwhile. I always liked the idea that all my handywork is either in rc.local or in custom rc.* files which are not part of the core system :-)

Edit: There is also the time-saving and efficiency factor. The clearer the demarcation between settings and changes made by the user after install, and core/default system settings and scripts, the easier and faster it is to do a system upgrade. And less likely to go wrong.

1 members found this post helpful.

Yes, but does this not depend on when an action is needed? For example /etc/rc.d/rc.4 also needs editing in case one wants to use the Slim login manager and don't want to run in an error message (when no gdm, kdm or xdm are present)...

I've always been an advocate of the rc.conf/rc.conf.local approach used by the *BSDs for configuring rc files.

1 members found this post helpful.