Microsoft MVP성태의 닷넷 이야기
Linux: 6. getenv, setenv가 언어/운영체제마다 호환이 안 되는 문제 [링크 복사], [링크+제목 복사],
조회: 13270
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 2개 있습니다.)
Linux: 6. getenv, setenv가 언어/운영체제마다 호환이 안 되는 문제
; https://www.sysnet.pe.kr/2/0/11846

Linux: 11. 리눅스의 환경 변수 관련 함수 정리 - putenv, setenv, unsetenv
; https://www.sysnet.pe.kr/2/0/11915




getenv, setenv가 언어/운영체제마다 호환이 안 되는 문제

C/C++ 프로그램을 만드는 경우 기본적으로 CRT(윈도우의 경우 msvcr, 리눅스의 경우 libc) 라이브러리에 링크하게 됩니다. 그리고 getenv, setenv는 그 CRT 라이브러리에서 제공하는 함수입니다. 문제의 원인은, CRT 라이브러리에 구현된 환경 변수의 처리가 프로세스(EXE, out)의 환경 변수를 직접 다루는 방식이 아니라는 점입니다.

CRT는 처음 초기화 시점에 프로세스의 환경 변수 문자열을 가져와 cache한 다음 이후의 getenv, setenv는 그 영역을 대상으로 처리를 하는 방식입니다. 아래는 이것 때문에 문제가 된 사례의 하나입니다.

When what you set is not what you get : SetEnvironmentVariable and getenv
; https://blogs.msmvps.com/senthil/2009/10/13/when-what-you-set-is-not-what-you-get-setenvironmentvariable-and-getenv/

단적인 예로, 윈도우의 경우 Visual C++가 CRT에 대한 정적 링크를 제공하므로 2개의 DLL을 만들어 CRT를 정적 링크를 하게 되면 DLL마다 각자의 CRT 환경 변수 메모리 영역이 할당되므로 각자 별도의 getenv, setenv가 동작하게 돼서 서로 환경 변수를 공유할 수 없게 됩니다. 게다가 동적 링크를 한다고 해도, 각각의 DLL이 다른 버전의 CRT와 링크를 하게 되면 그것들 간에도 역시 환경 변수 공유가 안 됩니다.

당연한 이야기지만, 이렇게 CRT의 setenv로 환경 변수를 다루는 것은 "Process Explorer"에서 제공하는 환경 변수 탭에서는 확인할 수 없습니다.




CRT가 이렇게, 프로세스가 아닌 독자적인 환경 변수를 가져가는 것은 사실 윈도우 환경에서는 크게 문제가 되지 않습니다. 왜냐하면 윈도우의 경우 프로세스 환경 변수 영역을 직접 다룰 수 있게 해주는 Win32 API를 제공하기 때문에,

SetEnvironmentVariable function
; https://learn.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-setenvironmentvariable

GetEnvironmentVariable function
; https://learn.microsoft.com/ko-kr/windows/desktop/api/winbase/nf-winbase-getenvironmentvariable

대개의 윈도우 프로그램들이 이를 이용하므로 환경 변수의 불일치로 인한 문제가 거의 없습니다. 물론 위에서 언급했지만 CRT의 getenv, setenv를 사용하면 윈도우에서도 문제가 됩니다.




반면 리눅스는 이것을 좀 특이하게 해결(?)합니다. 리눅스의 C/C++ 응용 프로그램은 윈도우처럼 프로세스의 환경 변수 영역을 대상으로 하는 API를 제공하지 않습니다. 따라서 무조건 libc의 getenv, setenv를 가져다 쓰게 되는데 리눅스의 libc 역시 런타임이 초기화되는 시점에 프로세스의 환경 변수를 복사하는 방식으로 동작합니다. 이로 인해, 일단 응용 프로그램이 실행되면 해당 프로세스에서 setenv로 변경한 환경 변수를 확인할 방법이 없습니다. 즉, cat /proc/...pid.../environ으로는,

Show the environment variables of a running process in Linux
; https://ma.ttias.be/show-the-environment-variables-of-a-running-process-in-linux/

libc의 setenv로 변경된 환경 변수가 안 나옵니다. (Win32 API를 사용한 윈도우에서는 Process Explorer로 확인할 수 있다는 점과 대조됩니다.)

재미있는 것은 지난번에도 언급했지만,

