running ps1 script create temp file in everytime

[nAnderYang]

Cento7 and powershell-6.2.3-1.rhel.7.x86_64

#!/bin/bin/pwsh

function xxx{
  echo xxx
}

xxx

create temp file in /tmp at running this script every time ,filename like CoreFxPipe_PSHost.[machine name].[num]+3.None.{scrptname}.ps1

[iSazonov]

@nAnderYang Can you check and confirm with latest 7.0 build?

[nAnderYang]

@iSazonov os: CentOS Linux release 7.7.1908 (Core)

[iSazonov]

@nAnderYang Sorry, I meant we need to repo with PowerShell 7.0 latest build.

[nAnderYang]

@iSazonov update to github powershell-preview-7.0.0_rc.2-1.rhel.7.x86_64.rpm ,no command of pwsh

[root@test tmp]# rpm -qa|grep powershell
powershell-preview-7.0.0_rc.2-1.rhel.7.x86_64
[root@test tmp]# rpm -qa|grep powershell
-bash: pwsh: command not found
[root@test tmp]# which pwsh
/usr/bin/which: no pwsh in (/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin)

[nAnderYang]

i found command in /opt/microsoft/powershell/7-preview/pwsh . change and running the script,that temp files are still being created.

[iSazonov]

no command of pwsh

It is by design to allow Side-By-Side scenario with stable version (pwsh vs pwsh-preview).

@rjmholt Have you any thoughts why the temp file is created?

[SeeminglyScience]

Isn't that the named pipe used for IPC? e.g. for Enter-PSHostProcess?

[iSazonov]

Question is why it is used.

[SeeminglyScience]

Why what's used? Enter-PSHostProcess? If you just mean why is a file created, that's how named pipes work on unix likes.

$pipe = $null
try {
    $pipe = [IO.Pipes.NamedPipeServerStream]::new('mypipe')
    Get-ChildItem /tmp/CoreFxPipe*
    # Should show one with "mypipe" in the file name
} finally {
    ($pipe)?.Dispose()
}

The named pipe is created for PowerShell process to enable Enter-PSHostProcess.

[iSazonov]

@SeeminglyScience My question is about scenario of the issue. Enter-PSHostProcess is not mentioned and it is not clear is it used or not.

[SeeminglyScience]

It's not created on demand, it's part of start up. The named pipe is there whether you use it or not, otherwise there would be no way for Enter-PSHostProcess to signal the process it's trying to enter that it needs to create the pipe.

[iSazonov]

If the named pipe is created every pwsh startup this is answer to the issue question.

[nAnderYang]

i used the scheduled task service, part of which is to control the working baseline of the windows virtual machine under the host through the pwsh script on the host. but over time, i discovered this problem. there are massive files in the / tmp path. the problem is that the files are generated during startup. why not destroy them when exiting?

[iSazonov]

I'd expect the pipe is disposed. @SeeminglyScience Do you know there it is created?

[SeeminglyScience]

Yeah, it's created in the static ctor for RemoteSessionNamedPipeServer:

https://github.com/PowerShell/PowerShell/blob/70d4a899310f5460700f0be8cba5a2af1d4a0305/src/System.Management.Automation/engine/remoting/common/RemoteSessionNamedPipe.cs#L553-L566

(Follow CreateIPCNamedPipeServerSingleton to see it create an instance of RemoteSessionNamedPIpe and save it to a static prop)

It's implemented using NamedPipeServerStream which has a finalizer so it should be doing the clean up on process exit. That's assuming non-Windows reliably runs finalizers, do you know if that's the case @iSazonov?

[iSazonov]

Perhaps it is the case https://stackoverflow.com/questions/12126598/how-and-when-are-c-sharp-static-members-disposed

Stack Overflow

How and when are c# Static members disposed?

I have a class with extensive static members, some of which keep references to managed and unmanaged objects. For instance, the static constructor is called as soon as the Type is referenced, which

[SeeminglyScience]

Hmm. I know on Windows finalizers are supposed to run when the process is closing, but iirc there is a timeout for the whole finalizer queue. So either that just doesn't happen on non-Windows (or maybe on core at all) or something is blocking the queue.

