It's not specifically guarded. Dynamic stuff like networking is specifically excluded. Timezone is pretty much the same as any other config, in that if you want to change it make sure you can save it.
I'd argue that dynamically changing timezone for the duration of a boot is not that common. If you really want it to be dynamic, you can either: 1. Bind mount over the top of /etc/localtime to a writable file on boot. Update it's contents whenever you want to change the timezone. 2. Set your /etc/ master image to make /etc/localtime to be a symlink to /run/localtime and then ensure /run/localtime is a symlink to the appropriate file in /usr during early boot (e.g. in initramfs). Then when you want to to change the timezone, just update the /run/ symlink. Both will work fine. You can do this if you really want to and no-one is stopping you, it's just that the systemd-blessed tool to update the content in /etc won't do that, just like it won't do that for numerous other stuff too. Everyone sees the problem (and often the solution) they have in front of them as the most obvious thing in the world, but some perspective is often needed to see it as others do. Col Shravan Singh wrote on 08/09/2020 14:31: > No one is answering a simple question. Why we have to guard timezone so > much?. > Why can't I change it? What happens if I change it on a read-only > rootfs? I am breaking the whole systemd by doing this? > > In fact most of the people in this group are suggesting a work-around to me > > "I wonder: If you have a working pull request, why don't you use that > code and be happy with it? That's how free software works. > Still everybody interested can apply you patch." > > Yes, it works. My question is why is not getting included so that > everyone can benefit from it. That is how a free software community > should work. > > In this day and age of mobile computing it is really shocking to see. > That timezone is not regarded as something that can be dynamically changed. > > Anyway this issue is going no-further if people are adamant in not > changing it. > And I don't see any reason in going back and forth with everyone. > > > Regards, > Shravan Singh > (239) 243-0838 > > Blue Sparq, Inc. > 928 NE 24th Lane unit 4 and 5. > Cape Coral, FL 33993 > > IMPORTANT: The contents of this email and any attachments are > confidential. They are intended for the named recipient(s) only. If you > have received this email by mistake, please notify the sender > immediately and do not disclose the contents to anyone or make copies > thereof. > > > On Mon, Sep 7, 2020 at 4:49 AM Ulrich Windl > <ulrich.wi...@rz.uni-regensburg.de > <mailto:ulrich.wi...@rz.uni-regensburg.de>> wrote: > > >>> Shravan Singh <shra...@bluesparq.com > <mailto:shra...@bluesparq.com>> schrieb am 05.09.2020 um 00:26 in > Nachricht > <CABjzrPR=7mwzfwmz6ovegvi+3gjc24dcxos4gk_sk-kxd91...@mail.gmail.com > <mailto:7mwzfwmz6ovegvi%2b3gjc24dcxos4gk_sk-kxd91...@mail.gmail.com>>: > > And this is a major problem for any one running raspberry pi, NXP > or any > > other embedded processor that uses mender and embedded linux. > > Maybe an embedded OS really should use UTC as timezone. > > > A machine with embedded linux running on it goes to San Francisco > and then > > transported to Chicago. > > And you are saying that we shouldn't be allowed to change the > timezone? > > The question is : Who will "see" the timezone? Does every process > run with the same timezone? > > > Just because you are not "convinced" > > Does this group have a poll system? Let's put this to poll and see? > > I wonder: If you have a working pull request, why don't you use that > code and be happy with it? That's how free software works. > Still everybody interested can apply you patch. > > > > I have tried having a rational explanation with you but your > attitude is > > just appalling > > > > I have tried this solution and it works > > https://github.com/systemd/systemd/pull/8277. > > I just don't understand why you are not willing to accept this. > And provide > > a solution to all the people using raspberry pi and or embedded > processors? > > > > > > > > > > Regards, > > Shravan Singh > > (239) 243-0838 > > > > Blue Sparq, Inc. > > 928 NE 24th Lane unit 4 and 5. > > Cape Coral, FL 33993 > > > > IMPORTANT: The contents of this email and any attachments are > confidential. > > They are intended for the named recipient(s) only. If you have > received > > this email by mistake, please notify the sender immediately and do not > > disclose the contents to anyone or make copies thereof. > > > > > > On Fri, Sep 4, 2020 at 6:16 PM Shravan Singh > <shra...@bluesparq.com <mailto:shra...@bluesparq.com>> wrote: > > > >> What constitutes a configuration? > >> And please read my email subject. I can't have writable /etc, mender > >> dosen't allow that. > >> > >> In today's mobile computing age you really think users shouldn't > change > >> timezone? > >> You keep saying " I for one am certainly not convinced that the > timezones" > >> but you don't explain why? > >> Are you looking at this system as a static machine? That can > never change > >> timezone? > >> > >> And please don't use profanity. I have not and you shouldn't either. > >> > >> Regards, > >> Shravan Singh > >> (239) 243-0838 > >> > >> Blue Sparq, Inc. > >> 928 NE 24th Lane unit 4 and 5. > >> Cape Coral, FL 33993 > >> > >> IMPORTANT: The contents of this email and any attachments are > >> confidential. They are intended for the named recipient(s) only. > If you > >> have received this email by mistake, please notify the sender > immediately > >> and do not disclose the contents to anyone or make copies thereof. > >> > >> > >> On Fri, Sep 4, 2020 at 6:05 PM Lennart Poettering > <lenn...@poettering.net <mailto:lenn...@poettering.net>> > >> wrote: > >> > >>> On Fr, 04.09.20 15:54, Shravan Singh (shra...@bluesparq.com > <mailto:shra...@bluesparq.com>) wrote: > >>> > >>> > Yes, But help me understand. > >>> > I think you said that you are not convinced as to why that has > to done. > >>> > > >>> > My argument is very simple shouldn't a Linux environment allow > change in > >>> > timezone easily? > >>> > >>> Oh we do. But if your want configuration to be changable, then mount > >>> /etc writable. > >>> > >>> You have two contradicting goals: you want immutable config, but > then > >>> you want to change config. So how's that gonna work? > >>> > >>> If you want your persistent config changable then make it changable, > >>> i.e. mount /etc/ writable. > >>> > >>> > Now I am not an expert in Linux kernel development. But I see > that some > >>> of > >>> > the files, even though they reside in /etc are linked to file > in /run > >>> > Like *resolv.conf. *Which allows dynamic changes. > >>> > >>> I explained this already. DNS server data today is much less config > >>> than state, acquired dynamically via DHCP, hence most distros don#t > >>> configure it in /etc so much anymore, but manage it in /run (where > >>> transient state is generally kept), and only keep a compat > symlink in > >>> /etc. If you try to convince people though that the local timezone > >>> should just be transient state and not persistent config you'll > have a > >>> hard time. I for one am certainly not convinced that the > timezones are > >>> state... > >>> > >>> I mean, the line between persistent configuration and transient > state > >>> is blurry, but in the case of DNS settings and timezone settings I > >>> certainly can draw a line easily. > >>> > >>> > timezone activity change is a very basic change one that needs > to be > >>> > supported by the system. Why guard it with so much. > >>> > >>> We don't do that. Just make /etc/ writable ffs, if you want stuff in > >>> /etc to be changable. > >>> > >>> Lennart > >>> > >>> -- > >>> Lennart Poettering, Berlin > >>> > >> > > > > > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
