A request I've seen voted upwards by others several times that I wanted
to pass along to you:
Being able to shutdown MIS (windows or linux) and MIS -D (linux) gracefully from a command line. So if I wanted to run a backup script
and not have MIS running it can be shutdown gracefully without a human being needing to press the ESC key and press enter on YES
If this is a motion on the floor, I'd like to 2nd it. to execute a
Mutil type command at the prompt before a batch backup run .. then a
Mutil type command to launch MIS back normally.
Being able to shutdown MIS (windows or linux) and MIS -D (linux) gracefully from a command line. So if I wanted to run a backup script and not have MIS running it can be shutdown gracefully without a human being needing to press the ESC key and press enter on YES
A better cross platform approach may be the use of semaphores - which is how Taurus does it.
Interesting idea... personally I'd love a switch that I could just pass in a batch file to MIS but that's just me :)
On 01-21-20 21:38, Avon wrote to g00r00 <=-
A request I've seen voted upwards by others several times that I wanted
to pass along to you:
Being able to shutdown MIS (windows or linux) and MIS -D (linux) gracefully from a command line. So if I wanted to run a backup script
and not have MIS running it can be shutdown gracefully without a human being needing to press the ESC key and press enter on YES
On 01-21-20 09:31, ryan wrote to Argos <=-
If this is a motion on the floor, I'd like to 2nd it. to execute a
Mutil type command at the prompt before a batch backup run .. then a
Mutil type command to launch MIS back normally.
I'd even be inclined to vote /more/ strongly for keeping mis running,
but when connection attempts are made, it throws some kind of "the bbs
is undergoing nightly maintenance, please call back" type message.
The benefit here is that we'd potentially be able to put a backup job
in mystic's own events. I, a linux user, would otherwise have to
disable the automatic systemd job to launch mystic, shut the board
down, do the backup, re-enable the systemd job, and start the BBS once again. Simply pausing any activity to/from data files with a "board is temporarily down" message seems like a home run in this case :)
On 01-22-20 09:35, Alterego wrote to Avon <=-
So between touching the "shutdown" semaphore, you test that the "im running" semaphore gets deleted. And after touching the "start"
sempahore, you check that the "im running" semaphore is created (and
that way you know its working at an application level). (The "shutdown" and "start" semaphores also get deleted when actioned...)
...deon
On Linux:
killall mis
should do the trick, because by default, kill and killsll send SIGTERM, which tells the process to shutdown in an orderly manner.
I use a cron job to both monitor and start mis if it's not already running. The backup problem is easy for me to handle. Any script that manages MIS can tell it not to restart by dropping a file called /tmp/upgrade". The file doesn't have to contain anything. If this file exists, the script that attempts to restart MIS will abort. That way, backups and upgrades can be done easily. To restart the BBS, I can
simply remove that file or run the script that restarts MIS directly, because that script also removes /tmp/upgrade.
On 01-21-20 19:10, ryan wrote to Vk3jed <=-
I'm not really a fan of this method. It's pretty brute force...there's
no communicating to a user that there will be maintenance, it's just a terminated connection, no matter what the users may be doing at the
time.
Furthermore I use a systemd service to start mystic on boot and monitor
it being up. killall mis would, in my case, just cause the daemon to restart due to the systemd service. I'd prefer to keep the service
since that's a real true modern linux way of managing services :)
On 01-21-20 19:14, ryan wrote to Vk3jed <=-
I know we're just splitting hairs here but fully killing the mis
process seems unnecessary to me if we just want to pause writing to any
of its files while we do a backup.
I also prefer using an init script (systemd, init.d, for example) to launch and monitor the BBS daemon. I know cronjobs can work, I just
don't think that's the most graceful approach and it's one I'd rather avoid :)
The major reason I'd prefer not killing and restarting mis is the user facing portion. Why not have mis continue to run and respond to
incoming connections with a message that the bbs is undergoing maintenance? Couple that with pre=emptive alerting to users that the
board will go down at a certain time...hell, perhaps even stop allowing incoming connections at a certain time but let your already connected users disconnect as normal, then conduct the maintenance once none of
the nodes are tied up. No user facing negativity there at all.
Being able to shutdown MIS (windows or linux) and MIS -D (linux) gracefully from a command line.
Being able to shutdown MIS (windows or linux) and MIS -D (linux) gracefully from a command line. So if I wanted to run a backup script
and not have MIS running it can be shutdown gracefully without a human being needing to press the ESC key and press enter on YES
I'd even be inclined to vote /more/ strongly for keeping mis running, but when connection attempts are made, it throws some kind of "the bbs is undergoing nightly maintenance, please call back" type message.
Being able to shutdown MIS (windows or linux) and MIS -D (linux) gracefully from a command line. So if I wanted to run a backup script not have MIS running it can be shutdown gracefully without a human be needing to press the ESC key and press enter on YES
A better cross platform approach may be the use of semaphores - which is how Taurus does it.
A better cross platform approach may be the use of semaphores - which how Taurus does it.
Interesting idea... personally I'd love a switch that I could just pass in a batch file to MIS but that's just me :)
So folks who run mysic on linux, could do this with systemd or init/rc start stop scripts. (Although IIRC, mystic shows a WFC type screen when started?)
(When I ran Mystic in docker, I could did this - "docker attach" let me jump onto the console for the WFC screen, but otherwise, my "docker
stop" gracefully shutdown - since mystic intercepts kill signals.)
I use a cron job to both monitor and start mis if it's not already running. The backup problem is easy for me to handle. Any script that manages MIS can tell it not to restart by dropping a file called /tmp/upgrade". The file doesn't have to contain anything. If this file exists, the script that attempts to restart MIS will abort. That way,
I'm not really a fan of this method. It's pretty brute force...there's no communicating to a user that there will be maintenance, it's just a terminated connection, no matter what the users may be doing at the time.
In Linux running "mis shutdown" should do it for you to shutdown the service from the command line. You might need to use sudo to do it.
There isn't a service in Windows so it doesn't work, but maybe I can expand on it so that it can do a shutdown of the UI. I'll look into
maybe having a semaphore file that will force the UI or daemon to shutdown.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 369 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 100:39:39 |
| Calls: | 7,897 |
| Files: | 12,968 |
| Messages: | 5,793,761 |