Either way, even if it does typically work, unless they removed the timeout for processing finalizers; this needs to hook into some process exiting event.

@nAnderYang Does it create (and not remove) a file every time the schedule task runs? And can you provide an example directory listing with file names and sizes? Can you see if it reproduces when running an empty script?

@iSazonov I don't have easy access to a unix machine to test this with, if you do can you verify that this repros by just starting and exiting?

[nAnderYang]

@SeeminglyScience I have currently disabled this feature. However I created a test environment. This problem was reproduced. Version powershell-6.2.3-1.rhel.7.x86_64 the situation is the same

[root@test tmp]# rpm -qa|grep powershell
powershell-preview-7.0.0_rc.2-1.rhel.7.x86_64
[root@test tmp]# rm -rf * /tmp
[root@test tmp]# echo '#!/opt/microsoft/powershell/7-preview/pwsh

function workthread{
  echo hello
}

workthread'>/tmp/test.ps1
[root@test tmp]# chmod 700 /tmp/test.ps1
[root@test tmp]# for i in $(seq 1 10); do /tmp/test.ps1; done
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
[root@test tmp]# ls -lh /tmp
total 4.0K
srwxr-xr-x. 1 root root  0 Jan 19 09:47 CoreFxPipe_PSHost.D5CE6A72.1591.None.test.ps1
srwxr-xr-x. 1 root root  0 Jan 19 09:47 CoreFxPipe_PSHost.D5CE6A72.1615.None.test.ps1
srwxr-xr-x. 1 root root  0 Jan 19 09:47 CoreFxPipe_PSHost.D5CE6A73.1635.None.test.ps1
srwxr-xr-x. 1 root root  0 Jan 19 09:47 CoreFxPipe_PSHost.D5CE6A73.1656.None.test.ps1
srwxr-xr-x. 1 root root  0 Jan 19 09:47 CoreFxPipe_PSHost.D5CE6A74.1676.None.test.ps1
srwxr-xr-x. 1 root root  0 Jan 19 09:47 CoreFxPipe_PSHost.D5CE6A74.1695.None.test.ps1
srwxr-xr-x. 1 root root  0 Jan 19 09:47 CoreFxPipe_PSHost.D5CE6A74.1715.None.test.ps1
srwxr-xr-x. 1 root root  0 Jan 19 09:47 CoreFxPipe_PSHost.D5CE6A75.1734.None.test.ps1
srwxr-xr-x. 1 root root  0 Jan 19 09:47 CoreFxPipe_PSHost.D5CE6A75.1754.None.test.ps1
srwxr-xr-x. 1 root root  0 Jan 19 09:47 CoreFxPipe_PSHost.D5CE6A76.1774.None.test.ps1
-rwx------. 1 root root 92 Jan 19 09:47 test.ps1
[root@test tmp]# 

[iSazonov]

It seems we need explicitly dispose the named pipe.

/cc @PaulHigin What do you think?

[KUTlime]

I can also confir this issue. I've just deleted about 40 000 files created by a job scheduled in cron. Now, I have to implement a cron job to cleanup other cron jobs. 😣 I have this issue on v7.0.0 RC1-RTM, Debian Stretch arm7l with the arm32 package.

[nAnderYang]

@KUTlime the bug was not fixed in v7.0.0 release.

[KUTlime]

@nAnderYang Yes, I can see the status Open and I can see thousands of files in my /tmp folders.

I've just wanted to refresh this topic since the last entry was two months and four releases ago. Is there anybody who is actually doing something with this issue?

[nAnderYang]

i don't know if anyone is following this bug. I will not close the isuse without being fixed.

[PaulHigin]

Windows cleans up all resources when a process exits, including named pipes, but it looks like we can't rely on this for Linux systems. For Windows PowerShell we were using the CLR Appdomain unload event to dispose of the server pipe, but that is not implemented in dotNet core. We can use the ProcessExit event to do this for dotNet. That is not always reliable but i think it is our best bet.

Another idea is to make this named pipe listener opt-in. But this diminishes its usefulness somewhat for debugging.

