00:44:00 jbk: There are some flags for svcs and ps for ISO format dates I think 00:44:25 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 00:44:40 And that there was some SMF setting to turn that back off if it broke you etc 00:44:45 Maybe alanc can remember 00:48:39 what is the format now? is it localized? 00:51:27 https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/svc/startd/log.c#L358-L364 00:52:52 For ps(1) in Solaris 11.4, we have: -I Use ISO 8601-1:2019 format for the stime field. 00:53:52 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 00:54:54 alanc: and in the SMF logs in /var/svc/log/ ? 00:54:59 svc logs still seem to be in the old format though 00:55:09 [ 2026 Jan 13 17:22:56 Method "start" exited with status 0. ] 00:55:16 Huh! 00:55:22 I guess I must have imagined it 00:55:24 though the year is new 00:55:33 [ Apr 22 16:27:41 Enabled. ] 00:55:34 is what we have 00:55:51 that probably _is_ loalized then 00:56:02 you may be thinking of the changes to syslog & /dev/log to enable high precision timestamps 00:56:08 where we have arbitrary differences in special strings, it's almost always fromm the libc_i18n + unicode sync 00:56:32 alanc: ah maybe yeah 00:56:37 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 00:57:25 I dunno it seems to just be "%b %e %T" 00:57:36 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 00:57:54 Surely it would need %Y to get the year 00:58:34 well, when I write blogs like https://blogs.oracle.com/solaris/whats-new-in-the-oracle-solaris-11481-cbe-release covering 3 years worth of changes, there's a lot to get stuck in strange corners of your brain 00:58:41 I feel like it would be pretty reasonable to do something like "2026-01-16 11:58:32.012" there by default tbh 00:59:57 Could probably allow one to override it via a property of some kind also 01:00:20 "struct log_ctl timestamps extended" in https://blogs.oracle.com/solaris/whats-new-in-the-oracle-solaris-11481-cbe-release#log_ctl-cbe81 covers the syslog change 01:01:15 one of those "as long as we have to increase timestamps past 32 bits, may as well make them more precise" changes 01:01:20 jclulow: that way we can support @beats 01:01:39 (if there's a property that specifies the format) 01:02:52 https://github.com/jasonbking/illumos-gate/commit/01bbca6cf93c89cd5cfdde15a16a4b75e9e7a68d is what I did... I had forgotten about it until some recent bits reminded me about it... 01:03:30 (not in love with the property name and might try to think of something better if I throw it up for review) 01:06:51 [illumos-gate] 17211 Tools svccfg build missing LIBSCF -- Jason King 01:18:46 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) 01:19:10 Maybe we could add that group, and add "timestamp" or something under it 01:19:19 and then also do the "permissions" one which honestly seems pretty valuable 01:37:26 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 01:38:43 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 02:10:13 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. 02:11:09 That's with respect to the earlier ping on sff. 03:01:26 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 03:01:49 at least it seems like that'd be a logical place for them 05:23:00 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 05:23:17 They should show up in topo though and be managed in userland. 05:29:56 why would I want to invent a whole new framework to read the temperature of a piece of hardware? 05:30:20 just so it's all done in userland? 05:30:25 First, I didn't tell you to do that. 05:30:36 Second, all the parsing logic for arbitrary binary payloads already is in userlad 05:30:40 *userland 05:31:57 The main point of fmtopo is to be the nexus of all the different sensors and sources. 05:32:50 So at least I don't think there's a whole framework to write here? 05:34:18 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. 05:37:00 Even with ksensor now I wouldn't go back and say we should do ipmi, ses, et. all as ksensors probably. 14:59:14 [illumos-gate] 17770 smbadm: double free of 'mname' is actually missing no return attribute -- Toomas Soome 15:18:18 Do we have support yet for ICE e810-C? 15:19:30 no 15:19:47 i picked up the work rmustacc had done, but it got side tracked multiple times for other things 15:21:21 I didn't think so, thanks for confirming 15:36:24 i'd need to look, but I think most of what's left is doing the rather extensive initialization/setup of the card 18:14:11 has anyone here used `jj gerrit upload` to push to our gerrit? 18:16:15 or am I the first to the moon? 18:20:41 i don't even know what that is 18:22:03 https://docs.jj-vcs.dev/latest/ 19:11:35 [illumos-gate] 17682 bhyve: want walk_config_nodes() -- Hans Rosenfeld 19:53:29 rzezeski: several oxide people were jj partisans 19:53:33 I dunno if they still are 19:53:38 but if anyone did, it'd be them 19:55:00 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 19:55:16 I have been playing with jj for a couple of months, I like it 19:55:32 beware our .gitignore not being thorough _during_ the build 19:55:39 temp files will come and go into your life 19:56:28 I don't build where I code, I code, push, pull, build. So no fear of jj status pulling in the world, haha