Coder Social home page Coder Social logo

fedora-sysv / chkconfig Goto Github PK

View Code? Open in Web Editor NEW
15.0 15.0 29.0 2.35 MB

✔️ A system tool for maintaining the /etc/rc*.d hierarchy.

License: GNU General Public License v2.0

Makefile 2.88% C 76.42% Shell 6.40% Roff 14.31%
alternatives initscript

chkconfig's People

Contributors

0xf2 avatar anipeter avatar bbbush avatar dependabot[bot] avatar diegobz avatar goeranu avatar igorpsoares avatar jamacku avatar jibec avatar kmilos avatar lanurmi avatar lnykryn avatar mswilson avatar mtelka avatar mtrmac avatar nalind avatar nikolay-phxa avatar norwayfun avatar odubaj avatar omshivaprakash avatar paul-j-brown avatar piotrdrag avatar poettering avatar rh-tchuang avatar richard-allen avatar simmon-nplob avatar sshedmake avatar weblate avatar wenottingham avatar yurchor avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar

Forkers

lnykryn msehnout jrybar-rh valentinchcloud odubaj nullr0ute miztake zaryob shellspicker dhodovsk weblate tpgxyz hassoon1986 fayeinseu comradekingu akadata cgwalters judovana xxteraxx zhrf2020 zlnice abhaysp95 jorgectf lyterly jamacku yangyangdaji marcosfrm

chkconfig's Issues

chkconfig does not reload systemd

CentOS Stream 9 (chkconfig-1.24-1.el9.x86_64, systemd-252-18.el9.x86_64). SysV daemons never show up in systemd. I guess systemdActive()

chkconfig/leveldb.c

Lines 948 to 960 in c3511a1

int systemdActive() {
struct stat a, b;
if (lstat("/sys/fs/cgroup", &a) < 0)
return 0;
if (lstat("/sys/fs/cgroup/systemd", &b) < 0)
return 0;
if (a.st_dev == b.st_dev)
return 0;
if (!systemdIsInit())
return 0;
return 1;
}

chkconfig/chkconfig.c

Lines 104 to 107 in c3511a1

static void reloadSystemd(void) {
if (systemdActive())
system("systemctl daemon-reload > /dev/null 2>&1");
}

is broken. Simple test:

#define _GNU_SOURCE
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/stat.h>

int systemdIsInit() {
    char *path = realpath("/sbin/init", NULL);
    char *base = NULL;

    if (!path)
        return 0;
    base = basename(path);
    if (!base)
        return 0;
    if (strcmp(base, "systemd"))
        return 0;
    return 1;
}

int systemdActive() {
    struct stat a, b;

    if (lstat("/sys/fs/cgroup", &a) < 0)
        return 0;
    if (lstat("/sys/fs/cgroup/systemd", &b) < 0)
        return 0;
    if (a.st_dev == b.st_dev)
        return 0;
    if (!systemdIsInit())
        return 0;
    return 1;
}

int main(void)
{
    printf("systemdIsInit(): %d\n", systemdIsInit());
    printf("systemdActive(): %d\n", systemdActive());

    return 0;
}
$ gcc test.c
$ ./a.out
systemdIsInit(): 1
systemdActive(): 0
$ sudo ./a.out
systemdIsInit(): 1
systemdActive(): 0

mem leak in alternatives

i find memory leak in alternatives.c when using AddressSanitizer.the leak main about reallca, strdup, just few bytes. but multiple code leaks. so i can't not decide to modify it or not, i want to know what does github give suggestion about this issue.

Version: 1.10

==8212==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0xffff9f2ab5ab in realloc (/lib64/libasan.so.4+0xd35ab)
#1 0xaaaac8c65e73 (/usr/sbin/alternatives+0x7e73)
#2 0xaaaac8c68437 (/usr/sbin/alternatives+0xa437)
#3 0xffff9f072adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac8c68777 (/usr/sbin/alternatives+0xa777)

Direct leak of 35 byte(s) in 1 object(s) allocated from:
#0 0xffff9f218f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac8c6759b (/usr/sbin/alternatives+0x959b)
#2 0xffff9f072adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#3 0xaaaac8c68777 (/usr/sbin/alternatives+0xa777)