Linux 응용 프로그램의 (C++) so 의존성 줄이기(ReleaseMinDependency)
; https://www.sysnet.pe.kr/2/0/11845

일반적인 공유 라이브러리 유형의 리눅스 응용 프로그램은 libc를 정적 링크하는 것이 허용되지 않습니다. 덕분에 공통적인 libc 공유 라이브러리의 환경 변수 영역을 대상으로 getenv, setenv를 연산하므로 환경 변수 불일치 문제가 그나마 완화됩니다.

그런데, 리눅스의 그런 특성으로 잠재적인 문제가 있습니다. 말인즉, 모든 라이브러리들이 libc에 대한 공유 링킹을 해야 환경 변수 처리에 일관성이 있다는 것입니다. 예를 들어, 어셈블리 언어로 libc에 대한 의존성을 갖지 않는 프로그램을 만든다면 환경 변수는 따로 놀 수밖에 없습니다. 이와 유사하게 언어 간에 환경 변수가 따로 노는 문제가 있습니다. 예를 들어, .NET Core 런타임에서 Environment.SetEnvironmentVariable로 설정한 환경 변수를 DllImport로 가져온 C/C++ so 공유 라이브러리 측에서 getenv로 조회할 수 없습니다. 즉, .NET Core 런타임의 경우 libc에 대한 의존성 없이 /proc/...pid.../environ 환경 변수 값을 독자적으로 가져와 처리하고 있는 듯합니다.

이와 마찬가지로 python과 C/C++ 모듈 간의 환경 변수 처리에도 문제가 있습니다. 예를 들어 다음과 같은 shared1.so C/C++ 공유 라이브러리를,

#include <cstdio>
#include <stdlib.h>
#include "dllmain.h"

void test_set_env()
{
    {
        char* chValue = getenv("TEST");
        if (chValue == nullptr)
        {
            printf("[C/C++] TEST=(null)\n");
        }
        else
        {
            printf("[C/C++] TEST=%s\n", chValue);
        }
    }

    {
        setenv("TEST", "2", 1);
        char* chValue = getenv("TEST");
        printf("[C/C++] TEST=%s\n", chValue);
    }
}

다음과 같은 파이썬 코드에서 가져다 쓰면,

import os
import ctypes
import sys

os.environ['TEST'] = '1'
print(os.environ['TEST'])

fun = ctypes.CDLL('/home/usr32/projects/shared1/bin/x64/Debug/libshared1.so')
fun.test_set_env();

print(os.environ.get('TEST'))

os.environ['TEST'] = '3'
fun.test_set_env();

print(os.environ.get('TEST'))

이렇게 동작하는 것을 확인할 수 있습니다.

$ python test.py
1
[C/C++] TEST=1
[C/C++] TEST=2
1                 // C/C++ 측에서 setenv로 TEST=2를 설정했지만 python에서는 1로 반환
[C/C++] TEST=3
[C/C++] TEST=2
3                 

위의 동작을 정리해 보면, python의 경우 C/C++의 환경 변수 변화를 적용하지만 C/C++ 측에서는 python의 환경 변수 처리를 전혀 알지 못합니다. (참고로, 윈도우용 python에서는 os.environ은 내부적으로 Win32 API를 사용하므로 C/C++ 측에서도 Win32 API를 사용하면 환경 변수 공유가 됩니다.)




그렇다면 리눅스의 경우 /proc/...pid.../environ 파일을 대상으로 직접 환경 변수를 문자열 연산해서 set/get하면 되지 않을까요?...라고 생각했었습니다. ^^ 하지만 실제로 해당 프로세스의 정보를 보면,

$ ls /proc/19248/environ -l
-r-------- 1 root root 0  3월 15 09:42 /proc/19248/environ

read 권한만 있으며 설령 이것의 권한을 변경하려고 해도,

$ sudo chmod 755 /proc/21060/environ
chmod: '/proc/21060/environ'의 권한 설정 중: 명령을 허용하지 않음

라고 오류가 떨어집니다. 혹시, 리눅스에서 윈도우의 SetEnvironmentVariable/GetEnvironmentVariable처럼 프로세스 자체의 환경 변수에 접근해 처리하는 방법을 알고 계신 있다면 덧글 부탁드립니다. ^^