[MaFreiberger]

Problem still exists

also sylog gets spammed by informational ps-messages

[iSazonov]

@MaFreiberger Please open new issues with repo steps and examples (screenshots)

[eduardcloud]

Problem still exists

also sylog gets spammed by informational ps-messages

From: https://github.com/PowerShell/PowerShell/issues/6324#issuecomment-524233270

• Find out where $PSHOME is. My $PSHOME pointed to /opt/microsoft/powershell/7/. Take note that $PSHOME is a variable in PWSH, not in any other shell.
• Create a file in $PSHOME named powershell.config.json.
• Add the following JSON to the file: { "LogLevel": "error" }

[prosciaisaac]

I am having this issue as well on Linux (RHEL 7) with 7.0.3. Thousands of CoreFxPipe_* files sitting in /tmp, with a new one created every time my cron job runs. Pwsh needs to clean up the pipes on exit, or have a startup option to prevent them from being created in a hosting/production environment. This needs to be fixed.

[rjmholt]

This is fixed in PowerShell 7.1. Please give 7.1.0-rc.1 a try to verify.

[JoeSalmeri]

This is fixed in PowerShell 7.1. Please give 7.1.0-rc.1 a try to verify.

@rjmholt

I am running PS 7.1.0 final on OpenSuse Tumbleweed and I still see these files getting created in /tmp

I cleared out /tmp and then launched pwsh so only my profile ran nothing else.

These files all appeared in /tmp

Mode LastWriteTime Length Name

---

----- 12/30/2020 5:02 PM 0 clr-debug-pipe-2473-40708-in ----- 12/30/2020 5:02 PM 0 clr-debug-pipe-2473-40708-out ----- 12/30/2020 5:02 PM 0 CoreFxPipe_PSHost.D6DEF787.2473.None.pwsh ----- 12/30/2020 5:02 PM 0 dotnet-diagnostic-2473-40708-socket

Is that normal or a bug?

[iSazonov]

I am running PS 7.1.0 final on OpenSuse Tumbleweed and I still see these files getting created in /tmp

@JoeSalmeri They will always be created. A problem is if they are not deleted.

[nAnderYang]

@iSazonov @JoeSalmeri I simple test release version 7.1.0 in centos7.8 2003,the bug has be fixed. But use pwsh in command interface you have found temp files in /tmp. Normal exit pwsh command interface delete the temp files，unusual exit can not delete the temp files.

[nAnderYang]

normal test

[root@test tmp]# pwd
/tmp
[root@test tmp]# ls -la
total 4
drwxrwxrwt.  2 root root    6 Dec 31 16:22 .
dr-xr-xr-x. 21 root root 4096 Dec 31 09:59 ..
[root@test tmp]# echo "dir /tmp;exit"|pwsh
PowerShell 7.1.0
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

PS /tmp> dir /tmp;exit

    Directory: /tmp

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-----          12/31/2020  4:23 PM              0 clr-debug-pipe-22918-2632877-in
-----          12/31/2020  4:23 PM              0 clr-debug-pipe-22918-2632877-out
-----          12/31/2020  4:23 PM              0 CoreFxPipe_PSHost.D6DF4E2F.22918.None.pwsh
-----          12/31/2020  4:23 PM              0 dotnet-diagnostic-22918-2632877-socket
[root@test tmp]# ls -la
total 4
drwxrwxrwt.  2 root root    6 Dec 31 16:23 .
dr-xr-xr-x. 21 root root 4096 Dec 31 09:59 ..
[root@test tmp]#

unusual exit

[root@test tmp]# pwsh
PowerShell 7.1.0
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

PS /tmp> dir /tmp

    Directory: /tmp

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-----          12/31/2020  4:24 PM              0 clr-debug-pipe-23001-2640839-in
-----          12/31/2020  4:24 PM              0 clr-debug-pipe-23001-2640839-out
-----          12/31/2020  4:24 PM              0 CoreFxPipe_PSHost.D6DF4E5F.23001.None.pwsh
-----          12/31/2020  4:24 PM              0 dotnet-diagnostic-23001-2640839-socket

