Two Objects Not Namespaced by the Linux Kernel (2017)
blog.jessfraz.com
Two Objects Not Namespaced by the Linux Kernel (2017)
1–10 of 59 posts
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#2Why is this the case? No one has bothered to do it? It would break backwards compatibility? Linus thinks it's a bad idea?
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#3Since this was written a time namespace was proposed: https://www.phoronix.com/scan.php?page=news_item&px=Linux-Ti...
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#4Syslog seems to be on the proposal list as well.
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#5Why is this the case? No one has bothered to do it? It would break backwards compatibility? Linus thinks it's a bad idea?
Shouldn't break backwards compatibility. More than anything, my guess is that it's just a result of most of Linux's modern day design having been implemented before the era of containers. Afaik, namespaces+cgroups were never meant to support complete isolation.
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#6Why is this the case? No one has bothered to do it? It would break backwards compatibility? Linus thinks it's a bad idea?
Probably merely because it's hard to do and no one has sufficient motivation.
I can think of one good use case -- y2k style problems.
Also sometimes apps are tied to external events like legislation. It would be good to set the time forward for testing.
You can sort of do this with LD_PRELOAD but it can get hairy.
Also see @wmf's comment above.
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#7I wonder whether namespacing time would also result in those namespaces being able to have separate "clocks" (time backends? time schedulers?) that progress at different rates, or for different reasons.
Being able to put a process into a time namespace with a deterministic "clock" would obviate a large benefit of http://www.zerovm.org/.
Also, having "clock slew" be a matter of perspective—with processes that can handle leap seconds seeing them happen instantaneously; and processes that can't handle leap-seconds, seeing slewed time—would be nice. Then you could have different system facilities that care about monotonic time, vs. synced to calendar time, vs. one second per second time, all having that kind of time available to them as "the time", rather than through different APIs.
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#8You can't change time in container, but it's possible to change timezone files.
With generating fake timezones it is possible to change time in container.
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#9Why is this the case? No one has bothered to do it? It would break backwards compatibility? Linus thinks it's a bad idea?
Probably merely because it's hard to do and no one has sufficient motivation. I can think of one good use case -- y2k style problems. Also sometimes apps are tied to external events like legislation. It would be good to set the time forward for testing. You can sort of do this with LD_PRELOAD but it can get hairy. Also see @wmf's comment above.
Another use case is dealing with tokens that assume globally synchronised clocks such as JWTs and Kerberos/Active Directory. Ideally all clocks would be perfectly synchronised but things happen.
For example, you might have one container that’s exchanging JWTs with a micro service that should be using AWS’s NTP servers and another that’s joined an Active Directory domain that should be using the AD NTP server. Right now you either need to run them on separate machines or expose yourself to interesting problems if clock skew happens.
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#10I wonder whether namespacing time would also result in those namespaces being able to have separate "clocks" (time backends? time schedulers?) that progress at different rates, or for different reasons. Being able to put a process into a time namespace with a deterministic "clock" would obviate a large benefit of http://www.zerovm.org/ . Also, having "clock slew" be a matter of perspective—with processes that can han…
> Also, having "clock slew" be a matter of perspective—with processes that can handle leap seconds seeing them happen instantaneously; and processes that can't handle leap-seconds, seeing slewed time—would be nice.
I imagine there might be some really interesting (for meanings of interesting that include shoot me now) and hard to track down bugs as you deal with inconsistent clocks not just across systems within a network, but processes within a single system.