Microsoft MVP성태의 닷넷 이야기
Linux: 6. getenv, setenv가 언어/운영체제마다 호환이 안 되는 문제 [링크 복사], [링크+제목 복사]
조회: 1277
글쓴 사람
홈페이지
첨부 파일
 

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://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-setenvironmentvariable

GetEnvironmentVariable function
; https://docs.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처럼 프로세스 자체의 환경 변수에 접근해 처리하는 방법을 알고 계신 있다면 덧글 부탁드립니다. ^^





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

[연관 글]





[최초 등록일: ]
[최종 수정일: 3/15/2019 ]

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

비밀번호

댓글 쓴 사람
 




1  2  3  4  5  6  7  8  9  10  11  12  13  [14]  15  ...
NoWriterDateCnt.TitleFile(s)
11808정성태2/8/20191605디버깅 기술: 123. windbg - 닷넷 응용 프로그램의 메모리 누수 분석
11807정성태1/29/20191175Windows: 156. 가상 디스크의 용량을 복구 파티션으로 인해 늘리지 못하는 경우 [3]
11806정성태1/29/20191130디버깅 기술: 122. windbg - 덤프 파일로부터 PID와 환경 변수 등의 정보를 구하는 방법
11805정성태1/28/20191792.NET Framework: 806. C# - int []와 object []의 차이로 이해하는 제네릭의 필요성 [2]파일 다운로드1
11804정성태1/24/20191121Windows: 155. diskpart - remove letter 이후 재부팅 시 다시 드라이브 문자가 할당되는 경우
11803정성태1/10/20191394디버깅 기술: 121. windbg - 닷넷 Finalizer 스레드가 멈춰있는 현상
11802정성태1/7/20191505.NET Framework: 805. 두 개의 윈도우를 각각 실행하는 방법(Windows Forms, WPF)파일 다운로드1
11801정성태1/1/20191699개발 환경 구성: 427. Netsh의 네트워크 모니터링 기능 [3]
11800정성태12/28/20181430오류 유형: 509. WCF 호출 오류 메시지 - System.ServiceModel.CommunicationException: Internal Server Error
11799정성태12/19/20182051.NET Framework: 804. WPF(또는 WinForm)에서 UWP UI 구성 요소 사용하는 방법 [3]파일 다운로드1
11798정성태12/19/20181933개발 환경 구성: 426. vcpkg - "Building vcpkg.exe failed. Please ensure you have installed Visual Studio with the Desktop C++ workload and the Windows SDK for Desktop C++"
11797정성태12/19/20181290개발 환경 구성: 425. vcpkg - CMake Error: Problem with archive_write_header(): Can't create '' 빌드 오류
11796정성태12/19/20181221개발 환경 구성: 424. vcpkg - "File does not have expected hash" 오류를 무시하는 방법
11795정성태12/19/20181467Windows: 154. PowerShell - Zone 별로 DNS 레코드 유형 정보 조회 [1]
11794정성태12/17/20181189오류 유형: 508. Get-AzureWebsite : Request to a downlevel service failed.
11793정성태12/16/20181367개발 환경 구성: 423. NuGet 패키지 제작 - Native와 Managed DLL을 분리하는 방법
11792정성태12/11/20181605Graphics: 34. .NET으로 구현하는 OpenGL (11) - Per-Pixel Lighting파일 다운로드1
11791정성태12/11/20181636VS.NET IDE: 130. C/C++ 프로젝트의 시작 프로그램으로 .NET Core EXE를 지정하는 경우 닷넷 디버깅이 안 되는 문제 [1]
11790정성태12/11/20181455오류 유형: 507. Could not save daemon configuration to C:\ProgramData\Docker\config\daemon.json: Access to the path 'C:\ProgramData\Docker\config' is denied.
11789정성태12/10/20182648Windows: 153. C# - USB 장치의 연결 및 해제 알림을 위한 WM_DEVICECHANGE 메시지 처리파일 다운로드1
11788정성태12/4/20181172오류 유형: 506. SqlClient - Value was either too large or too small for an Int32.Couldn't store <2151292191> in ... Column
11787정성태11/29/20182047Graphics: 33. .NET으로 구현하는 OpenGL (9), (10) - OBJ File Format, Loading 3D Models파일 다운로드1
11786정성태11/29/20181239오류 유형: 505. OpenGL.NET 예제 실행 시 "Managed Debugging Assistant 'CallbackOnCollectedDelegate'" 예외 발생
11785정성태12/23/20191890디버깅 기술: 120. windbg 분석 사례 - ODP.NET 사용 시 Finalizer에서 System.AccessViolationException 예외 발생으로 인한 비정상 종료
11784정성태11/18/20181653Graphics: 32. .NET으로 구현하는 OpenGL (7), (8) - Matrices and Uniform Variables, Model, View & Projection Matrices파일 다운로드1
11783정성태11/18/20181585오류 유형: 504. 윈도우 환경에서 docker가 설치된 컴퓨터 간의 ping IP 주소 풀이 오류
1  2  3  4  5  6  7  8  9  10  11  12  13  [14]  15  ...