What Is The Maximum Allowed Limit on The Length of a Process Name

What is the maximum allowed limit on the length of a process name?

According to man 2 prctl:

PR_SET_NAME (since Linux 2.6.9)

Set the name of the calling thread, using the value in the location pointed to by (char *) arg2. The name can be up to 16 bytes long, and should be null-terminated if it contains fewer bytes.

So I'd go for a 16 bytes long buffer.

---

EDIT:

Let me back this up a little more.

Each process in Linux corresponds to a struct task_struct in the kernel, which is defined in include/linux/sched.h.

In this definition, there's a field char comm[TASK_COMM_LEN], which according to the comment refers to the executable name excluding the path:

    char comm[TASK_COMM_LEN]; /* executable name excluding path
                                 - access with [gs]et_task_comm (which lock
                                   it with task_lock())
                                 - initialized normally by setup_new_exec */

Its size, TASK_COMM_LEN, is defined above in the same header file, here, to be 16 bytes:

/* Task command name length */
#define TASK_COMM_LEN 16

---

Furthermore, quoting LDD3 page 22:

...

the following statement prints the process ID and the command name of the current
process by accessing certain fields in struct task_struct :

printk(KERN_INFO "The process is \"%s\" (pid %i)\n",
        current->comm, current->pid);

The command name stored in current->comm is the base name of the program file
(trimmed to 15 characters if need be) that is being executed by the current process.

Maximum Length of Command Line String

From the Microsoft documentation: Command prompt (Cmd. exe) command-line string limitation

On computers running Microsoft Windows XP or later, the maximum length of the string that you can use at the command prompt is 8191 characters.

Maximum number of globally registered processes

Good question! I'd bet on the number of atoms, if you take into account the following. The Efficiency Guide has a section on system limits:

Processes
The maximum number of simultaneously alive Erlang processes is by default 32768. This limit can be raised up to at most 268435456 processes at startup (see documentation of the system flag +P in the erl(1) documentation). The maximum limit of 268435456 processes will at least on a 32-bit architecture be impossible to reach due to memory shortage.

Distributed nodes
Known nodes
A remote node Y has to be known to node X if there exist any pids, ports, references, or funs (Erlang data types) from Y on X, or if X and Y are connected. The maximum number of remote nodes simultaneously/ever known to a node is limited by the maximum number of atoms available for node names. All data concerning remote nodes, except for the node name atom, are garbage-collected.

Also, the erl manual section describes the flag you can use to alter the number of processes in your node:

+P Number
Sets the maximum number of concurrent processes for this system. Number must be in the range 16..134217727. Default is 32768.

Since you can alter the number of concurrent processes per node, but you cant alter the number of allowed atoms, and the process names are atoms which are copied in replica per node, that should be the total allowed number of globally registered processes.

Hope it helps :)

EDIT: Actually, turns out you can change the number of allowed atoms :)

    Atoms
By default, the maximum number of atoms is 1048576. This limit can be raised or lowered using the +t option.

+t size
Set the maximum number of atoms the VM can handle. Default is 1048576.

What is the maximum length of the -ArgumentList parameter of the Start-Process cmdlet

Combined length of 8191 characters, maybe. Or maybe it depends on the program you're running.

Source: Trial and error (Windows 8.1 / PSv4):

Start-Process -FilePath cmd -ArgumentList (@('/k','echo 1') + (2..1852))
# works

Start-Process -FilePath cmd -ArgumentList (@('/k','echo 1') + (2..1853))
# doesn't work

Around 6769 it triggers an exception:

