Bug 1494168
Summary: | usleep: warning: use sleep(1) instead... | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Harald Reindl <h.reindl> |
Component: | initscripts | Assignee: | David Kaspar // Dee'Kej <deekej> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 26 | CC: | deekej, harald, jonathan, kdudka, lnykryn, vpavlin, zbyszek, zenczykowski |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | initscripts-9.78-1.fc28 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-03-15 09:43:25 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Harald Reindl
2017-09-21 14:59:21 UTC
Comment hidden (abuse)
(In reply to Harald Reindl from comment #0) > which drunken sailor pretends usleep can be replaced by sleep I believe it can because sleep(1) takes also numbers below 1. > (ignoring that it don't care about the value in the error message at all) The numbers in brackets refer to the corresponding man page sections. > [root@testserver:~]$ usleep 10 You should be able to use the following command instead: $ sleep .00001 upstream commit: https://github.com/fedora-sysv/initscripts/commit/fc9eb02e Could we please keep usleep around, even if as a symlink to sleep with sleep being smart enough to handle the divide by 1000000 based on its name (busybox/gzip style)? That's so much easier than having *everyone* update their shell scripts, and the warning is frickin' annoying (and actually breaks things which expect no output on stderr during successful execution). It's really not worth the pain of trying to deprecate. (In reply to Maciej Żenczykowski from comment #4) > Could we please keep usleep around, even if as a symlink to sleep with sleep > being smart enough to handle the divide by 1000000 based on its name > (busybox/gzip style)? I implemented a similar solution (see bug #1189877 comment #10) but it was not used in the end. You can't stop progress... (In reply to Maciej Żenczykowski from comment #4) > Could we please keep usleep around, even if as a symlink to sleep with sleep > being smart enough to handle the divide by 1000000 based on its name > (busybox/gzip style)? > > That's so much easier than having *everyone* update their shell scripts, and > the warning is frickin' annoying (and actually breaks things which expect no > output on stderr during successful execution). > > It's really not worth the pain of trying to deprecate. Unfortunately, we have to move forward somehow. We expect the network-scripts/initscripts to become deprecated soon in the future, and dropping them later on. I realize this can be painful, but it's better to issue warning on stderr (which is a common way to do it), rather than drop usleep completely without a warning at some point. > Unfortunately, we have to move forward somehow no - remove things is not moving forward > We expect the network-scripts/initscripts to become deprecated > soon in the future, and dropping them later on than do it like iptables.service which just moved the initscripts somewhere else removing "network.service" will do more harm on as many machines than you ever can imagine - there are setups wich more than just a ifcf-eth0 file and many of them are hundrets of miles away and they last thing you want do there is rework the networking when the machine is the router/firewall/vpn-gateway over a ssh-session if it ain't broken don't fix it (In reply to Harald Reindl from comment #7) > > Unfortunately, we have to move forward somehow > > no - remove things is not moving forward Unless you have something to replace it with - which we actually have - and it's called NetworkManager. > > We expect the network-scripts/initscripts to become deprecated > > soon in the future, and dropping them later on > > than do it like iptables.service which just moved the initscripts somewhere > else Moving them somewhere else won't warn people that the initscripts are deprecated. This would be just solving a problem with just moving it into a different shelf - in other words - not solving it at all. > removing "network.service" will do more harm on as many machines than you > ever can imagine - there are setups wich more than just a ifcf-eth0 file and > many of them are hundrets of miles away and they last thing you want do > there is rework the networking when the machine is the > router/firewall/vpn-gateway over a ssh-session Who said something about network.service? If you want to argue or discuss something, then stop using logical fallacies (straw-man in this case). Do you really think I don't already realize what you have written? This has been discussed for a long time now, and we aware of the setups relying on network-scripts (more than you think). So, stop making simple conclusions based on one informative comment. And stop assuming everyone except you is stupid - it's quite offensive. > if it ain't broken don't fix it It is broken - you just don't see the complexities of it. And because network-scripts are limited (and broken in many cases) is the reason(s) why we have NetworkManager as default these days. Good bye. it's not only about "network-scripts" - th epoint is that the are not managed by a daemon and you can do a lot of complex things with "ifconfig" (yeah another deprecated "if it ain't broken don't fix it" nd no ipv6 don't matter in many LAN environments) which is complicated in case of MANAGED devices So, I still don't understand why sleep doesn't simply get a usleep busybox style symlink to it... --- Fixing shell scripts is not so simple. (a) there's soo many of them (b) usleep ${n} does not just become usleep() { sleep "${1}u" } because sleep doesn't accept 'u' 'us' nor even 'ms' as units. Similarly: usleep() { local -r n="$1" sleep $((n/1000000)) } also doesn't work, cause bash only does integer arithmetic. Thankfully printf is a shell builtin, so you can do something like usleep() { local -r n="$1" sleep $(printf "%d.%06d" $[n / 1000000] $[n % 1000000]) } which is *ugly*. Probably the best solution appears to be: usleep() { sleep "${1}e-06" } which isn't really documented, unless you take 'arbitrary floating point number' to mean it's always going to be safe to use scientific notation... I have some idea I'd like to pursue to have better support in the future for this, but I can't guarantee it will happen or when. In the meantime, you can also use this (from /etc/rc.d/init.d/functions): https://github.com/fedora-sysv/initscripts/blob/master/etc/rc.d/init.d/functions#L629 Best regards, -- Dee'Kej -- > This has been discussed for a long time now, and we aware of > the setups relying on network-scripts (more than you think) i see.... ETHTOOL_OPTS ignored, subscriber content https://access.redhat.com/solutions/878503 what is so difficult in "After=network.service systemd-networkd.service network-online.target NetworkManager.service"? works for many years without "NetworkManager.service" and now in 2018 we have ordering issues? [root@testserver:~]$ systemctl status network-routing.service ● network-routing.service - Network Static Routes Loaded: loaded (/etc/systemd/system/network-routing.service; enabled; vendor preset: disabled) Active: active (exited) since Sun 2018-09-09 23:11:31 CEST; 20s ago Process: 660 ExecStartPost=/usr/sbin/route add -net 172.17.0.0 netmask 255.255.255.0 gw 192.168.196.2 dev eth1 (code=exited, status=7) Process: 657 ExecStartPost=/usr/sbin/route add -net 10.0.0.0 netmask 255.255.255.0 gw 192.168.196.2 dev eth1 (code=exited, status=7) Process: 656 ExecStart=/usr/bin/true (code=exited, status=0/SUCCESS) Main PID: 656 (code=exited, status=0/SUCCESS) Sep 09 23:11:31 testserver.rhsoft.net systemd[1]: Starting Network Static Routes... Sep 09 23:11:31 testserver.rhsoft.net route[657]: SIOCADDRT: Das Netzwerk ist nicht erreichbar Sep 09 23:11:31 testserver.rhsoft.net route[660]: SIOCADDRT: Das Netzwerk ist nicht erreichbar Sep 09 23:11:31 testserver.rhsoft.net systemd[1]: Started Network Static Routes. wthat is so difficult in "MTU=1472" - only works on very naive setups i see how much you are aware lan-spare1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether ac:16:2d:a1:74:ee txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0xf7880000-f78fffff lan-spare2: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether ac:16:2d:a1:74:ed txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0xf7900000-f797ffff ---------------------- only god knows why this one interface kept it's setting an the other 5 not, was no issue all the years with network.service poe-phone: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1472 ether 00:e0:4c:80:5c:cb txqueuelen 1000 (Ethernet) RX packets 788 bytes 117551 (114.7 KiB) RX errors 0 dropped 42 overruns 0 frame 0 TX packets 671 bytes 106856 (104.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 why the fuck do you think you need to restart dhcpd.service evertime a link status on a bridnge changes and why can't this crap just configure the interfaces as told on startup and then exit itself instead waste 16 MB RAM on 40 vms in a cluster with only static configs? Sep 10 00:57:05 srv-rhsoft nm-dispatcher[12580]: req:1 'down' [lan-tv]: new request (4 scripts) Sep 10 00:57:05 srv-rhsoft nm-dispatcher[12580]: req:1 'down' [lan-tv]: start running ordered scripts... Sep 10 00:57:05 srv-rhsoft nm-dispatcher[12580]: req:2 'pre-up' [lan-tv]: new request (1 scripts) Sep 10 00:57:05 srv-rhsoft NetworkManager[1253]: <info> [1536533825.4822] device (lan-tv): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'external') Sep 10 00:57:05 srv-rhsoft NetworkManager[1253]: <info> [1536533825.4831] device (lan-tv): state change: secondaries -> activated (reason 'none', sys-iface-state: 'external') Sep 10 00:57:05 srv-rhsoft NetworkManager[1253]: <info> [1536533825.4845] device (lan-tv): Activation: successful, device activated. Sep 10 00:57:05 srv-rhsoft nm-dispatcher[12580]: req:3 'up' [lan-tv]: new request (4 scripts) Sep 10 00:57:05 srv-rhsoft nm-dispatcher[12580]: req:3 'up' [lan-tv]: start running ordered scripts... Sep 10 00:57:07 srv-rhsoft systemd[1]: Stopping DHCPD LAN... Sep 10 00:57:07 srv-rhsoft systemd[1]: Stopped DHCPD LAN. Sep 10 00:57:07 srv-rhsoft systemd[1]: Starting DHCPD LAN... Sep 10 00:57:07 srv-rhsoft systemd[1]: Started DHCPD LAN. the whole ordering is BORKEN at all BOTH have "After=network.service systemd-networkd.service network.target network-online.target NetworkManager-wait-online.service NetworkManager.service openvpn.service hostapd.service openvpn.service hostapd.service" but are fired up way too soon "NetworkManager-wait-online.service" obviously don't work at all - that all was no problem with "After=network.service" [root@master:~]$ system-errors.sh Sep 10 01:53:05 master systemd[1]: Failed to start apply settings after network. Sep 10 01:53:05 master systemd[1]: sysctl-post-network.service: Unit entered failed state. Sep 10 01:53:05 master systemd[1]: sysctl-post-network.service: Failed with result 'exit-code'. Sep 10 01:50:47 master rsyslogd[450]: action 'action-11-ommysql' suspended (module 'ommysql'), retry 0. There should be messages before this one giving the reason for suspension. [v8.37.0 try http://www.rsyslog.com/e/2007 ] Sep 10 01:50:47 master rsyslogd[450]: action 'action-11-ommysql' suspended (module 'ommysql'), next retry is Mon Sep 10 01:51:17 2018, retry nbr 0. There should be messages before this one giving the reason for suspension. [v8.37.0 try http://www.rsyslog.com/e/2007 ] Sep 10 01:50:47 master rsyslogd[450]: action 'action-11-ommysql' suspended (module 'ommysql'), retry 1. There should be messages before this one giving the reason for suspension. [v8.37.0 try http://www.rsyslog.com/e/2007 ] Sep 10 01:50:47 master rsyslogd[450]: action 'action-11-ommysql' suspended (module 'ommysql'), retry 2. There should be messages before this one giving the reason for suspension. [v8.37.0 try http://www.rsyslog.com/e/2007 ] Sep 10 01:50:47 master rsyslogd[450]: action 'action-11-ommysql' suspended (module 'ommysql'), retry 3. There should be messages before this one giving the reason for suspension. [v8.37.0 try http://www.rsyslog.com/e/2007 ] Sep 10 01:50:47 master rsyslogd[450]: action 'action-11-ommysql' suspended (module 'ommysql'), retry 4. There should be messages before this one giving the reason for suspension. [v8.37.0 try http://www.rsyslog.com/e/2007 ] (In reply to Harald Reindl from comment #12) > > This has been discussed for a long time now, and we aware of > > the setups relying on network-scripts (more than you think) > > i see.... > > ETHTOOL_OPTS ignored, subscriber content > https://access.redhat.com/solutions/878503 > > what is so difficult in "After=network.service systemd-networkd.service > network-online.target NetworkManager.service"? works for many years without > "NetworkManager.service" and now in 2018 we have ordering issues? You do realize that this BZ has nothing to do with your issues, right? Do you also realize you're posting here a KB article related to RHEL-7? (In reply to Harald Reindl from comment #13) > wthat is so difficult in "MTU=1472" - only works on very naive setups > > i see how much you are aware Do you really think that being a passive-aggressive person will help you with anything? > only god knows why this one interface kept it's setting an the other 5 not, > was no issue all the years with network.service Well, things do break from time to time, no matter how much people do their best. Fedora is moving forward, so it sometimes introduces problems. Nothing's ever perfect. If you have problem with this, then you can consider switching to other Linux distro. But from my 8 years Linux experience, you will never find a perfect distribution. (In reply to Harald Reindl from comment #14) > why the fuck do you think you need to restart dhcpd.service evertime a link > status on a bridnge changes and why can't this crap just configure the > interfaces as told on startup and then exit itself instead waste 16 MB RAM > on 40 vms in a cluster with only static configs? I strongly suggest you go vent your temper / anger issues somewhere else, this is not the place to do so... If you think the things can be improved, then why don't you submit a pull-request with improvement? If you have time to yell about it, you probably also have to time to actually do something about it - that's one of the beauties of Open-Source. (In reply to Harald Reindl from comment #15) > the whole ordering is BORKEN at all > > BOTH have "After=network.service systemd-networkd.service network.target > network-online.target NetworkManager-wait-online.service > NetworkManager.service openvpn.service hostapd.service openvpn.service > hostapd.service" but are fired up way too soon > > "NetworkManager-wait-online.service" obviously don't work at all - that all > was no problem with "After=network.service" Again - you're barking at the wrong tree. And I reckon the "barking" in this case won't get your problem fixed... Just something to think of. Have a nice day. |