Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#4550 - add a conf.d file for clock settings

Attached to Project: Arch Linux
Opened by Dale Blount (dale) - Tuesday, 02 May 2006, 15:43 GMT
Last edited by Aaron Griffin (phrakture) - Thursday, 17 April 2008, 20:03 GMT
Task Type Feature Request
Category System
Status Closed
Assigned To dtw (dibblethewrecker)
Aaron Griffin (phrakture)
Thomas B├Ąchler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version 0.7.1 Noodle
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Similar to the sysconfig file RedHat/Fedora uses..

http://www.redhat.com/archives/fedora-list/2005-April/msg04936.html


I can implement and send patches if that's easier.
This task depends upon

Closed by  Aaron Griffin (phrakture)
Thursday, 17 April 2008, 20:03 GMT
Reason for closing:  Implemented
Additional comments about closing:  USEDIRECTISA in rc.conf
Comment by Roman Kyrylych (Romashka) - Friday, 05 May 2006, 08:36 GMT
How is this better from current implementation in Arch?
Comment by Dale Blount (dale) - Friday, 05 May 2006, 12:08 GMT
Certain clocks need extra parameters when using hwclock. This moves that out to an external file so local changes to rc.sysinit won't get overwritten.
Comment by Roman Kyrylych (Romashka) - Friday, 05 May 2006, 12:46 GMT
OK, maybe it worth to move clock settings to conf.d. Maybe not in 0.7.2, but in 0.7.3 I hope.
Comment by Roman Kyrylych (Romashka) - Saturday, 14 April 2007, 11:45 GMT
status?
Comment by Ivan Todoroski (Grnch) - Sunday, 28 October 2007, 06:44 GMT
This would help greatly with problems like  FS#7667  and  FS#8437 . They have been declared non-bugs which is technically correct because they don't occur on real hardware, but are still pain in the ass for us VirtualBox users. Having the hwclock parameters in a separate place like conf.d or rc.conf would allow us to change them without manually patching rc.{sysinit,shutdown} scripts on each upgrade.
Comment by Aaron Griffin (phrakture) - Monday, 17 December 2007, 07:40 GMT
Well, could you please describe the parameters you'd need? We currently abstract the hwclock params a but with HARDWARECLOCK="utc" in rc.conf, so if we could cover it with a similar variable, it'd be nicer. I'm going to guess the only discrepancy is --directisa?
Comment by Ivan Todoroski (Grnch) - Monday, 17 December 2007, 07:54 GMT
Yes, at least for me it's only --directisa. Still, for possible future expansion it would be nice if it was a variable where you could set arbitrary additional parameters, rather than being something overly specific like USEDIRECTISA="yes/no".
Comment by Aaron Griffin (phrakture) - Monday, 17 December 2007, 08:02 GMT
The problem is that adding a generic variable like this is going to cause issues with the existing functionality. What happens with "--localtime --utc" or vice versa?

It's something I'd like to avoid. Even more so, I'd like to avoid moving yet more functionality outside of rc.conf for something like this. I've heard a lot of "rc.conf is awesome" but never "editing 30 files in /etc/conf.d is awesome"
Comment by Ivan Todoroski (Grnch) - Monday, 17 December 2007, 08:18 GMT
I see your point about --localtime etc. Well, I guess my argument about "possible future expansion" is hand-waving at best, so for me a USEDIRECTISA type variable would be more than enough (I'm not the original bug submitter though and I wouldn't want to hijack this bug report just to scratch my particular itch).

As for rc.conf vs conf.d, as I said in my earlier comment above I have no preference, either one is fine by me as long as it spares me from editing rc.sysinit and rc.shutdown all the time. I know the title of this bug report specifies conf.d, but if the original submitter has no objection I vote for rc.conf too.
Comment by Aaron Griffin (phrakture) - Monday, 17 December 2007, 09:21 GMT
An alternative would be to remove all the hwclock calls and put them in a custom /etc/rc.d/hwclock script. It *might* make things cleaner... opinions?
Comment by Ivan Todoroski (Grnch) - Monday, 17 December 2007, 09:32 GMT
Wouldn't that bring us right back to the problem of user customizations being overwritten on each package update?
Comment by Ivan Todoroski (Grnch) - Monday, 17 December 2007, 09:36 GMT
One possible approach is to have a generic HWCLOCKPARAMS variable after all, but if a user specifies parameters that are used internally by the script (such as --utc, --localtime, etc), a warning could be printed and those parameters ignored.
Comment by Aaron Griffin (phrakture) - Monday, 17 December 2007, 22:22 GMT
I don't mean an /etc/rc.d/hwclock that you hand edit - we don't do that anywhere in arch. I mean a hwclock script with a corresponding conf.d/ configuration
Comment by Ivan Todoroski (Grnch) - Monday, 17 December 2007, 22:40 GMT
Oh, sorry for the confusion. Yeah, that would be perfect.
Comment by Roman Kyrylych (Romashka) - Sunday, 06 January 2008, 11:56 GMT
/etc/rc.d/hwclock will break everything! hwclock is called way before any rc.d can be.
We've spent alot of time for tracking all time-related bugs.
If you need some extra parameters - no problem implementing them in rc.conf or conf.d, but rc.d/hwclock - no way!
Comment by Aaron Griffin (phrakture) - Monday, 07 January 2008, 19:08 GMT
Just to clarify Roman's point: hwclock is called before the rc.d scripts are loaded

So it appears we cannot use a rc.d script as the clock is needed well before we get to that point.

If so, Roman can you explain what problems this would cause? See on my system right now, I can set the time any time after /dev is loaded. And it works fine. Could you please explain the reasoning, as "no way!" doesn't really give me very much info.
Comment by Roman Kyrylych (Romashka) - Tuesday, 08 January 2008, 02:04 GMT
Why hwclock handling should not be touched:  FS#5444 ,  FS#5445 ,  FS#5529 ,  FS#6063  (it took a *lot* of time and work to get it to a really good working state)
(in short - what correct hwclock handling must take into considerations: UTC/localtime in BIOS, timezone, is /usr separate?, is / read-only, what timezone was on previous mount etc.)
Why --directisa should be made configurable:  FS#4929 ,  FS#8437 
Comment by Aaron Griffin (phrakture) - Tuesday, 08 January 2008, 09:08 GMT
Roman, for the record, I am well aware of what it requires to boot a machine and get it in working order. It is, in a way, what I do. I never once suggested "why don't I move this and neglect everything that's been done while re-introducing about 5 different regressions". 3 of the original 4 bug reports hard nothing to do with the ordering of the hwclock call, only one of them does. I understand very well when the proper system time is needed and when it is not.

The difference here, is that your stance is "it works, don't touch it", where my stance is "we can do this better".

However, I'm getting offtrack here. I will fall in line with the "it works, don't touch it" crowd for simplicity and brevity:
http://code.phraktured.net/?p=initscripts.git;a=commitdiff;h=9bf2014b750579d9720c13c9dfb9d358e0c27665

*EDIT* amended the commit, new URL
Comment by Roman Kyrylych (Romashka) - Tuesday, 08 January 2008, 09:53 GMT
Aaron, I've mentioned that info for reference purposes, not for teaching. :)

> See on my system right now, I can set the time any time after /dev is loaded. And it works fine.
ehm..  FS#8665  ;)
Anyway, we cannot set hwclock in rc.d because of  FS#5445 .
I didn't mean that the code shouldn't be touched *just* because it works, but because I don't see any way to make it better by moving hwclock setting to rc.d.

Your patch for USEDIRECTISA is good (you forgot about rc.shutdown though).
I think this report can be closed after releasing new initscripts.

Loading...