Opened 15 years ago
Closed 15 years ago
#20545 closed defect (fixed)
smartmontools removes the user's config file and no longer works
Reported by: | vinc17@… | Owned by: | tobypeterson |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.7.1 |
Keywords: | Cc: | ||
Port: | smartmontools |
Description
The new revision 5.38_1 of smartmontools no longer works. First, it removed my config file! Then the daemon is no longer running.
Change History (11)
comment:1 Changed 15 years ago by tobypeterson
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:3 Changed 15 years ago by vinc17@…
OK, but perhaps the old config file should have been restored or a message should have been displayed to warn the user. When I did the upgrade, I wasn't aware that my config file disappeared.
Ditto for loading the plist, a message should have been displayed to warn the user that something important had changed.
comment:4 Changed 15 years ago by vinc17@…
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
I'm reopening since it still doesn't work.
$ sudo launchctl load /Library/LaunchDaemons/net.sourceforge.smartmontools.smartd.plist net.sourceforge.smartmontools.smartd: Already loaded
But the daemon isn't running.
Other plist files have <key>RunAtLoad</key><true/>.
comment:5 Changed 15 years ago by tobypeterson
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
comment:6 Changed 15 years ago by vinc17@…
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
smartmontools/files/net.sourceforge.smartmontools.smartd.plist is clearly broken.
comment:7 Changed 15 years ago by vinc17@…
well... unless there's something special to do in order to have the RunAtLoad set to true (e.g. an option in macports.conf?), but that's not documented.
comment:8 follow-up: 10 Changed 15 years ago by tobypeterson
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
RunAtLoad wouldn't make any sense - that only causes the job to get run once. KeepAlive is true, that should be enough. I don't see how you can say it's "clearly broken" - for me, it "clearly works".
comment:9 Changed 15 years ago by tobypeterson
Priority: | High → Normal |
---|
Hrm. Are you on Tiger or something? That might explain it...
comment:10 follow-up: 11 Changed 15 years ago by vinc17@…
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
Summary: | smartmontools removes the user's config file and no longer works → smartmontools no longer loaded on Tiger |
Replying to toby@…:
RunAtLoad wouldn't make any sense - that only causes the job to get run once.
It does make sense. This is what Apple sometimes does for daemons that need to run all the time, e.g. in /System/Library/LaunchDaemons/com.vix.cron.plist.
I don't see what you mean by "that only causes the job to get run once". Actually I also need <key>OnDemand</key><false/> so that the daemon is restarted automatically after being killed.
KeepAlive is true, that should be enough.
Apple doesn't seem to use KeepAlive very much:
$ grep KeepAlive /System/Library/LaunchDaemons/* /System/Library/LaunchDaemons/com.apple.usbmuxd.plist: <key>KeepAlive</key>
But this plist also has <key>RunAtLoad</key><true/> and <key>OnDemand</key><false/>.
I don't see how you can say it's "clearly broken" - for me, it "clearly works".
It works on your machine. But machines are different, with different options and so on. You mustn't assume that just because it works on your machine, it isn't buggy, in particular when analyzing various plist files shows a clear difference.
Are you on Tiger or something?
Yes, I'm on Tiger. Hmm... According to Technical Note TN2083 - Daemons and Agents, this is what makes the difference, KeepAlive is supported as of 10.5 only. In fact, setting OnDemand to false would be sufficient.
(Wondering why trac doesn't have an "OS" field, contrary to usual BTS.)
comment:11 Changed 15 years ago by tobypeterson
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Summary: | smartmontools no longer loaded on Tiger → smartmontools removes the user's config file and no longer works |
Restoring the old title and closing (again), as the problem you're describing is different from the original problem.
Removing the config file was a necessary evil - before, it would just overwrite any user config file. Problem should be gone in the future.
Not sure why it isn't running - it was switched from the deprecated startup item to a launchd job. If rebooting and/or manually loading the plist doesn't work, provide logs.