PS /tmp> Killed
[root@test tmp]# ls -lah
total 4.0K
drwxrwxrwt.  3 root root  196 Dec 31 16:24 .
dr-xr-xr-x. 21 root root 4.0K Dec 31 09:59 ..
prwx------   1 root root    0 Dec 31 16:24 clr-debug-pipe-23001-2640839-in
prwx------   1 root root    0 Dec 31 16:24 clr-debug-pipe-23001-2640839-out
srwxr-xr-x   1 root root    0 Dec 31 16:24 CoreFxPipe_PSHost.D6DF4E5F.23001.None.pwsh
drwxrwxrwx   3 root root   17 Dec 31 16:24 .dotnet
srw-------   1 root root    0 Dec 31 16:24 dotnet-diagnostic-23001-2640839-socket
[root@test tmp]# tree -a
[root@spider tmp]# tree -a
.
├── clr-debug-pipe-23001-2640839-in
├── clr-debug-pipe-23001-2640839-out
├── CoreFxPipe_PSHost.D6DF4E5F.23001.None.pwsh
├── .dotnet
│   └── shm
│       └── session21039
│           └── PSReadLineHistoryFile_3120419687
└── dotnet-diagnostic-23001-2640839-socket

note: other terminal run command kill -9 `pidof pwsh`

[JoeSalmeri]

@iSazonov @nAnderYang

I simple test release version 7.1.0 in centos7.8 2003,the bug has be fixed. But use pwsh in command interface you have found temp files in /tmp. Normal exit pwsh command interface delete the temp files，unusual exit can not delete the temp files.

Ok, I did some further testing too and with 7.1.1 it is working, however, there is one situation which I would consider "normal" where they are not removed.

If you close the window by clicking the close button, then the files are not deleted.

I don't normally type exit to end pwsh, I just click on the close button for the window.

Is there any way to have pwsh detect that it is exiting in that case and delete the files?

I did a little research on this and found this

https://social.technet.microsoft.com/Forums/windowsserver/en-US/573c1870-5e31-43a1-a863-3f2ebed418df/how-to-handle-close-event-of-powershell-window-if-user-clicks-on-closex-button?forum=winserverpowershell

Although it is talking about Windows Powershell it seems like it should be possible to deal with the situation and remove the files when the user clicks the close button.

I really feel that pwsh should do this clean on exit otherwise /tmp will have lots of these files piling up.

Joe

How to handle close event of PowerShell window if user clicks on Close('X') button

[iSazonov]

@JoeSalmeri Please see https://github.com/PowerShell/PowerShell/issues/11599#issuecomment-602720389

[K0nne]

Hello,

I am using pwsh 7.1.3 on RHEL7 and the problem still exists. I use pwsh in a monitoring usecase and I am using it to execute remote connections against some windows hosts on a 24/7 base. The /tmp filesystem is filled up with pwsh artefacts quickly.

For now I am running the following cron job to clean up but it leaves no good feeling in a productive environment.

/usr/bin/find /tmp -cmin +10 -regextype posix-egrep -regex '.*([a-f0-9-]{36}|CoreFxPipe_PSHost.*)' | xargs rm -rf >/dev/null 2>&1

[eduardcloud]

Hello, this problems still exists with 7.1.4 and is a very important performance issue. On the other hand if you try to reboot an Ubuntu with no tmp cleaning will die in the try also we can talk about the inodes consumption...

Please any forecast for this?

[Zimeon-]

Noticed the same with Powerhell 7.1.4 and Centos7. Use powershell for monitoring and it generates a lot of them, fast.

[PaulHigin]

WG-Remoting Re-opening issue since it appears the fix isn't working on all platforms. One thing we can consider is making the named pipe listener opt-in. That way most powershell instances will not create the named pipe files.

[iSazonov]

@PaulHigin Makes sense to open issue in .Net Runtime repository?

[yusufozturk]

This is still happening for us, for PowerShell 7.2.3 on Ubuntu 20.04.

Are we really having this issue due to telemetry or diagnostic reasons?