Direct leak of 35 byte(s) in 1 object(s) allocated from:
#0 0xffff9f218f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac8c684df (/usr/sbin/alternatives+0xa4df)
#2 0xffff9f072adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#3 0xaaaac8c68777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 48 byte(s) in 1 object(s) allocated from:
#0 0xffff9f218f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac8c68e1b (/usr/sbin/alternatives+0xae1b)
#2 0xaaaac8c66d07 (/usr/sbin/alternatives+0x8d07)
#3 0xffff9f072adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac8c68777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 47 byte(s) in 1 object(s) allocated from:
#0 0xffff9f218f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac8c68e1b (/usr/sbin/alternatives+0xae1b)
#2 0xaaaac8c66b63 (/usr/sbin/alternatives+0x8b63)
#3 0xffff9f072adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac8c68777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 46 byte(s) in 1 object(s) allocated from:
#0 0xffff9f218f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac8c68d4b (/usr/sbin/alternatives+0xad4b)
#2 0xaaaac8c66d07 (/usr/sbin/alternatives+0x8d07)
#3 0xffff9f072adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac8c68777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 45 byte(s) in 1 object(s) allocated from:
#0 0xffff9f218f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac8c68d4b (/usr/sbin/alternatives+0xad4b)
#2 0xaaaac8c66b63 (/usr/sbin/alternatives+0x8b63)
#3 0xffff9f072adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac8c68777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 24 byte(s) in 1 object(s) allocated from:
#0 0xffff9f2ab5ab in realloc (/lib64/libasan.so.4+0xd35ab)
#1 0xaaaac8c66cbb (/usr/sbin/alternatives+0x8cbb)
#2 0xffff9f072adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#3 0xaaaac8c68777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 9 byte(s) in 1 object(s) allocated from:
#0 0xffff9f218f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac8c66e07 (/usr/sbin/alternatives+0x8e07)
#2 0xffff9f072adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#3 0xaaaac8c68777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 6 byte(s) in 1 object(s) allocated from:
#0 0xffff9f218f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac8c68db3 (/usr/sbin/alternatives+0xadb3)
#2 0xaaaac8c66d07 (/usr/sbin/alternatives+0x8d07)
#3 0xffff9f072adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac8c68777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 5 byte(s) in 1 object(s) allocated from:
#0 0xffff9f218f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac8c68db3 (/usr/sbin/alternatives+0xadb3)
#2 0xaaaac8c66b63 (/usr/sbin/alternatives+0x8b63)
#3 0xffff9f072adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac8c68777 (/usr/sbin/alternatives+0xa777)

SUMMARY: AddressSanitizer: 364 byte(s) leaked in 11 allocation(s).
NEW link: link_a Prio: 10 Family: family_a

