Situation: /etc/init.d/atd --quiet status * /etc/init.d/atd uses runscript, please convert to openrc-run. Should be: quiet should be quiet without warning messages Otherwise you get plenty of warning messages while using the statement in scripts, or crontabs, i.e.: /etc/init.d/atd --quiet status || /etc/init.d/atd --quiet restart * /etc/init.d/atd uses runscript, please convert to openrc-run. So, pls make quiet as it should be - quiet agein :)
There's nothing for me to do here in OpenRC. The packages have init scripts with a shebang line that is being deprecated. Most of these are already actually fixed in the tree. Find the scripts that are complaining and run this command as root: emerge /etc/init.d/<scriptname> That should fix the init scripts. If you still have one that complains after doing that, file a bug against the package. Thanks, William
Well, just a remark: net.lo still uses runscript atm PS: won't file a bug for netifrc
That is fixed in netifrc 0.4.0.
Am I missing something: eix -e netifrc [I] net-misc/netifrc Available versions: 0.2.2{tbz2} ~0.2.3 ~0.2.4 ~0.3.0 ~0.3.1 ~0.4.0 **9999 Installed versions: 0.2.2{tbz2}(09:56:15 PM 08/16/2016) Homepage: https://www.gentoo.org/proj/en/base/openrc/ Description: Gentoo Network Interface Management Scripts
When --quiet doesn't make it quiet ... that could be interpreted as a valid error.
To suppress errors/warnings, use --quiet --quiet.
(In reply to William Hubbs from comment #6) > To suppress errors/warnings, use --quiet --quiet. How is this to understand? Do you really mean, to use "--quiet --quiet" as option? Will this suppress warnings and errors or only warnings? If it suppresses errors and warnings, then it's not the real deal, since errors shouldn't be suppressed. Warnings aren't important for running a service… so anyhow, what's the deal now?
If --quiet does not suppress warnings and if --quiet --quiet suppresses both warnings and errors, then this issue isn't invalid and still not resolved.
You may have a point. However, keep the following in mind. This is not an error because things still work, but it is an extremely significant warning, because /sbin/runscript will no longer exist at some point in the future. Once that happens, you could very easily end up with an unbootable system or some services not starting if the scripts are not updated. Because of the significance of this, I strongly prefer that you do the following instead of suppressing the message: 1. as root, run this command: # emerge /etc/init.d This will update all packages that have service scripts. Once that is done, if you still see this warning, file bugs against the packages that are still producing it. That way you will assist us with making sure all of the services are transitioned.
(In reply to William Hubbs from comment #9) > You may have a point. However, keep the following in mind… Thanks for that comment and and input and making things clear. This now makes sense.
I did updates today and have this problem also. I have not yet run emerge /etc/init.d but will and will report back if it doesn't fix everything. I must say that as a stable user I'm really surprised this was allowed to happen.
Reporting back - running emerge /etc/init.d seems to have fixed most of it, but I still get the messages for a few things, specifically: /etc/init.d/udev /etc/init.d/net.lo /etc/init/d/eth0 After that the screen goes black as the machine switches to X11. I can shut that off and boot without X if it's somehow important but I doubt it is. NOTE: I'm posting to this existing bug report although I was not using --quiet. (And don't intend to...) If I might make a suggestion, someone should put out a news item suggesting the emerge action so that other stable users don't have to search this out on their own.
(In reply to Mark Knecht from comment #11) > I did updates today and have this problem also. I have not yet run > > emerge /etc/init.d > > but will and will report back if it doesn't fix everything. > > I must say that as a stable user I'm really surprised this was allowed to > happen. This change has been in the works since this commit: http://github.com/openrc/openrc/commit/3470ed When I started this process, there were concerns about the messages being annoying so this was done rather than fixing the packages. http://github.com/openrc/openrc/commit/d1e71b OpenRC 0.21.3 just brings back the messages. We updated the scripts in the tree to have the change, we just left it to maintainers to decide whether a one line change in the scripts was worth a revbump and going through the stabilization process, revbumping straight to stable, or waiting for a new upstream version What the emerge action does is accelerates the update that will come to you when the maintainer either revbumps or does a stable request for a newer version. New installations will not get near as many messages. It isn't a breaking change, it just makes OpenRC complain pretty loudly. (In reply to Mark Knecht from comment #12) > Reporting back - running emerge /etc/init.d seems to have fixed most of it, > but I still get the messages for a few things, specifically: > > /etc/init.d/udev I'll take a look at this one, because I'm also a maintainer there. > /etc/init.d/net.lo > /etc/init/d/eth0 This is netifrc, that should be a separate bug asking that #!/sbin/runscript be changed to #!/sbin/openrc-run. > After that the screen goes black as the machine switches to X11. I can shut > that off and boot without X if it's somehow important but I doubt it is. That is not going to make a difference. You could do this if you want to see if there are others: $ cd /etc/init.d $ grep '^#/sbin/runscript' * > If I might make a suggestion, someone should put out a news item suggesting > the emerge action so that other stable users don't have to search this out > on their own. I'm open to that, but let me post to dev and see if folks think this is news-item worthy or not.
Let me apologize for sort of harsh language earlier. I'm not upset and you don't deserve to get dumped on so please accept my apology. I have some frustrations with Gentoo package management over the last year or two that bubbles up now and again. I should not let that happen. Maybe there aren't a lot of users like me - I've used Gentoo since 2004 but for the last 5 years have restricted myself to using only stable packages as much as possible. I don't subscribe to gentoo-users and don't follow development at all. I run multiple Windows VMs on Gentoo to do my work and in general Gentoo works very well for me. My POV on the news item is simply that for people who expect a clean OpenRC bootup with just a lot of green *OK's seeing all these messages made me first think the whole machine was going to fail. Even when it came up I was worrying that I wouldn't have a network connection to find out what the solutions would be. I worried that I'd have to spend hours/days/weeks getting things working again, wondering what computer I would be using when I need to be working on Monday. Of course, none of that happened, but my opinion is that a stable user shouldn't have to even have thoughts like that. A news item that warned me ahead of time that this was coming and told me to chill as these are just warnings would have completely eliminated that worry for me. Anyway, thanks very much for the help and please accept my apologies. $ cd /etc/init.d $ grep '^#/sbin/runscript' * returned nothing so I guess that's it. I'll look into whether a netifrc bug report has been filed.
If the original report was about the fact, that a runscript outputs warnings even if you call it with "--quiet" than I agree with Patrick (comment #5): > # /etc/init.d/test2 --quiet --quiet --quiet --quiet status > * /etc/init.d/test2 uses runscript, please convert to openrc-run. So "--quiet --quiet" obviously doesn't work (but I assume William mixed it with start-stop-daemon's quiet parameter but this is about the runscript itself). Also, it looks like the deprecation warning is treated differently (and I guess this should be fixed): > # cat /etc/init.d/test2 > #!/sbin/runscript > # Copyright 1999-2013 Gentoo Foundation > # Distributed under the terms of the GNU General Public License v2 > # $Header: $ > > depend() { > return 0 > } > > start_pre() { > ewarn "Test warning" > } > > start() { > einfo "starting $RC_SVCNAME" > } > > stop() { > einfo "stopping $RC_SVCNAME" > } > # /etc/init.d/test2 restart > * /etc/init.d/test2 uses runscript, please convert to openrc-run. > * stopping test2 > * Test warning > * starting test2 and > # /etc/init.d/test2 --quiet restart > * /etc/init.d/test2 uses runscript, please convert to openrc-run. The normal "ewarn" is suppressed when using "--quiet" but the deprecated warning isn't.
(In reply to Mark Knecht from comment #14) > Let me apologize for sort of harsh language earlier. I'm not upset and you > don't deserve to get dumped on so please accept my apology. No problem. > I have some frustrations with Gentoo package management over the last year > or two that bubbles up now and again. I should not let that happen. Oh trust me, I know what you mean. I have some frustrations as well. One of which is that the stable tree seems so far out of date these days that Debian stable is starting to be ahead of us. > Maybe there aren't a lot of users like me - I've used Gentoo since 2004 but > for the last 5 years have restricted myself to using only stable packages as > much as possible. I don't subscribe to gentoo-users and don't follow > development at all. I run multiple Windows VMs on Gentoo to do my work and > in general Gentoo works very well for me. I'm glad to hear that. I've been a dev for as long as you have been a user I guess (since April 2004 or so). I stay with Gentoo because it, in my opinion, is the most flexable distro out there. > My POV on the news item is simply that for people who expect a clean OpenRC > bootup with just a lot of green *OK's seeing all these messages made me > first think the whole machine was going to fail. Even when it came up I was > worrying that I wouldn't have a network connection to find out what the > solutions would be. I worried that I'd have to spend hours/days/weeks > getting things working again, wondering what computer I would be using when > I need to be working on Monday. Of course, none of that happened, but my > opinion is that a stable user shouldn't have to even have thoughts like that. I do my best with OpenRC to not send something through that will break stable, but I see what you mean. I posted a msg back to the list, and I'll see whether or not it is news-worthy. If it is, you will see the newsitem as well, because I'll post it so that openrc users with stable openrc see it. > Anyway, thanks very much for the help and please accept my apologies. > > $ cd /etc/init.d > $ grep '^#/sbin/runscript' * > > returned nothing so I guess that's it. Actually I missed a character in the grep. It should be: grep '#!/sbin/runscript' * > I'll look into whether a netifrc bug report has been filed. I already have this answer actually; this is fixed in 0.4, but that isn't stable yet. (In reply to Thomas Deutschmann from comment #15) > Also, it looks like the deprecation warning is treated differently (and I > guess this should be fixed): > > > # cat /etc/init.d/test2 > > #!/sbin/runscript > > # Copyright 1999-2013 Gentoo Foundation > > # Distributed under the terms of the GNU General Public License v2 > > # $Header: $ > > > > depend() { > > return 0 > > } > > > > start_pre() { > > ewarn "Test warning" > > } > > > > start() { > > einfo "starting $RC_SVCNAME" > > } > > > > stop() { > > einfo "stopping $RC_SVCNAME" > > } Add a call to eerror to the start_pre function, then when you restart with -q or -qq (this is the short form of --quiet and --quiet --quiet), you should see that -q suppresses einfo messages and -qq suppresses ewarn/error messages as well. > > # /etc/init.d/test2 restart > > * /etc/init.d/test2 uses runscript, please convert to openrc-run. > > * stopping test2 > > * Test warning > > * starting test2 > > and > > > # /etc/init.d/test2 --quiet restart > > * /etc/init.d/test2 uses runscript, please convert to openrc-run. > > The normal "ewarn" is suppressed when using "--quiet" but the deprecated > warning isn't. I think this is the issue, the deprecation warning is treated differently than other ewarns, and I will take a look at this.
(In reply to William Hubbs from comment #16) > Add a call to eerror to the start_pre function, then when you restart with > -q or -qq (this is the short form of --quiet and --quiet --quiet), you > should see that -q suppresses einfo messages and -qq suppresses ewarn/error > messages as well. > > > > # /etc/init.d/test2 restart > > > * /etc/init.d/test2 uses runscript, please convert to openrc-run. > > > * stopping test2 > > > * Test warning > > > * starting test2 > > > > and > > > > > # /etc/init.d/test2 --quiet restart > > > * /etc/init.d/test2 uses runscript, please convert to openrc-run. > > > > The normal "ewarn" is suppressed when using "--quiet" but the deprecated > > warning isn't. > > I think this is the issue, the deprecation warning is treated differently > than other ewarns, and I will take a look at this. OK: I had set > start_pre() { > ewarn "Test warning" > eerror "Test error" > return 0 > } Call this script with a single "--quiet" suppresses the "ewarn". Calling the script with two "--quiet" parameters (or "-qq") als suppresses the "eerror". From my view there are two things to do: 1) Update openrc-run man page to document that the "--quiet" parameter can be used multiple times. 2) Check (and fix ;)) why the deprecation warning which looks like an ewarn is shown when you call the script with "--quiet" parameter.
OK, the modified command agrees with what I filmed when my machine boots. c2RAID6 init.d # grep '#!/sbin/runscript' * net.eth0:#!/sbin/runscript net.eth1:#!/sbin/runscript net.lo:#!/sbin/runscript udev:#!/sbin/runscript c2RAID6 init.d # Thanks!
https://github.com/openrc/openrc/commit/69ac78d The above commit fixes the original bug and will be included in OpenRC 0.21.4. The man pages are a separate issue, and I'll look at that for 0.22; multiple man pages may need to be updated. That could be debatable though since using -q twice is mentioned in the help.
I will also be publishing a news item soon.
