она не показывает день и время когда была введена команда
export HISTTIMEFORMAT='%F %T ' в ~/.bashrc
Почему бы сразу не блокировать поток вызовом read и не ждать пока данные будут доступны
(в голову приходит только один вариант, когда необходимо принудительно прихлопнуть поток и если использовать таймаут, то не требуется прерывать системный вызов, хотя если принудительно завершить поток, то ядро по идее само прервет системный вызов)
В момент, когда функция read блокирована (по факту системный вызов (syscall) не вернул результат в пользовательское пространство), то при вызове другого системного вызова того же драйвера, например, write, необходимо ли в самом драйвере синхронизировать общие данные, которые используются и в read и в write?
Или выполнение системных вызовов как-то гарантировано регламентировано и прерывания отключены
rw init=/bin/sh, выполнение в появившейся оболочке команды passwd с желаемыми параметрами (например, passwd -d root) и продолжение загрузки командой exec /sbin/init.
При компиляции, библиотека находится, при запуске объекта, библиотека не находится, в чём может быть причина?
понял, что проблема возникает при вызове open()
Normally, opening the FIFO blocks until the other end is opened also.При установке на CentOS 8, ядро 5.13.13 возникает следующая ошибка:
/usr/src/dahdi-linux-complete-3.1.0+3.1.0/linux/drivers/dahdi/opvxa24xx/callerid.c:1235:40: ошибка: в передаче аргумента 4 «proc_create_data»: несовместимый тип указателя [-Werror=incompatible-pointer-types] proc_create_data(name, 0444, base, &proc_param_fops, data); ^~~~~~~~~~~~~~~~ /usr/src/dahdi-linux-complete-3.1.0+3.1.0/linux/drivers/dahdi/opvxa24xx/callerid.c:1321:40: ошибка: в передаче аргумента 4 «proc_create_data»: несовместимый тип указателя [-Werror=incompatible-pointer-types] proc_create_data(name, 0644, base, &proc_param_off_fops, data); ^~~~~~~~~~~~~~~~~~~~
undefined reference to `boost::python::exec(char const*, boost::python::api::object, boost::python::api::object)'
$ c++filt
_ZN5boost6python4execENS0_3strENS0_3api6objectES3_
boost::python::exec(boost::python::str, boost::python::api::object, boost::python::api::object)boost::python::str из с-строчки.
Почему ядро паникует
$ echo 'Code: 0f 7f 44 17 f0 f3 0f 7f 07 c3 48 83 fa 40 77 16 f3 0f 7f 07 f3 0f 7f 47 10 f3 0f 7f 44 17 f0 f3 0f 7f 44 17 e0 c3 48 8d 4f 40 <f3> 0f 7f 07 48 83 e1 c0 f3 0f 7f 44 17 f0 f3 0f 7f 47 10 f3 0f 7f' | scripts/decodecode
Code: 0f 7f 44 17 f0 f3 0f 7f 07 c3 48 83 fa 40 77 16 f3 0f 7f 07 f3 0f 7f 47 10 f3 0f 7f 44 17 f0 f3 0f 7f 44 17 e0 c3 48 8d 4f 40 <f3> 0f 7f 07 48 83 e1 c0 f3 0f 7f 44 17 f0 f3 0f 7f 47 10 f3 0f 7f
All code
========
0: 0f 7f 44 17 f0 movq %mm0,-0x10(%rdi,%rdx,1)
5: f3 0f 7f 07 movdqu %xmm0,(%rdi)
9: c3 retq
a: 48 83 fa 40 cmp $0x40,%rdx
e: 77 16 ja 0x26
10: f3 0f 7f 07 movdqu %xmm0,(%rdi)
14: f3 0f 7f 47 10 movdqu %xmm0,0x10(%rdi)
19: f3 0f 7f 44 17 f0 movdqu %xmm0,-0x10(%rdi,%rdx,1)
1f: f3 0f 7f 44 17 e0 movdqu %xmm0,-0x20(%rdi,%rdx,1)
25: c3 retq
26: 48 8d 4f 40 lea 0x40(%rdi),%rcx
2a:* f3 0f 7f 07 movdqu %xmm0,(%rdi) <-- trapping instruction
2e: 48 83 e1 c0 and $0xffffffffffffffc0,%rcx
32: f3 0f 7f 44 17 f0 movdqu %xmm0,-0x10(%rdi,%rdx,1)
38: f3 0f 7f 47 10 movdqu %xmm0,0x10(%rdi)
3d: f3 repz
3e: 0f .byte 0xf
3f: 7f .byte 0x7f
Code starting with the faulting instruction
===========================================
0: f3 0f 7f 07 movdqu %xmm0,(%rdi)
4: 48 83 e1 c0 and $0xffffffffffffffc0,%rcx
8: f3 0f 7f 44 17 f0 movdqu %xmm0,-0x10(%rdi,%rdx,1)
e: f3 0f 7f 47 10 movdqu %xmm0,0x10(%rdi)
13: f3 repz
14: 0f .byte 0xf
15: 7f .byte 0x7fLinux как-то закрывает сам программы (и завершает работу ОС) "правильно" перед тем, как полностью выключиться?
выводится ошибка dlopen failed library libc.so.6 not found. Как исправить данную ошибку?
Однако я не могу получить доступ к любой из инициированных скриптом переменных в текущем процессе. Как я понимаю, это происходит потому, что скрипт выполняется отдельным процессом, а возможности экспортировать переменную на уровень выше нет.
Что нужно изменить в системе что-бы добиться такого поведения?
Или процесс создания linux headers настолько специфичен?
Bash Script работает некорректно, почему?
#!/bin/sh
В чем может быть проблема?
#!/bin/bash. Твой скрипт хочет чтобы его выполнял /bin/sh, а он не обязан быть башем.
static struct file_operations process_sched_add_module_fops = { … proc_create(PROC_CONFIG_FILE_NAME,0777,NULL,&process_sched_add_module_fops);
proc_ops, а не на file_operations. Компилятор должен был бы что-нибудь сказать в этом месте, ты не читаешь его предупреждения?static ssize_t process_sched_add_module_write(struct file *file, const char *buf, size_t count, loff_t *ppos)
__user у параметра buf. Этот буфер приходит из юзерспейса, по этой причине ты не можешь лезть в него напрямую функцией kstrtol.