=================================================================
==8255==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 128 byte(s) in 1 object(s) allocated from:
#0 0xffffa7c035ab in realloc (/lib64/libasan.so.4+0xd35ab)
#1 0xaaaac5949647 (/usr/sbin/alternatives+0x7647)
#2 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#3 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Direct leak of 47 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac5948fcf (/usr/sbin/alternatives+0x6fcf)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Direct leak of 35 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac594c4df (/usr/sbin/alternatives+0xa4df)
#2 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#3 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Direct leak of 35 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac594b59b (/usr/sbin/alternatives+0x959b)
#2 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#3 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0xffffa7c035ab in realloc (/lib64/libasan.so.4+0xd35ab)
#1 0xaaaac594811f (/usr/sbin/alternatives+0x611f)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0xffffa7c031db in __interceptor_malloc (/lib64/libasan.so.4+0xd31db)
#1 0xaaaac594849f (/usr/sbin/alternatives+0x649f)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0xffffa7c031db in __interceptor_malloc (/lib64/libasan.so.4+0xd31db)
#1 0xaaaac59493b7 (/usr/sbin/alternatives+0x73b7)
#2 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#3 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0xffffa7c035ab in realloc (/lib64/libasan.so.4+0xd35ab)
#1 0xaaaac594acbb (/usr/sbin/alternatives+0x8cbb)
#2 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#3 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Direct leak of 13 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59484e7 (/usr/sbin/alternatives+0x64e7)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Direct leak of 1 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59481ef (/usr/sbin/alternatives+0x61ef)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 48 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac594897b (/usr/sbin/alternatives+0x697b)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 48 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac594ce1b (/usr/sbin/alternatives+0xae1b)
#2 0xaaaac594ad07 (/usr/sbin/alternatives+0x8d07)
#3 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 47 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac5948217 (/usr/sbin/alternatives+0x6217)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 47 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac594ce1b (/usr/sbin/alternatives+0xae1b)
#2 0xaaaac594ab63 (/usr/sbin/alternatives+0x8b63)
#3 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 46 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac5948147 (/usr/sbin/alternatives+0x6147)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 46 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac5948b57 (/usr/sbin/alternatives+0x6b57)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 46 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac594cd4b (/usr/sbin/alternatives+0xad4b)
#2 0xaaaac594ad07 (/usr/sbin/alternatives+0x8d07)
#3 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 45 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac5947fb3 (/usr/sbin/alternatives+0x5fb3)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 45 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59483eb (/usr/sbin/alternatives+0x63eb)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 45 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac594cd4b (/usr/sbin/alternatives+0xad4b)
#2 0xaaaac594ab63 (/usr/sbin/alternatives+0x8b63)
#3 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 9 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac594ae07 (/usr/sbin/alternatives+0x8e07)
#2 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#3 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 9 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59486af (/usr/sbin/alternatives+0x66af)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 6 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac594cdb3 (/usr/sbin/alternatives+0xadb3)
#2 0xaaaac594ad07 (/usr/sbin/alternatives+0x8d07)
#3 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 6 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac5948093 (/usr/sbin/alternatives+0x6093)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 6 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac5948abb (/usr/sbin/alternatives+0x6abb)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 5 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac594cdb3 (/usr/sbin/alternatives+0xadb3)
#2 0xaaaac594ab63 (/usr/sbin/alternatives+0x8b63)
#3 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 5 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac5948037 (/usr/sbin/alternatives+0x6037)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 5 byte(s) in 1 object(s) allocated from:
#0 0xffffa7b70f63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac594842b (/usr/sbin/alternatives+0x642b)
#2 0xaaaac594923f (/usr/sbin/alternatives+0x723f)
#3 0xaaaac594c437 (/usr/sbin/alternatives+0xa437)
#4 0xffffa79caadf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#5 0xaaaac594c777 (/usr/sbin/alternatives+0xa777)

SUMMARY: AddressSanitizer: 877 byte(s) leaked in 28 allocation(s).
NEW link: link_b Prio: 20 Family: family_b

=================================================================
==8301==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 128 byte(s) in 1 object(s) allocated from:
#0 0xffffa55f15ab in realloc (/lib64/libasan.so.4+0xd35ab)
#1 0xaaaac59f72d3 (/usr/sbin/alternatives+0x62d3)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Direct leak of 47 byte(s) in 1 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59f7fcf (/usr/sbin/alternatives+0x6fcf)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Direct leak of 35 byte(s) in 1 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59fa59b (/usr/sbin/alternatives+0x959b)
#2 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#3 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Direct leak of 35 byte(s) in 1 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59fb4df (/usr/sbin/alternatives+0xa4df)
#2 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#3 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0xffffa55f15ab in realloc (/lib64/libasan.so.4+0xd35ab)
#1 0xaaaac59f711f (/usr/sbin/alternatives+0x611f)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Direct leak of 26 byte(s) in 2 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59f74e7 (/usr/sbin/alternatives+0x64e7)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Direct leak of 5 byte(s) in 1 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59fbb4b (/usr/sbin/alternatives+0xab4b)
#2 0xaaaac59fa0ef (/usr/sbin/alternatives+0x90ef)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Direct leak of 1 byte(s) in 1 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59f71ef (/usr/sbin/alternatives+0x61ef)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 96 byte(s) in 2 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59f797b (/usr/sbin/alternatives+0x697b)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 92 byte(s) in 2 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59f7b57 (/usr/sbin/alternatives+0x6b57)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 90 byte(s) in 2 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59f73eb (/usr/sbin/alternatives+0x63eb)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 48 byte(s) in 2 object(s) allocated from:
#0 0xffffa55f11db in __interceptor_malloc (/lib64/libasan.so.4+0xd31db)
#1 0xaaaac59f749f (/usr/sbin/alternatives+0x649f)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 47 byte(s) in 1 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59f7bd7 (/usr/sbin/alternatives+0x6bd7)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 47 byte(s) in 1 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59f7217 (/usr/sbin/alternatives+0x6217)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 46 byte(s) in 1 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59f7147 (/usr/sbin/alternatives+0x6147)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 45 byte(s) in 1 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59f6fb3 (/usr/sbin/alternatives+0x5fb3)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 18 byte(s) in 2 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59f76af (/usr/sbin/alternatives+0x66af)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 12 byte(s) in 2 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59f7abb (/usr/sbin/alternatives+0x6abb)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 10 byte(s) in 2 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59f742b (/usr/sbin/alternatives+0x642b)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 6 byte(s) in 1 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59f7093 (/usr/sbin/alternatives+0x6093)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

