jbk: There are some flags for svcs and ps for ISO format dates I think

And while I have not been able to find it, I feel like I read at some point that the SMF logs at least had higher precision timestamps if not also an ISO format

And that there was some SMF setting to turn that back off if it broke you etc

Maybe alanc can remember

what is the format now? is it localized?

For ps(1) in Solaris 11.4, we have: -I Use ISO 8601-1:2019 format for the stime field.

For svcs(1), we default to ISO-8601, but go back to old style with the -i flag, if that's all your scripts parsing the output will handle

alanc: and in the SMF logs in /var/svc/log/ ?

svc logs still seem to be in the old format though

[ 2026 Jan 13 17:22:56 Method "start" exited with status 0. ]

Huh!

I guess I must have imagined it

though the year is new

[ Apr 22 16:27:41 Enabled. ]

is what we have

that probably _is_ loalized then

you may be thinking of the changes to syslog & /dev/log to enable high precision timestamps

where we have arbitrary differences in special strings, it's almost always fromm the libc_i18n + unicode sync

alanc: ah maybe yeah

Jan 15 12:58:49.125 alf genunix: [ID 603404 kern.notice] NOTICE: core_log: firefox[1618] core dumped: /var/cores/core.global.firefox.50758.1618

I dunno it seems to just be "%b %e %T"

jclulow: it reaches a point where you start to think every nice-if-I-had-the-time userland feature, must be something you saw alan talk about

Surely it would need %Y to get the year

well, when I write blogs like blogs.oracle.com/solaris/whats-new-…he-oracle-solaris-11481-cbe-release covering 3 years worth of changes, there's a lot to get stuck in strange corners of your brain

I feel like it would be pretty reasonable to do something like "2026-01-16 11:58:32.012" there by default tbh

Could probably allow one to override it via a property of some kind also

"struct log_ctl timestamps extended" in blogs.oracle.com/solaris/whats-new-…ris-11481-cbe-release#log_ctl-cbe81 covers the syslog change

one of those "as long as we have to increase timestamps past 32 bits, may as well make them more precise" changes

jclulow: that way we can support @beats

(if there's a property that specifies the format)

jasonbking/illumos-gate 01bbca6 is what I did... I had forgotten about it until some recent bits reminded me about it...

(not in love with the property name and might try to think of something better if I throw it up for review)

[illumos-gate] 17211 Tools svccfg build missing LIBSCF -- Jason King <jason.brian.king⊙gc>

jbk: It seems like svc.startd(8) has a "logfile_attributes" property group that contains a "permissions" property right now (which we don't have either)

Maybe we could add that group, and add "timestamp" or something under it

and then also do the "permissions" one which honestly seems pretty valuable

ooh yeah.. i guess the only thing (but maybe it's actually desirable?) is it'd mean different services (or even instances) could have different formats

note could, not would -- I believe if you set it on svc.startd's instance, I think as long as it's defined properly, it'll inherit unless explicitly overridden

jbk: Yeah, getting some of the existing stuff is definitely a design challenge there. There are probably a few different ways I might approach it depending on my general goals over time. But I think that's a rather reasonable way to start. Though I'd probably output to a different nvlist_t.

That's with respect to the earlier ping on sff.

eventually, it might be nice to get some of those things (when present) as ksensors though dealing with insertion/removal might add a wrinkle to making everything work

at least it seems like that'd be a logical place for them

jbk: I don't think it makes sense for them to be ksensors. Because the kernel shouldn't be in the busines of processing them

They should show up in topo though and be managed in userland.

why would I want to invent a whole new framework to read the temperature of a piece of hardware?

just so it's all done in userland?

First, I didn't tell you to do that.

Second, all the parsing logic for arbitrary binary payloads already is in userlad

*userland

The main point of fmtopo is to be the nexus of all the different sensors and sources.

So at least I don't think there's a whole framework to write here?

I conciously chose libsff to be in userland when I wrote it. Maybe that's the wrong choice, but that was what I was thinking, fwiw.

Even with ksensor now I wouldn't go back and say we should do ipmi, ses, et. all as ksensors probably.

[illumos-gate] 17770 smbadm: double free of 'mname' is actually missing no return attribute -- Toomas Soome <tsoome⊙mc>

Do we have support yet for ICE e810-C?

no

i picked up the work rmustacc had done, but it got side tracked multiple times for other things

I didn't think so, thanks for confirming

i'd need to look, but I think most of what's left is doing the rather extensive initialization/setup of the card

has anyone here used `jj gerrit upload` to push to our gerrit?

or am I the first to the moon?

i don't even know what that is

[illumos-gate] 17682 bhyve: want walk_config_nodes() -- Hans Rosenfeld <rosenfeld⊙gho>

rzezeski: several oxide people were jj partisans

I dunno if they still are

but if anyone did, it'd be them

I ran into an issue and after some head banging I just pushed with git, but I think it had to do with my gerrit remote not being fetched

I have been playing with jj for a couple of months, I like it

beware our .gitignore not being thorough _during_ the build

temp files will come and go into your life

I don't build where I code, I code, push, pull, build. So no fear of jj status pulling in the world, haha