LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Reboot required and restarting services (https://www.linuxquestions.org/questions/slackware-14/reboot-required-and-restarting-services-4175617159/)

upnort 11-07-2017 06:04 PM

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
As /run is mounted with tmpfs, the file vanishes with a reboot.

For restarting services, perhaps a variable container /etc/default/restart-service:

Code:

RESTART=false/true
In the respective doinst.sh:

Code:

RESTART=false
if [ -r /etc/default/restart-service ]; then
  . /etc/default/restart-service
fi
if [ "$RESTART" = "true" ] && [ ! -e /etc/rc.d/rc.service.new ]; then
  /etc/rc.d/rc.service restart
fi

That kind of change requires Pat agreeing and adopting the idea. Otherwise something else is needed to sniff updates.

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.

TracyTiger 11-07-2017 09:39 PM

Quote:

Originally Posted by upnort (Post 5778035)
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.

My initial reaction to reading your post ...

Quote:

... any such mechanism ... similar tools ...
If you're referring to an automatic reboot, (to be polite instead of what I'm really thinking) No Thank You. I can install Windows 10 if I want to give up control of my systems. I think auto-reboot is probably bad idea for technical reasons even during a maintenance procedure.

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.

Richard Cranium 11-07-2017 10:04 PM

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.

upnort 11-07-2017 10:34 PM

Quote:

If you're referring to an automatic reboot, (to be polite instead of what I'm really thinking) No Thank You.
Golly gee willikers Mr. Wilson! I thought I was clear in my post. Where, oh where did I mention anything about auto-reboot? I would have thought my posted example made clear that I was discussing a reboot notification and the option to have services automatically restarted.

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.
Yes, yes! :)

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:

Rather brute force, but should work for most things.
I had thought about that, which could work for restarting services but not for rebooting with a change in the kernel or (I think) glibc. Also seems like sledge hammer when /etc/rc.d/rc.service restart|reload would suffice. :)

abga 11-08-2017 01:36 AM

@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:

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
I would also like to mention that some 22 years ago, when I first touched Unix (BSD/Linux) I was not allowed to gain root for at least half a year during my learning experience and those were test/play systems. Now, as a "modern apt-get-apt-don't-get-apt-never-know-what-you-get" administrator if you're that inexperienced that you don't realize a service restart is required after the update of its components, then you should well learn out of your mistakes, that's the best teacher by the way.
I rest my case.

55020 11-08-2017 03:22 AM

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.

GazL 11-08-2017 04:35 AM

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()
{
  if [[ "$1" == '-v' ]] ; then
    find -H /proc/{1..9}*/map_files -type l -ilname '*lib*.so* (deleted)' -printf '%h %l\n' 2>/dev/null \
      | sed -e 's|/proc/||;s|/map_files||'
  else
    find -H /proc/{1..9}*/map_files -type l -ilname '*lib*.so* (deleted)' -printf '%h\n' 2>/dev/null \
      | cut -f3 -d'/'
  fi | sort -u | grep -F ''
}

e.g.
Code:

root@ws1:~$ stale-pids
1860
1948
1990
1991
1992
1993
1994
1995
1998
root@ws1:~$ stale-pids -v
1860 /lib64/libcrypto.so.1.0.0 (deleted)
1860 /lib64/libssl.so.1.0.0 (deleted)
1948 /lib64/libcrypto.so.1.0.0 (deleted)
1948 /lib64/libssl.so.1.0.0 (deleted)
1990 /lib64/libcrypto.so.1.0.0 (deleted)
1990 /lib64/libssl.so.1.0.0 (deleted)
1991 /lib64/libcrypto.so.1.0.0 (deleted)
1991 /lib64/libssl.so.1.0.0 (deleted)
1992 /lib64/libcrypto.so.1.0.0 (deleted)
1992 /lib64/libssl.so.1.0.0 (deleted)
1993 /lib64/libcrypto.so.1.0.0 (deleted)
1993 /lib64/libssl.so.1.0.0 (deleted)
1994 /lib64/libcrypto.so.1.0.0 (deleted)
1994 /lib64/libssl.so.1.0.0 (deleted)
1995 /lib64/libcrypto.so.1.0.0 (deleted)
1995 /lib64/libssl.so.1.0.0 (deleted)
1998 /lib64/libcrypto.so.1.0.0 (deleted)
1998 /lib64/libssl.so.1.0.0 (deleted)
root@ws1:~$ ps -ho cmd $(stale-pids)
wpa_supplicant -B -c /etc/wpa_supplicant/wlan0.conf -i wlan0
/usr/sbin/ntpd -g -x -u ntp:ntp
/usr/sbin/smtpd
smtpd: klondike
smtpd: control
smtpd: lookup
smtpd: pony express
smtpd: queue
smtpd: scheduler
root@ws1:~$

(I removed and readded the ssl packages to give the example above)

kjhambrick 11-08-2017 04:40 AM

Very nice bash function GazL !

Thanks !

-- kjh

p.s. I don't believe the package manager is the best place for restarting servers either.

55020 11-08-2017 05:05 AM

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.

kjhambrick 11-08-2017 05:27 AM

Quote:

Originally Posted by 55020 (Post 5778180)
<<snip>>
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.

Yes, some of the other package management systems include a mechanism to run a 'pre-install' script which could do step(2) for you.

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

urbanwks 11-08-2017 06:50 AM

FWIW, here’s how I handle it:

Code:

# slackpkg update
# slackpkg upgrade-all

Quote:

Originally Posted by “my brain”
What’s it upgrading?

Quote:

Originally Posted by “my brain again”
Ok, it’s upgrading the kernel. Reboot if I want to use it.


upnort 11-08-2017 12:59 PM

Quote:

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 agree that this gets complicated. I don't know how the other distro developers support this complexity. Perhaps they don't and just restart each service on its own. Of course, they never reboot systems automatically.

Quote:

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.
Yes, again, no easy answer. Although my experience is that often enough, not always, just often enough, services can be restarted without disrupting systems in any way.

Quote:

You've made an interesting start, but it would be much less intrusive to put it into (for example) a slackpkg extension.
I agree that an external tool likely is the better place to monitor this kind of thing. I had thought about a slackpkg method because that is the common medium through which most Slackware users update their systems.

Quote:

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.
Yes, if you look at the example I posted in the original post you'll see that I would not restart a service if a respective new file exists. My example only included a new rc.d script but could be expanded to look for new config files too. slackpkg does support this by prompting users to review differences in config files.

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.

montagdude 11-09-2017 12:37 PM

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.

enorbet 11-09-2017 04:05 PM

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?

bassmadrigal 11-09-2017 05:06 PM

Quote:

Originally Posted by enorbet (Post 5778855)
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?

In my mind, I can see a benefit behind having a file in /run/ mentioning packages that had been updated that might have running services. It could be a handy file that some users or package managers could use to prompt restarting services (or rebooting the computer for those few packages that need a reboot for it to take effect)... but I'd never use it. For me, I think it is plenty easy to just do ls -lart /var/log/packages which will show me a list of all packages sorted by when the latest version was installed. That is enough for me to determine what services I might need to restart or if I need a reboot (if I didn't happen to pay enough attention during the upgrade process, or I got sidetracked and forgot what packages were upgraded). I don't reboot my computer unless absolutely necessary (kernel upgrade or the like), because I run several local and web-facing services on it.

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.