[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 12/21/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 31  32  33  34  35  36  [37]  38  39  40  41  42  43  44  45  ...
NoWriterDateCnt.TitleFile(s)
12705정성태7/13/20218874VS.NET IDE: 168. x64 DLL 프로젝트의 컨트롤이 Visual Studio의 Designer에서 보이지 않는 문제 - 두 번째 이야기
12704정성태7/12/20218005개발 환경 구성: 576. Azure VM의 서비스를 Azure Web App Service에서만 접근하도록 NSG 설정을 제한하는 방법
12703정성태7/11/202113638개발 환경 구성: 575. Azure VM에 (ICMP) ping을 허용하는 방법
12702정성태7/11/20218801오류 유형: 733. TaskScheduler에 등록된 wacs.exe의 Let's Encrypt 인증서 업데이트 문제
12701정성태7/9/20218424.NET Framework: 1075. C# - ThreadPool의 스레드는 반환 시 ThreadStatic과 AsyncLocal 값이 초기화 될까요?파일 다운로드1
12700정성태7/8/20218841.NET Framework: 1074. RuntimeType의 메모리 누수? [1]
12699정성태7/8/20217640VS.NET IDE: 167. Visual Studio 디버깅 중 GC Heap 상태를 보여주는 "Show Diagnostic Tools" 메뉴 사용법
12698정성태7/7/202111607오류 유형: 732. Windows 11 업데이트 시 3% 또는 0%에서 다운로드가 멈춘 경우
12697정성태7/7/20217502개발 환경 구성: 574. Windows 11 (Insider Preview) 설치하는 방법
12696정성태7/6/20218057VC++: 146. 운영체제의 스레드 문맥 교환(Context Switch)을 유사하게 구현하는 방법파일 다운로드2
12695정성태7/3/20218116VC++: 145. C 언어의 setjmp/longjmp 기능을 Thread Context를 이용해 유사하게 구현하는 방법파일 다운로드1
12694정성태7/2/202110027Java: 24. Azure - Spring Boot 앱을 Java SE(Embedded Web Server)로 호스팅 시 로그 파일 남기는 방법 [1]
12693정성태6/30/20217780오류 유형: 731. Azure Web App Site Extension - Failed to install web app extension [...]. {1}
12692정성태6/30/20217681디버깅 기술: 180. Azure - Web App의 비정상 종료 시 남겨지는 로그 확인
12691정성태6/30/20218527개발 환경 구성: 573. 테스트 용도이지만 테스트에 적합하지 않은 Azure D1 공유(shared) 요금제
12690정성태6/28/20219337Java: 23. Azure - 자바(Java)로 만드는 Web App Service - Tomcat 호스팅
12689정성태6/25/20219856오류 유형: 730. Windows Forms 디자이너 - The class Form1 can be designed, but is not the first class in the file. [1]
12688정성태6/24/20219568.NET Framework: 1073. C# - JSON 역/직렬화 시 리플렉션 손실을 없애는 JsonSrcGen [2]파일 다운로드1
12687정성태6/22/20217569오류 유형: 729. Invalid data: Invalid artifact, java se app service only supports .jar artifact
12686정성태6/21/202110008Java: 22. Azure - 자바(Java)로 만드는 Web App Service - Java SE (Embedded Web Server) 호스팅
12685정성태6/21/202110221Java: 21. Azure Web App Service에 배포된 Java 프로세스의 메모리 및 힙(Heap) 덤프 뜨는 방법
12684정성태6/19/20218676오류 유형: 728. Visual Studio 2022부터 DTE.get_Properties 속성 접근 시 System.MissingMethodException 예외 발생
12683정성태6/18/202110190VS.NET IDE: 166. Visual Studio 2022 - Windows Forms 프로젝트의 x86 DLL 컨트롤이 Designer에서 오류가 발생하는 문제 [1]파일 다운로드1
12682정성태6/18/20217849VS.NET IDE: 165. Visual Studio 2022를 위한 Extension 마이그레이션
12681정성태6/18/20217209오류 유형: 727. .NET 2.0 ~ 3.5 + x64 환경에서 System.EnterpriseServices 참조 시 CS8012 경고
12680정성태6/18/20218289오류 유형: 726. python2.7.exe 실행 시 0xc000007b 오류
... 31  32  33  34  35  36  [37]  38  39  40  41  42  43  44  45  ...