Indirect leak of 5 byte(s) in 1 object(s) allocated from:
#0 0xffffa555ef63 in strdup (/lib64/libasan.so.4+0x40f63)
#1 0xaaaac59f7037 (/usr/sbin/alternatives+0x6037)
#2 0xaaaac59fa95b (/usr/sbin/alternatives+0x995b)
#3 0xffffa53b8adf in __libc_start_main (/lib64/libc.so.6+0x20adf)
#4 0xaaaac59fb777 (/usr/sbin/alternatives+0xa777)

/usr/sbin/alternatives needs to support more inclusive terminology

Per the IETF's draft-knodel-terminology memo and Inclusive Naming Initiative (of which the Linux Foundation and Red Hat are both members of), please consider deprecating the use of "master/slave" terminology in this program and replacing them with a more inclusive pair like "leader/follower".

Given that there will be some use-cases or scripts out there that will rely on alternatives current behaviour and parameters for years to come, I'm under no illusion that compatibility/legacy shims will be around for years if not a decade or more to come.

[packit] Propose downstream failed for release 1.23

Packit failed on creating pull-requests in dist-git (https://src.fedoraproject.org/rpms/chkconfig.git):

dist-git branch error
f36 See https://dashboard.packit.dev/results/propose-downstream/2422
f37 See https://dashboard.packit.dev/results/propose-downstream/2421
f38 See https://dashboard.packit.dev/results/propose-downstream/2423
rawhide See https://dashboard.packit.dev/results/propose-downstream/2420

You can retrigger the update by adding a comment (/packit propose-downstream) into this issue.

`update-alternatives --install` fails when changing the follower name

Current state with follower name as zabbix-proxy-systemd:

# alternatives --display zabbix-proxy
zabbix-proxy - status is auto.
 link currently points to /usr/sbin/zabbix_proxy_mysql
/usr/sbin/zabbix_proxy_mysql - priority 10
 follower zabbix-proxy-systemd: /usr/lib/systemd/system/zabbix-proxy-mysql.service
Current `best' version is /usr/sbin/zabbix_proxy_mysql.
# ls -l /etc/alternatives/zabb*
lrwxrwxrwx. 1 root root 28 Nov  6 12:42 /etc/alternatives/zabbix-proxy -> /usr/sbin/zabbix_proxy_mysql*
lrwxrwxrwx. 1 root root 50 Jan 12 17:33 /etc/alternatives/zabbix-proxy-systemd -> /usr/lib/systemd/system/zabbix-proxy-mysql.service

Try to change that:

# /usr/sbin/update-alternatives --install /usr/sbin/zabbix_proxy     zabbix-proxy /usr/sbin/zabbix_proxy_mysql 10         --slave /usr/lib/systemd/system/zabbix-proxy.service zabbix-proxy.service             /usr/lib/systemd/system/zabbix-proxy-mysql.service --verbose
reading /var/lib/alternatives/zabbix-proxy

Things are broken:

# ls -l /etc/alternatives/zabbix* /usr/lib/systemd/system/zabbix-proxy.service
ls: cannot access '/usr/lib/systemd/system/zabbix-proxy.service': No such file or directory
lrwxrwxrwx. 1 root root 28 Nov  6 12:42 /etc/alternatives/zabbix-proxy -> /usr/sbin/zabbix_proxy_mysql*
# # alternatives --display zabbix-proxy
zabbix-proxy - status is auto.
 link currently points to /usr/sbin/zabbix_proxy_mysql
/usr/sbin/zabbix_proxy_mysql - priority 10
Current `best' version is /usr/sbin/zabbix_proxy_mysql.

If it is run again, then we are working:

# /usr/sbin/update-alternatives --install /usr/sbin/zabbix_proxy     zabbix-proxy /usr/sbin/zabbix_proxy_mysql 10         --slave /usr/lib/systemd/system/zabbix-proxy.service zabbix-proxy.service             /usr/lib/systemd/system/zabbix-proxy-mysql.service --verbose
reading /var/lib/alternatives/zabbix-proxy
# ls -l /etc/alternatives/zabbix* /usr/lib/systemd/system/zabbix-proxy.service
lrwxrwxrwx. 1 root root 28 Nov  6 12:42 /etc/alternatives/zabbix-proxy -> /usr/sbin/zabbix_proxy_mysql*
lrwxrwxrwx. 1 root root 50 Jan 12 17:38 /etc/alternatives/zabbix-proxy.service -> /usr/lib/systemd/system/zabbix-proxy-mysql.service
lrwxrwxrwx. 1 root root 38 Jan 12 17:38 /usr/lib/systemd/system/zabbix-proxy.service -> /etc/alternatives/zabbix-proxy.service

Do not hardcode systemd dir

In Makefile you are hardcoding systemd dir to $(DEST)/usr/lib/systemd.

Not all distributions install systemd into /usr/lib.

config files for alternatives?

Background: as part of my ongoing quest to make all RPM scriptlets deterministic, I'm looking for ways to make every common tool that runs in %pre or %post config-file driven rather than code-driven.

alternatives is one of these, and it's one of the few things that doesn't have a config file format already in use. So I'm proposing that either:

  1. alternatives grows its own config file format and drop-in directory, or
  2. We write and ship a wrapper that can parse config strings and convert them into invocations of /usr/sbin/alternatives.

So here's an example of a possible simple config file format:

# alternatives config for exim
10 mta              /usr/sbin/sendmail  /usr/sbin/sendmail.exim
+  mta-mailq        /usr/bin/mailq      /usr/bin/mailq.exim
+  mta-runq         /usr/bin/runq       /usr/bin/runq.exim
+  mta-rsmtp        /usr/bin/rsmtp      /usr/bin/rsmtp.exim
+  mta-rmail        /usr/bin/rmail      /usr/bin/rmail.exim
+  mta-pam          /etc/pam.d/smtp     /etc/pam.d/exim
+  mta-newaliases   /usr/bin/newaliases /usr/bin/newaliases.exim
+  mta-sendmail     /usr/lib/sendmail   /usr/lib/sendmail.exim
+  mta-mailqman     /usr/share/man/man1/mailq.1.gz /usr/share/man/man8/exim.8.gz
+s exim
  • Comments start with a # and run to EOL
  • Each config block starts with a "master" line, of the form PRIO NAME LINK PATH
    • PRIO must be an integer, obviously
    • This corresponds to --install LINK NAME PATH PRIO
  • Additional links can be added with lines of the form + NAME LINK PATH
    • These correspond to --slave LINK NAME PATH arguments
  • Optional "service" line is +s SERVICE
    • This corresponds to --initscript SERVICE
    • (could also be +i but these are called "services" now)
  • Optional "family" line is +f FAMILY (not used above)
    • This corresponds to --family FAMILY

Programs/packages that wanted to install alternatives links could ship a config file like, say, /etc/alternatives.conf.d/exim.conf. The system could then do something like

/usr/sbin/alternatives --install-from CONF_FILE

to perform the equivalent of the --install ... commandline, or --remove-from CONF_FILE to perform the equivalent --remove NAME PATH action.

We could accomplish this by writing a separate wrapper program that parses the config data and translates it into equivalent alternatives commandlines, but it seems like this might be something useful to integrate into alternatives itself.

Does this make sense? Any thoughts, questions, or suggestions? I'll be happy to try to get a patch written to accomplish this if you believe this functionality would be useful.

update-alternatives needs verbose invalid message

current message
admindir /var/lib/alternatives invalid
when doing
/usr/sbin/update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7.2.2 300700

Suggest adding : command line arguments here. Example:
admindir /var/lib/alternatives invalid: --install /usr/bin/gcc gcc /usr/bin/gcc-7.2.2 300700

alternatives.8 manual inconsistency for "--list"

There is an inconsistency in the manual page for alternatives. According to the synopsis section, the "--list" option can be followed by a argument. But further on, description of "--list" disagrees, and so does the code; e.g. "alternatives --help".

Add '*' legend to alternatives --config ?

There seems to be no explanation for the '*' symbol in the list output by alternatives --config. Why not add an explanation in the output of the command like

*: 'best' selection based on priority

or if not, at least add an explanation on the man page?

please migrate to the new Fedora translation platform

Hello, the Fedora project migrates its translation platform to Weblate [1].

This tool directly interact with your git repository, and requires us to know:

  • [mandatory] which branch is your development branch?
  • [mandatory] have you merged latest translation from Zanata and locked the project?
  • [info] Weblate will handle updates when pot file changes, don't edit po files for this [2]
  • [optional] what is the license of translation? (please use a code from https://spdx.org/licenses/)
  • [optional] do you have any announcement/warning you would like to display to the translators? (it will be displayed in Weblate)
  • [optional] do you need us to activate any specific checks? (this is a setting per component [3])
  • [optional] do you need us to automatically detect new translation files? (typical usecase: website translation with one translation file per page)

Please note:

  • For github hosted projects, Weblate open pull request. For other project, you'll have to add a key to allow commits.
  • In Weblate's vocable, one project is a group of component. Each component is a translation file. You can have many projects or many components or both.
  • You can change your mind over time, just reach [email protected]

[1] https://communityblog.fedoraproject.org/fedora-localization-platform-migrates-to-weblate/
[2] https://docs.weblate.org/en/latest/admin/continuous.html#avoiding-merge-conflicts
[3] https://docs.weblate.org/en/latest/user/checks.html#translation-checks

Weird behavior when `--add-slave` and `--keep-foreign` used together for active alternative

We have a problem in python3.11-wheel package which we can probably solve by ourselves but I think the strange behavior of alternatives I discovered is still worth reporting.

When talking about packages, I mean the ones available in RHEL 8 and I'm using 1minutetip for testing. The most important ones are chkconfig-1.19.1-1.el8.x86_64 and python3.11-wheel-0.38.4-3.el8.noarch.

To reproduce the problem on RHEL 8:

  1. dnf install python36 python3.11 (Python 3.6 is needed later.)
  2. alternatives --set python3 /usr/bin/python3.11
  3. dnf install python3.11-wheel

The installation of python3.11-wheel calls this command in its %post scriptlet:
alternatives --keep-foreign --add-slave python3 /usr/bin/python3.11 /usr/bin/wheel-3 wheel-3 /usr/bin/wheel-3.11

The command produces the following error:

Running scriptlet: python3.11-wheel-0.38.4-3.el8.noarch                                 1/1 
failed to link /usr/bin/wheel-3 -> /etc/alternatives/wheel-3: /usr/bin/wheel-3 exists and it is either not a symlink or --keep-foreign was set and link points outside /etc/alternatives

But, if you set the alternative for python3 to python36 which means that the installation of python3.11-wheel will add the slave into an inactive alternative, it works fine and no error is shown. So these steps are fine:

  1. dnf install python36 python3.11
  2. alternatives --set python3 /usr/bin/python3.6
  3. dnf install python3.11-wheel

If I understand it correctly --keep-foreign should prevent the --add-slave from removing/changing a symlink, if it already exists. If that's true, having --add-slave together with --keep-foreign makes perfect sense. The problem is that the error message is not true: /usr/bin/wheel-3 does not exist in this case. Alternatives should create that file if you install python3.11-wheel when python3.11 is the active alternative for python3.

To sum this up:

  • If python3.11 is active alternative for python3, the installation of python3.11-wheel does not create /usr/bin/wheel-3 and shows the error mentioned above.
  • If python36 is active alternative for python3, the installation succeedes without errors. Then, when you switch from python36 to python3.11 alternative, the file /usr/bin/wheel-3 is there and works as expected: /usr/bin/wheel-3 -> /etc/alternatives/wheel-3 -> /usr/bin/wheel-3.11.

Bug report with some more context: https://bugzilla.redhat.com/show_bug.cgi?id=2181479

Does it make sense to use --keep-foreign with --add-slave? If so, could we fix the problem? And if not, could we improve the error message to make it clear that this is not supported?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.