Microsoft MVP성태의 닷넷 이야기
Linux: 6. getenv, setenv가 언어/운영체제마다 호환이 안 되는 문제 [링크 복사], [링크+제목 복사],
조회: 21555
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 6개 있습니다.)
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

Linux: 66. 리눅스 - 실행 중인 프로세스 내부의 환경변수 설정을 구하는 방법 (gdb)
; https://www.sysnet.pe.kr/2/0/13496

Linux: 80. 리눅스 - 실행 중인 프로세스 내부의 환경변수 설정을 구하는 방법 (lldb)
; https://www.sysnet.pe.kr/2/0/13745

Linux: 81. Linux - PATH 환경변수의 적용 규칙
; https://www.sysnet.pe.kr/2/0/13753

Linux: 104. Linux - COLUMNS 환경변수가 언제나 80으로 설정되는 환경
; https://www.sysnet.pe.kr/2/0/13811




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

비밀번호

댓글 작성자
 




... 181  182  [183]  184  185  186  187  188  189  190  191  192  193  194  195  ...
NoWriterDateCnt.TitleFile(s)
393정성태11/8/200619511오류 유형: 17. Unable to start debugging - The binding handle is invalid.
371정성태10/23/200618653오류 유형: 16. STS Communication failed.
370정성태11/12/200622579.NET Framework: 75. Windows CardSpace 이야기 (이 글의 내용은 재작성되어질 예정입니다.)
375정성태10/25/200624525    답변글 .NET Framework: 75.1. 개인 발행 카드에 대한 Microsoft 예제 실습(이 글의 내용은 재작성되어질 예정입니다.)
376정성태10/27/200624189    답변글 .NET Framework: 75.2. "Windows CardSpace"와 "인증서 서비스"의 만남(이 글의 내용은 재작성되어질 예정입니다.)
377정성태10/26/200623831    답변글 .NET Framework: 75.3. Managed Card 발행에 대한 Microsoft 예제 실습 (1) - CardWriter (이 글의 내용은 재작성되어질 예정입니다.)
385정성태11/6/200626435    답변글 .NET Framework: 75.4. Managed Card 발행에 대한 Microsoft 예제 실습 (2) - STS 구현 (이 글의 내용은 재작성되어질 예정입니다.) [7]
387정성태11/2/200627194    답변글 .NET Framework: 75.5. Windows CardSpace와 SYSNET 사이트의 만남 (이 글의 내용은 재작성되어질 예정입니다.) [1]
397정성태11/11/200624762    답변글 .NET Framework: 75.6. CardWriter.csproj와 함께 알아보는 인증서 식별 방법(이 글의 내용은 재작성되어질 예정입니다.)
398정성태11/12/200623265    답변글 .NET Framework: 75.7. 카드에 암호 거는 방법(이 글의 내용은 재작성되어질 예정입니다.)
399정성태11/12/200625504    답변글 .NET Framework: 75.8. 인증서/스마트 카드에 기반한 Managed Card - STS 구현(이 글의 내용은 재작성되어질 예정입니다.) [5]
369정성태10/22/200620968오류 유형: 15. 자동 업데이트 실패
367정성태10/22/200636757Windows: 3. IIS 7.0 다중 바인딩 설정하는 방법 [1]
365정성태10/21/200620475Windows: 2. 서버(build 5600)에 IIS 7.0 서비스와 .NET 3.0 설치 방법
359정성태10/17/200616652오류 유형: 14. VS.NET 빌드 오류 - FxCopCmd.exe returned error code 65.
358정성태10/17/200621841오류 유형: 13. WSE 3.0 서비스 관련 WSE101 오류 / Destination Unreachable
357정성태12/1/200624091.NET Framework: 74. WCF 이야기 [4]
378정성태10/28/200628861    답변글 .NET Framework: 74.1. WCF와 WSE 3.0의 활용 [4]파일 다운로드1
379정성태11/3/200627805    답변글 .NET Framework: 74.2. WCF로 구현하는 .NET Remoting [4]파일 다운로드1
380정성태10/28/200626705    답변글 .NET Framework: 74.3. 웹 서비스와 닷넷 리모팅으로써의 WCF 구현파일 다운로드1
381정성태10/28/200629151    답변글 .NET Framework: 74.4. WCF 서비스 참조 추가 메뉴 [2]
382정성태10/28/200635214    답변글 .NET Framework: 74.5. WCF 서비스를 IIS에서 호스팅하는 방법파일 다운로드1
383정성태10/28/200629965    답변글 .NET Framework: 74.6. IIS 6.0: 다중 Endpoint 제공파일 다운로드1
384정성태10/28/200626891    답변글 .NET Framework: 74.7. IIS 7.0: 다중 Endpoint 제공
389정성태11/11/200629686    답변글 .NET Framework: 74.8. WCF에 SSL 적용 (1) - Httpcfg.exe 도구를 이용한 SSL 설정
390정성태11/6/200626848    답변글 .NET Framework: 74.9. WCF에 SSL 적용 (2) - 서비스 제작파일 다운로드1
... 181  182  [183]  184  185  186  187  188  189  190  191  192  193  194  195  ...