iX: “Don’t use /sbin/shutdown. Use midclt to power off the system if you don’t use the GUI’s button.”
Also iX: “For the UPS service, it will issue the /sbin/shutdown command instead of iX’s recommended midclt method.”
That’s not just messaging. That’s actually what the software does. iX simply needs to change the command used to invoke a system poweroff when triggered by UPS.
It would be just as inconsistent if iX says, “Don’t use /sbin/shutdown.” Then you later find out that pressing the poweroff button in the GUI actually invokes /sbin/shutdown under the hood, instead of using the midclt method.
You’re speaking matter of factly about how the software operates without actually investigating it. Sure, it might be inconsistent messaging but no one is telling me what bug they encountered in this area. It seems to be just a matter of other iX people claiming you should use midclt. I can’t change what other iX employees say on this forum but it would be wise to actually do a bit of investigation of the software instead of relying solely on what is reported on the forums.
So i’ll try to give a bit of help in this area because systemd service files can be quite complicated. We use systemd service files and we also have one for the middlewared service. It has a Conflicts=shutdown.target entry. This means that systemd will send SIGTERM to all service files that have that entry in their unit file definition. In middlewared code, we have signal handlers for SIGTERM. So when we receive SIGTERM, we start shutting down various parts of the middleware stack (ideally cleanly). After timeout, however, SIGKILL is sent by systemd to the process (this is by design).
EDIT: If someone finds a bug with the systemd unit file behavior, then I’m interested and I’d love to know more because that is a bug that we should fix.
I think this comment from @kris should just be linked in the Jira bugreport so iX can internally decide what to do, if anything. No need to argue here on forums.
Looks like both ways work correctly so no need to rush.
After iX communicated that one should not use shutdown in scripts because it could cause issues, I noticed that the default UPS shutdown command appeared to use just that, shutdown.
Because an iX employee was reading the topic, I asked here if this was intentional, and got this answer:
So I did just that. made a Jira report with my findings and said it was unexpected.
I personally think the situation is funny; think of all those databases on all those servers relying on that regular, stupid, old OS shutdown mechanism (systemd / rc.d). I keep thinking of Joe Pesci asking “were these magic grits?”
@csj is correct here, my information is out of date. Using shutdown now on SCALE is fine, and should call the correct things on middleware side for clean shutdown of Apps/VMs/Containers. Folks can breath easy again
I’m genuinely very happy to have been wrong on this, because it means that ACPI soft shutdown and similar out-of-band calls can function the same way as a webUI initiated shutdown.
Seems that people have decided that the shutdown behaviour is good, and working as I described that it should be working
BUT, there is an issue where the hypervisor host’s services are shutdown before the hosted VMs are…
As TrueNAS evolves into a more and more capable hypervisor (incus, sandboxes, dockers, qemu, etc), it seems to me that it would make sense to ensure that the hosted guests (incus, qemu, docker) are shutdown before the host’s services are shutdown (nfs, smb, iscsi etc)
I don’t know ANYTHING about systemd but isn’t this just a fstab issue (i.e., you need to tell systemd not to close the door on “X,Y,Z” stuff first)? I mean wasnt this one of the reasons (order of things) the reason NetBSD made rc.d and moved away from rc.local?
Not sure if people have decided it is “good” but I do think using the system’s method is “as it should be done” (is that the same as: ‘working as described’)?
I’m lost, what’s with the ‘jerk’ and ‘crow’ (seems a bit harsh)?
If that’s in reference to someone making a wrong statement, someone should try and fix the “only mistake on the internet” before the internet’s reputation gets tarnished.
Maintaining the (essentially) inverse of a boot time dependency tree (reboot/shutdown/halt) is complicated enough. Throw in this fad for hyper-converged features and the problem becomes almost untenable
I say that because the ticket you linked was assigned to me and I’ve done some initial investigation and I see maybe…a small…and I mean SMALL glimmer of light at the end of a veryyyyyy long tunnel on how we could convince ourselves that we could do this in a way that is “stable” and “reliable”.
To be completely transparent, we also have to consider service dependency order for our enterprise product line as well so this is deceptively simple but (potentially) profoundly complex
So, I guess what I’m saying is try to be patient with us. We’ll get to it eventually.
As the one whose face is on the thumbnail of the video and whose mouth said words came out of, I’m simply having a bit of a laugh at my own expense here.
But yes, I’ll go ahead and update the videos and statements with a footnote akin to “as of version XX.YY this isn’t necessary, you can ACPI shutdown or hit it with the classic shutdown call”
Ah. The famous “podcast”. Well, I’m sure you are not alone in making a false statement on youtube. As a rule-of-thumb, unless I’m trying to learn to knit or use a chainsaw I stay off youtube (music sometimes maybe).
I would also make a clarification for CORE too; I understand having to promote your current product but there is already proof in the wild that CORE users are trying to implement the same on those systems. Lest we forget the product that made you all that money.