If it's really a telemetry issue, I would like to understand the logic behind making Telemetry and Diagnostic ENABLED by default. I wonder who really uses them. How many developers actually ever needed them? I always think "Telemetry" or "Diagnostic" is something you enable when you think something is wrong.

I understand that some reason you would like to keep telemetry ENABLED for everybody. But then you should be able to fix these issues earlier than 2 years. I disabled them with opt-out, but it's still causing lots of directories. I see that many people have the similar issue, so it means that something is wrong here.

Maybe nobody uses PowerShell + .NET on Linux production machines and nobody cares. But we do. We trusted Microsoft, we migrated to Linux due to Linux support and we have these issues for a long time already.

This might be not related with PowerShell, maybe a pure .NET issue. But we use PowerShell. So if there is a bug with .NET, I assume PowerShell team should open the issue.

I will give it a try with PowerShell 7.3.0-preview.5. I hope newest beta version works. Fingers crossed.

[PaulHigin]

@PowerShell/powershell-committee

We make a best effort to clean up listener named pipes on process exit, but it is not foolproof depending on how the process is exited. Windows cleans up all resources on process exit, including named pipes so we don't have the problem there. However, Linux apparently does not clean up these resources.

The listener allows one local PowerShell process to connect and debug another PowerShell process. This is very convenient but is not needed all of the time, and on Linux machines ends up leaving named pipe files if the process is exited abruptly.

I feel the best option is to make the pipeline listener opt-out through an optional command line switch (-NoListener), and maybe a cmdlet to stop the listener if PowerShell is being hosted.

/cc @SteveL-MSFT who first suggested making this opt-out.

[yusufozturk]

Actually we were having a similar problem on Windows as well. We converted our PowerShell services to Golang apps to avoid these issues, sadly. Here is the issue about that:

https://github.com/PowerShell/PowerShell/issues/13198

So Windows was also not cleaning the temp files. It was eventually making production server unstable and crashing the apps. Then customer calls us and says our agent crashes their production servers. Even one time, due to thousand of these files on hundreds of servers, we were accused to make huge IO and bring their virtualmachine storage down.

I strongly belive that these files should be created on request. We never need these files but they are keep generated and causes lots of troubles on the large customers. And simply we can not do a cleanup in their /tmp folder because we are afraid to remove a file which is necessary for Linux by mistake.

Thank you for your understanding.

[daxian-dbw]

and maybe a cmdlet to stop the listener if PowerShell is being hosted.

Would it be possible to have it configured by a property in InitialSessionState? So that the -NoListener flag for pwsh can be translated to setting that property, and when hosting PowerShell, one can set the property to not start the listener thread when opening the Runspace.

[PaulHigin]

The listener is per process and not per runspace, so I didn't think it made sense to include it in InitialSessionState. Disabling the listener should probably just be an API for the hosted scenario.

[iSazonov]

The listener allows one local PowerShell process to connect and debug another PowerShell process. This is very convenient but is not needed all of the time, and on Linux machines ends up leaving named pipe files if the process is exited abruptly.

If it is for debug it is not clear why this should be opt-out but not out-in.

[daxian-dbw]

The listener is per process and not per runspace, so I didn't think it made sense to include it in InitialSessionState.

How about naming the property in InitialSessionState to be CreateDebugListenerIfNotYet (or something like that)? Then it's clear that it will create the listener only if it doesn't yet exist for the process.

[daxian-dbw]

If it is for debug it is not clear why this should be opt-out but not out-in.

@iSazonov That will be a breaking change.

[PaulHigin]

Again, I feel the listener state should not be part of InitialSessionState since it has nothing to do with runspace sessions. A public API is sufficient for opting out of the listener for hosted scenarios. I feel we want opt-out rather than opt-in since opt-in makes it less useful for debugging. It would be difficult or impossible to debug cases where starting the session to be debugged is not controllable.

[iSazonov]

If it is for debug it is not clear why this should be opt-out but not out-in.

@iSazonov That will be a breaking change.

Breaking what? Debug scenario is rare but today mainstream scenario is broken - why cannot we accept the breaking change?