Rather than dropping the dupe, rx was appending it to the file.
Signed-off-by: Dan Fandrich <dan@coneharvesters.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Allows one to specify list of filesystem types to be
tried when mounting particular device. E.g.
mount -t vfat,ext2 ...
Signed-off-by: Karol Lewandowski <k.lewandowsk@samsung.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Sometimes there's a need to figure out the controlling tty from a shell
script, for example, to obtain a line for getty. In this case it's easier
to call cttyhack than trying to repeat some of the cttyhack's logic.
function old new delta
cttyhack_main 283 327 +44
packed_usage 28911 28915 +4
Signed-off-by: Alexander Shishkin <virtuoso@slind.org>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Function log_locally() within the syslogd can potentially lock up when
restarting the daemon after a power loss in case the unplanned shutdown hit the
rename operation during logfile rotation.
While POSIX requires the rename operation to be atomic, many file systems such
as JFFS2 implement the rename operation in 2 steps by linking the new name
followed by unlinking the original name. In case of a power loss during the
rename the system can end up with /var/log/messages and /var/log/messages.0
being 2 hard links to the same file.
When the syslog daemon restarts in such a situation it will rediscover the need
to rotate the log files, however, POSIX also requires that rename does nothing
and reports success in case oldpath and newpath are existing hard links to the
same file. Looping through reopen: by (O_CREAT | O_APPEND), the daemon
eternally reopens the same file without succeeding to rotate.
Signed-off-by: Christian Engelmayer <christian.engelmayer@frequentis.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Scenario:
1. udhcpc gets lease for 86400 secs and sleeps for 43200 before renew attempt
2. PC gets physically disconnected and connected to another network
3. some phy control software sends SIGUSR1 to renew the lease, SIGUSR2 isn't
used because newly connected network could be the same as before
4. udhcpc sends unicast renew requests until lease timeout fall to 60 sec.
They are ignored by new network dhcp servers
5. udhcpc sends broadcast rebind requests for 60 seconds, which are NAKed
or ignored too
6. udhcpc deconfigs and starting from discover state, gets new lease for the
new network
So, pt.4+5 it could take up to 86400 secs without correct lease, which is
too long and not acceptable.
Second SIGUSR1 will immediately run into deconfig/discover state, which is
not preferable in case of the same subnet replugged.
This patch makes sure after SIGUSR1 timeout is no more than -A NUM
(usually 20 sec). It means that renew will be requested via broadcast,
and if no replies come back, full deconf/reconf cycle will be initiated
in 20 seconds.
Signed-off-by: Vladislav Grishenko <themiron@mail.ru>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Progress bar updates flicker quite a bit on slow hw / high resolutions
as the background is completely cleared before the new progress bar
position is drawn on top.
Improve it by first drawing the progress bar and then only fill the
remaining rows with the background.
function old new delta
fb_drawprogressbar 444 429 -15
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
