(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

https://github.com/fedora-sysv/initscripts/pull/129

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.

(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 --

(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.