PS C:\> Start-Process -FilePath cmd -ArgumentList (@('/k','echo 1') + (2..6768))
Start-Process : This command cannot be run due to the error: The filename or extension is too long.
At line:1 char:1
+ Start-Process -FilePath cmd -ArgumentList (@('/k','echo 1') + (2..676 ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

But if I shift the numbers a bit (2..1852|%{$_*100}) then it fails sooner. Suggesting it's not the number of arguments which matters, but the string length of the combined result.

((@('/k','echo 1') + (2..1852)) -join " ").Length
# 8160 when it works, 8165 when it breaks

Google for 8165 limit cmd and get:

Maximum Length of Command Line String

https://support.microsoft.com/en-gb/kb/830473

On computers running Microsoft Windows XP or later, the maximum length of the string that you can use at the command prompt is 8191 characters.

So, either 8191 characters or ... maybe it depends on the program you're calling.

300 * 32 would break that.

But then again, if you've already got a program which can handle it - start-process appears to have no problem with an array of 1,800 items as an argument list.

What is the maximum filename length in Windows 10? Java would try / catch would trough exeption?

If you really mean file name, I believe the limit is still "commonly" 255 characters, see the third quoted paragraph ("The Windows API has many...") below.

If you mean file path: You can enable the "Win32 long paths" option. From this Microsoft document:

Maximum Path Length Limitation

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string<NUL>" where "<NUL>" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)

Note

File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix as detailed in the following sections.

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".

Note

The maximum path of 32,767 characters is approximate, because the "\\?\" prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length.

The "\\?\" prefix can also be used with paths constructed according to the universal naming convention (UNC). To specify such a path using UNC, use the "\\?\UNC\" prefix. For example, "\\?\UNC\server\share", where "server" is the name of the computer and "share" is the name of the shared folder. These prefixes are not used as part of the path itself. They indicate that the path should be passed to the system with minimal modification, which means that you cannot use forward slashes to represent path separators, or a period to represent the current directory, or double dots to represent the parent directory. Because you cannot use the "\\?\" prefix with a relative path, relative paths are always limited to a total of MAX_PATH characters.

There is no need to perform any Unicode normalization on path and file name strings for use by the Windows file I/O API functions because the file system treats path and file names as an opaque sequence of WCHARs. Any normalization that your application requires should be performed with this in mind, external of any calls to related Windows file I/O API functions.

When using an API to create a directory, the specified path cannot be so long that you cannot append an 8.3 file name (that is, the directory name cannot exceed MAX_PATH minus 12).

The shell and the file system have different requirements. It is possible to create a path with the Windows API that the shell user interface is not able to interpret properly.

Enable Long Paths in Windows 10, Version 1607, and Later

Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior.

To enable the new long path behavior, both of the following conditions must be met:

• The registry key HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD) must exist and be set to 1. The key's value will be cached by the system (per process) after the first call to an affected Win32 file or directory function (see below for the list of functions). The registry key will not be reloaded during the lifetime of the process. In order for all apps on the system to recognize the value of the key, a reboot might be required because some processes may have started before the key was set.

Note

This registry key can also be controlled via Group Policy at Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths.

• The application manifest must also include the longPathAware element.

  <application xmlns="urn:schemas-microsoft-com:asm.v3">
      <windowsSettings xmlns:ws2="https://schemas.microsoft.com/SMI/2016/WindowsSettings">
          <ws2:longPathAware>true</ws2:longPathAware>
      </windowsSettings>
  </application>
  

These are the directory management functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior: CreateDirectoryW, CreateDirectoryExW GetCurrentDirectoryW RemoveDirectoryW SetCurrentDirectoryW.

These are the file management functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior: CopyFileW, CopyFile2, CopyFileExW, CreateFileW, CreateFile2, CreateHardLinkW, CreateSymbolicLinkW, DeleteFileW, FindFirstFileW, FindFirstFileExW, FindNextFileW, GetFileAttributesW, GetFileAttributesExW, SetFileAttributesW, GetFullPathNameW, GetLongPathNameW, MoveFileW, MoveFileExW, MoveFileWithProgressW, ReplaceFileW, SearchPathW, FindFirstFileNameW, FindNextFileNameW, FindFirstStreamW, FindNextStreamW, GetCompressedFileSizeW, GetFinalPathNameByHandleW.

Note that while that article says the Group Policy editor's setting is "Enable NTFS long paths", that's no longer the case; it's "Enable Win32 long paths" now:

What is the maximum process Id on Windows?

According to the Pushing the Limits of Windows: Processes and Threads blog post by Mark Russinovich number of processes is limited only by available memory. So theoretically maximum process id is DWORD_MAX aligned to 4: 0xFFFFFFFC (as pid/tid values are aligned to 4 on Windows).

Maximum filename length in NTFS (Windows XP and Windows Vista)?

Individual components of a filename (i.e. each subdirectory along the path, and the final filename) are limited to 255 characters, and the total path length is limited to approximately 32,000 characters.

However, on Windows, you can't exceed MAX_PATH value (259 characters for files, 248 for folders). See http://msdn.microsoft.com/en-us/library/aa365247.aspx for full details.

Using multiprocessing.Process with a maximum number of simultaneous processes

It might be most sensible to use multiprocessing.Pool which produces a pool of worker processes based on the max number of cores available on your system, and then basically feeds tasks in as the cores become available.

The example from the standard docs (http://docs.python.org/2/library/multiprocessing.html#using-a-pool-of-workers) shows that you can also manually set the number of cores:

from multiprocessing import Pool

def f(x):
    return x*x

if __name__ == '__main__':
    pool = Pool(processes=4)              # start 4 worker processes
    result = pool.apply_async(f, [10])    # evaluate "f(10)" asynchronously
    print result.get(timeout=1)           # prints "100" unless your computer is *very* slow
    print pool.map(f, range(10))          # prints "[0, 1, 4,..., 81]"

And it's also handy to know that there is the multiprocessing.cpu_count() method to count the number of cores on a given system, if needed in your code.

Edit: Here's some draft code that seems to work for your specific case:

import multiprocessing

def f(name):
    print 'hello', name

if __name__ == '__main__':
    pool = multiprocessing.Pool() #use all available cores, otherwise specify the number you want as an argument
    for i in xrange(0, 512):
        pool.apply_async(f, args=(i,))
    pool.close()
    pool.join()

Process names over 21 characters not detected/supported by TaskList

BDM's answer shows you how to achieve that tasklist returns also longer process names.

Just let me point out that the filter option /FI (tasklist /FI "ImageName eq process.exe") does accept longer process (or image) names, only the returned text may be truncated.

Anyway, you do not output process names to the console, but you are piping them into find, so the returned text is indeed relevant.

But instead of searching the returned list of processes for the process names again just to detect whether at least one such is running, you could revert the search to capture the tasklist message when no matching processes are encountered by findstr like this:

tasklist /FI "ImageName eq %ProcessName%.exe" | findstr /V /B /C:"INFO: " > nul

This, like your find command, sets ErrorLevel in case no matching process is found.

---

An alternative to tasklist is the wmic command:

wmic Process where "Name='%ProcessName%.exe'" get Name,ProcessID

And together with find:

wmic Process where "Name='%ProcessName%.exe'" get Name,ProcessID 2> nul | find /I ".exe" > nul

Why does the 260 character path length limit exist in Windows?

Quoting this article https://learn.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

Maximum Path Length Limitation

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string<NUL>" where "<NUL>" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)

Now we see that it is 1+2+256+1 or [drive][:\][path][null] = 260. One could assume that 256 is a reasonable fixed string length from the DOS days. And going back to the DOS APIs we realize that the system tracked the current path per drive, and we have 26 (32 with symbols) maximum drives (and current directories).

The INT 0x21 AH=0x47 says “This function returns the path description without the drive letter and the initial backslash.” So we see that the system stores the CWD as a pair (drive, path) and you ask for the path by specifying the drive (1=A, 2=B, …), if you specify a 0 then it assumes the path for the drive returned by INT 0x21 AH=0x15 AL=0x19. So now we know why it is 260 and not 256, because those 4 bytes are not stored in the path string.

Why a 256 byte path string, because 640K is enough RAM.

---

Related Topics