Reboot required and restarting services
At home I use mostly Slackware, but at work I maintain Debian, Ubuntu, and CentOS systems. Those systems provide users a way to know when a reboot is required. These tools are informative only and do not automatically reboot anything.
With Slackware the closest tool I am aware is slackpkg notifying the user when the kernel is updated and asking whether to update lilo. I have no idea if slapt-get provides such an option. From what I gather, a reboot probably is required or prudent when the following packages are updated: dbus glibc glibc-solibs gnutls kernel kernel-firmware openssl openssl-solibs udev In a similar note, the init system that shall not be discussed in this forum automatically restarts daemon services when the respective package is updated. Some folks probably suck air through their teeth when reading that, but I have experienced no problems with that design. I don't think Slackware supports any such mechanism outside perhaps the doinst.sh script. Would be nice to hear technical ideas about adding similar tools to Slackware. Thanks. :) For example: Modify the doinst.sh scripts of affected packages. Something like: Code:
echo "$PKG_NAME" >> /run/reboot-required.pkgs For restarting services, perhaps a variable container /etc/default/restart-service: Code:
RESTART=false/true Code:
RESTART=false There likely are other considerations. For example, some services do not need to be restarted but need to reload config files. There is some precedence for something like. The glibc doinst.sh script has init reloading to avoid stale file handles. |
Quote:
Quote:
If you're referring to just a notice/reminder that a reboot is needed to finish an installation of a package my blood pressure drops closer to normal. I imagine a timeline where the "reminder" notice is eventually read by install scripts that act on the advice and reboot during an install (even if you didn't want the reboot to happen). I admire appreciate the technical aspects of your suggestions but my initial reaction is negative to the idea of a reboot (due to a package installation) that I didn't explicitly initiate. I can change my mind as I read more posts in this thread from others. For example for remote maintenance I can see some value in having a standardized reboot mechanism. A mechanism that can be disabled if not desired. Anyway that's just my initial gut reaction. Probably colored a lot from my Windows 10 experience helping others. EDIT: I just noticed that you use the term "reboot" but you may actually be talking about stopping and starting daemons not rebooting the operating system. |
You could drop down to runlevel 1 and then back to 3 or 4 (depending upon your setup). Obviously, if you've changed the kernel, you'll need a reboot.
Rather brute force, but should work for most things. |
Quote:
Quote:
On a technical note, the Debian/Ubuntu folks have a simple but elegant mechansism for these notifications, which is where I derived my example in the original post. But their method of delivery requires being enabled in the post install scripts. As I mentioned, the closest thing Slackware has to that delivery is the doinst.sh script, which on the surface, seems just fine as the delivery vehicle. And we are not discussing modifying every doinst.sh script. Just those where rebooting a system is required or prudent, or where restarting a service script is desired and when optionally configured. The doinst.sh scripts would not notify users. They would only populate a text file that resides in tmpfs. End-users would still have to parse that text file to provide a visual notification. For many Slackers that likely would be some kind of script or cron job. Quote:
|
@upnort
I'm wondering what are you doing when you don't have anything to do, that's my honest and profoundly sincere reaction to your original post. Now I would like to ask you kindly, if you don't mind, to describe technically and objectively the reasons behind what drove you to believe that a reboot is "probably" required or "prudent" for the list you came up with. You should take the kernel & kernel firmware out of the list and you shouldn't spend (waste) time with d-bus, while a good idea, the design/implementation is wrong in so many directions & dimensions (just google it to save time and space on LQ). Quote:
I rest my case. |
upnort, you already seem to understand that the automatic service restarts and reboots in many distros are not "The Computer Telling You That It Needs Restarting". It was "Somebody Out There" in the distro who decided a long time ago that "It Should Always Happen" in particular circumstances, as a matter of "Policy", and "They" have put stuff into "Your Computer" to "Make It Happen".
If you want a Policy like that, it's up to you to make it happen. There is a valid use case for this kind of thing. Personally, I'd rather decide for myself, depending on the nuances of the circumstances, especially "is it important" and "is it convenient", but hey, that's just me. You've made an interesting start, but it would be much less intrusive to put it into (for example) a slackpkg extension. |
I don't believe the packaging system is the appropriate place for functionality like this: do one thing and do it well! For one, some services have dependencies to consider: stop b, stop a, restart a, restart b, etc and the packaging system can't handle that.
I suspect most experienced sysadms will have their own way of handling this sort of thing either manually or through shell/perl scripts. Anyway, here's a small bash function I use which you may find useful next time you have to do this: Code:
stale-pids() Code:
root@ws1:~$ stale-pids |
Very nice bash function GazL !
Thanks ! -- kjh p.s. I don't believe the package manager is the best place for restarting servers either. |
Well, the reason for integrating a service restart with updating the package is to minimise the time between updating the package and restarting the service, and to ensure that nobody ever forgets to restart.
The problem is that the ideal cycle is not (1) update package (2) restart service, but (1) wait for a good opportunity (2) stop service (3) update package (4) merge config changes (5) start service. |
Quote:
Slackware has doinst.sh which is strictly a post-install script ... I suppose doinst.sh could do (step(2) + step(5)) as restart service but I think it is important to look at the .new files first. The thing is that, step(4) - 'merge config changes' can take a bit of time to sort out so I don't want the restart the service feature in doinst.sh at all. My $0.02 -- kjh |
FWIW, here’s how I handle it:
Code:
# slackpkg update Quote:
Quote:
|
Quote:
Quote:
Quote:
Quote:
That said, seldom do config files in package updates, which for Slackware are almost always security only, change in a disruptive manner. Likewise for the rc.d files. @GazL, thank you for your technical idea. Your shell script function looks similar to something the Red Hat folks provide with the yum-utils package, a python script called needs-restarting. That script also looks at stale PIDs to find possible reboot or service restart candidates. As I shared in my previous posts, this is not about forcing a reboot or service restart, although the init system that shall not be discussed in this forum restarts services automatically. Likely the needs-restarting script could be massaged by a python wizard to adapt to an OS outside of Red Hat. The needs-restarting script is mildly anemic though because some kind of script wrapper is needed to actually inform users and is not as straightforward as the Debian/Ubuntu notification method. Or the user has to manually run the script. I don't think the needs-restarting script is much popular anymore, now that the init system that shall not be discussed in this forum automatically restarts services when updated. Because of those automatic restarts, mostly only kernel or glibc updates now require a full reboot to be effective. As your shell script function is short and sweet, perhaps something like that could be merged into slackpkg. I don't know if the maintainer (Roberto) is interested. I am prepared to help test if he is. @ Others, I asked for technical ideas about providing users information. That's all. I did not ask for questioning my motives or sanity or something out of Alice's Restaurant, where people jump up and down yelling, "Kill, kill, kill!" The Salix folks have done much to provide admin tools for users. GUI admin tools no less. As have other derivative Slackware distro maintainers. Nobody is required to use those tools, but they have their place. This was the spirit in which I started this thread. I had not advocated any kind of coup d'état. I asked only for some technical ideas. If you want a use case, sure. We use Proxmox (Debian), Ubuntu, and CentOS where I work. These distros provide methods to inform users when a reboot is required. Emphasis again on the word inform. The people I work with are not technical idiots. They are busy and prefer automation when convenient. These folks use Windows but they also use Ubuntu desktops. Ubuntu builds on the Debian method for informing users and provides a GUI notification when a reboot is required. As Ubuntu uses the init system that shall not be discussed in this forum, services are automatically restarted. These co-workers see and like this convenience. These people see computers as tools. Nothing more. They don't care if they use Windows or Ubuntu. Just get the job done and with some hope of satisfaction and minimal disruption. While I use Slackware at home and prefer Slackware, I also have Ubuntu and CentOS systems running at home because of their relationship to work. I too observe the convenience of services being restarted automatically and reboot notification reminders. While I am always aware when a kernel is updated, which requires a reboot to be effective, I see the GUI notifications as a good thing for co-workers. While they are not technically incompetent, being busy means the notices help them do what is needed to take advantage of updates. Some of the co-workers use Ubuntu and CentOS at home too and the big reason is the tools that help them bridge the gap between their busy lives and what is needed to maintain their computers. This is not about geek creds or soap box boasting. This is about using computers as tools to improve lives. This use case is more or less in the spirit of how could Slackware meet the needs of such busy people. Perhaps this ties into the discussion I started this past summer about using Slackware in business. That was a healthy and informative conversation. I wish that conversation is the kind of response that all visitors to this forum would always see. Again, thanks to those who provided technical comments. |
In my opinion, it's not the Slackware way to try to perform system admin tasks automatically, especially ones that may require manual intervention like updating config files and other things that may differ on a case-by-case basis. So I say, interesting idea, but no thanks.
|
Please forgive me, upnort, if this seems at all dense or offensive since it is not intended at all, but as I understand it, unless one restarts a service or reboots to restart all services, the system does not require a reboot.... only the updated/upgraded application might. The system will continue running as it had until then. An example is found in lilo where no amount of modifying "/etc/lilo.conf" becomes effective until one runs "/sbin/lilo" to 'seal the deal" and since the user just modified the .conf file to achieve some change why would they not also know to run "lilo"? to effect that change?
So since the user apparently just upgraded something it seems to me it quickly becomes obvious whether or not a restart of services or a reboot is required since the previous version will not do what the upgrade was meant to accomplish, lest why upgrade at all? TLDR I don't understand why notification is needed at all since it seems redundant. So what purpose do you suppose that extra notification serves? |
Quote:
I don't like the idea of the doinst.sh file restarting services automatically. I want to be the one to determine when those services are stopped and started, not a post-installation script. I would say this is a great feature that 3rd-party package managers could provide (by referencing that file), allowing users to restart all services that were upgraded, but I feel it shouldn't be part of the stock install as it doesn't seem very Slackware-like. All that being said, I don't think it is worth the effort of Pat and team to go redo all the doinst.sh files to output into /run/. It is a lot of work and there is nothing that can currently utilize it unless someone references it directly. |
All times are GMT -5. The time now is 07:49 PM. |