Linux POS machine maintenance method and system and electronic equipment

Abstract

The invention relates to a Linux POS machine maintenance method, which is applied to a POS machine equipment end, and comprises the following steps: a monitoring step: running background service, and continuously monitoring input data of code scanning equipment connected with the POS machine equipment end; an identification step: identifying a task trigger instruction according with a preset format from the input data, wherein the task trigger instruction comprises an acquisition path of a remote task packet; an obtaining step: in response to the identified task triggering instruction, obtaining a remote task package according to the obtaining path; and an execution step: analyzing and executing the script in the remote task package so as to complete the maintenance operation of the POS machine equipment end.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to a Linux POS machine maintenance method, system, and electronic device. Background Art With the development of information technology in the retail industry, POS (Point of Sale) machines have become indispensable equipment. Currently, the operating systems used by POS machines mainly include Windows, Android, and various Linux distributions. Among them, Linux has gained widespread application due to its advantages of being open-source, flexible, stable, and low-cost. However, Linux also has characteristics such as numerous distributions, rapid iteration speed, and significant differences in software ecosystems, which pose a significant challenge to the unified remote maintenance of POS devices in the later stages.

[0002] Existing remote maintenance solutions mostly employ a network-based client-server architecture. For example, by deploying a client program on the POS terminal and establishing a real-time network communication connection with the backend server, the server directly sends encoded monitoring or management commands to the terminal, which then parses and executes them. While this type of solution enables remote control, it has the following inherent drawbacks: First, existing POS machine maintenance methods heavily rely on a continuous and stable network connection for the POS terminal, and cannot function in environments with poor or no network conditions. Second, a complex, persistent communication client needs to be developed and maintained on the POS terminal. This client program needs to be adapted and compiled for different CPU architectures and Linux distributions, resulting in high maintenance costs and poor compatibility in fragmented Linux environments. Finally, existing POS machine maintenance methods cannot fully utilize the hardware interaction methods that are already present at the POS terminal and are very familiar to users.

[0003] Therefore, there is an urgent need to develop a Linux POS machine maintenance method, system, and electronic equipment to overcome the above-mentioned defects. Summary of the Invention

[0004] This invention provides a Linux POS machine maintenance method, system, and electronic device to at least solve the problems of excessive reliance on stable network connections, poor compatibility across different Linux distributions, and high maintenance costs in existing POS machine maintenance methods.

[0005] To achieve the above objectives, in the first aspect, this application provides a Linux POS machine maintenance method, applied to the POS machine device, comprising the following steps: Monitoring steps: Run a background service to continuously monitor the input data of the scanning device connected to the POS machine. Identification step: Identify a task trigger instruction that conforms to a preset format from the input data, wherein the task trigger instruction contains the acquisition path of the remote task package; Acquisition Steps: In response to recognizing the task trigger command, acquire the remote task package according to the acquisition path; Execution steps: Parse and execute the script in the remote task package to complete the maintenance operation on the POS machine device.

[0006] Furthermore, it also includes a device positioning step, including: The scanning device is bound to the supplier's identifier and product identifier; or... The device connected to a specific physical USB interface on the POS machine is designated as the scanning device.

[0007] Furthermore, it also includes equipment status monitoring steps: Monitor the connection status of the scanning device; When the reconnection of the scanning device is detected, the scanning device binding information of the background service is updated.

[0008] Furthermore, the monitoring step includes: Set a fixed-size input buffer; store the input data of the barcode scanner into the input buffer; When a newline character is detected, the data in the input buffer is extracted, and the recognition step is triggered. After the recognition step is completed, the input buffer is cleared.

[0009] Furthermore, the identification step specifically includes: The input buffer data is matched and judged. If the input buffer data contains a predefined trigger command string, the task trigger instruction is identified and the string following it is used as the acquisition path of the remote task package.

[0010] Furthermore, the acquisition step includes: Parse the task trigger command to extract the acquisition path; Based on the acquisition path, download the corresponding remote task package from the remote file server.

[0011] Further, the execution steps include: Decompress the remote task package; The script parser on the POS machine is invoked to sequentially execute the predefined script files within the remote task package.

[0012] Furthermore, the script parser is a Shell parser.

[0013] In a second aspect, the present invention provides a Linux POS machine maintenance system for implementing the Linux POS machine maintenance method as described in the first aspect, comprising: The monitoring module is used to run background services and continuously monitor the input data of the scanning device connected to the POS machine. The identification module is used to identify task triggering instructions that conform to a preset format from the input data, wherein the task triggering instructions include the acquisition path of the remote task package; The acquisition module is used to acquire a remote task package according to the acquisition path in response to the identified task triggering instruction; The execution module is used to parse and execute the scripts in the remote task package to complete the maintenance operations on the POS machine device.

[0014] In a third aspect, the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program, implements the Linux POS machine maintenance method as described in the first aspect.

[0015] Compared with the prior art, the advantages and positive effects of the present invention are as follows: This invention triggers tasks by continuously monitoring the input from the scanning device via a local backend service on the POS terminal, replacing the traditional command push mode that requires a remote server to actively initiate a network connection. This eliminates the dependence of maintenance command input on the real-time online status of the POS terminal, requiring only a network connection when downloading task packages, thus significantly enhancing maintenance capabilities in environments with poor network conditions or intermittent connectivity.

[0016] This invention leverages Linux features, acquiring input by monitoring standard device files, and relies on interpreted languages ​​such as Shell or Python, which are natively supported or easily deployed in almost all Linux distributions, to execute specific tasks. This avoids the tedious work of compiling and adapting dedicated client programs for different system architectures and distributions, enabling the same maintenance logic to run seamlessly in diverse Linux environments. It fundamentally solves the compatibility problems caused by system fragmentation and greatly simplifies the deployment and maintenance of the solution itself.

[0017] This invention simplifies complex system maintenance operations into familiar scanning device trigger actions. Maintenance personnel do not need specialized Linux knowledge to complete the operations. For service providers, they only need to centrally maintain a common script task package and corresponding trigger commands to cover all terminal devices, avoiding differentiated support work for different hardware or system versions. This effectively reduces the need for on-site technical support and achieves high-efficiency, low-cost, large-scale remote maintenance.

[0018] As can be seen from the above technical solutions, additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0019] Figure 1 This is a flowchart of a server-side task generation and publishing method according to an embodiment of this application; Figure 2 This is a schematic diagram of the first process of a Linux POS machine maintenance method according to an embodiment of this application; Figure 3 This is a schematic diagram of the second process of the Linux POS machine maintenance method according to the embodiments of this application; Figure 4 This is a schematic diagram of the monitoring steps according to the embodiments of this application; Figure 5 This is a schematic diagram of the Linux POS machine maintenance system structure according to an embodiment of this application; Figure 6 This is a schematic diagram of a computer device according to an embodiment of this application.

[0020] In the above figures: 100. Listening module; 200. Identification module; 300. Acquisition module; 400. Execution module.

[0021] 40. Bus; 41. Processor; 42. Memory; 43. Communication interface. Detailed Implementation

[0022] In the description of this application, it should be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", "axial", "radial", "circumferential", etc., indicating the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. In this application, unless otherwise expressly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection, an electrical connection, or a connection that allows communication between components; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication between two components or the interaction between two components, unless otherwise expressly limited. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances. In this application, unless otherwise expressly specified and limited, "above" or "below" the second feature can mean that the first feature is in direct contact with the second feature, or that the first feature is in indirect contact with the second feature through an intermediate medium. Furthermore, "above," "on top of," and "over" the second feature can mean that the first feature is directly above or diagonally above the second feature, or simply that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature can mean that the first feature is directly below or diagonally below the second feature, or simply that the first feature is at a lower horizontal level than the second feature. In this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0023] The present application will now be described in detail through exemplary embodiments. However, it should be understood that, without further description, elements, structures, and features in one embodiment may be advantageously incorporated into other embodiments. With the digital transformation of industries such as retail, catering, and finance, point-of-sale (POS) machines have become core equipment for completing transactions, managing inventory, and conducting data analysis.

[0024] A POS machine is a computer system equipped with specific software and peripherals used to process payments and record transaction data at the point of sale.

[0025] Peripheral devices for a POS machine can include barcode scanners, printers, card readers, etc.

[0026] Currently, most POS machines on the market use Windows, Android, and various Linux distributions as their operating systems. Linux, due to its advantages such as being open-source, having a stable kernel, high customizability, and low licensing costs, has gained widespread use in commercial devices that require long-term stable operation and are cost-sensitive.

[0027] Linux is a Unix-like computer operating system kernel. Based on this kernel, many different distributions such as Ubuntu, Debian, CentOS, and Red Hat have been derived. These distributions share core features, but differ in package management tools, system initialization methods, pre-installed software sets, and system library file versions.

[0028] This diversity and fragmentation of the Linux ecosystem presents significant challenges to the unified remote maintenance of POS devices. Incompatibility can exist between different distributions and even different versions of the same distribution in terms of system environment, dependency libraries, and interfaces. This often prevents maintenance tools or client programs compiled for a specific Linux environment from running directly on devices running on other versions.

[0029] Traditional remote maintenance solutions typically employ a client-server architecture, where a dedicated backend client program is deployed on the POS terminal. This program needs to establish and maintain a persistent network connection with the remote management server to receive instructions from the server.

[0030] This type of solution has several inherent flaws: First, it is highly dependent on a continuous and stable network connection of the terminal device, and it is difficult to work effectively in environments with poor network signal, intermittent network outages, or private network isolation. Secondly, the maintainers need to develop, test, and adapt corresponding client programs for different hardware architectures (such as x86, ARM) and different Linux distributions, which leads to extremely high development complexity and long-term maintenance costs. Finally, this approach fails to fully utilize the existing hardware interaction methods on-site at the POS equipment, which are extremely familiar to operators, to simplify the maintenance process.

[0031] Therefore, the present invention provides a Linux POS machine maintenance method, system, and electronic device to at least solve the problems of excessive reliance on stable network connections, poor compatibility across different Linux distributions, and high maintenance costs in existing POS machine maintenance methods.

[0032] The following is combined Figures 1-4 The specific process of the Linux POS machine maintenance method of this invention is described in detail.

[0033] In some embodiments, the Linux POS machine maintenance method of the present invention includes a device location step, which includes: The scanning device can be bound to the supplier's and product's identifiers, or the device connected to a specific physical USB interface on the POS machine can be designated as the scanning device by default.

[0034] Preferably, the device positioning step is used to identify and bind the scanning device as the source of instruction input when the POS machine starts its background service or when a new USB device is connected.

[0035] Furthermore, the specific implementation of the equipment positioning step includes the following two optional positioning strategies.

[0036] Specifically, for known models of proprietary or branded barcode scanning devices, a positioning strategy based on device identification for binding the barcode scanning device can be applied.

[0037] The background service reads the vendor ID (VID) and product ID (PID) of the connected USB device.

[0038] VID and PID are unique identifiers assigned by the USB standard to each device manufacturer and its product model.

[0039] The service program internally maintains a list of legal devices, which records the allowed combinations of device VID and PID. When the VID and PID of an access device match any record in the list, the system automatically recognizes that device as the input device for the task command and begins listening to its corresponding device file.

[0040] Specifically, for other unknown models of barcode scanning devices, a positioning strategy based on a fixed physical interface and a binding agreement can be adopted.

[0041] The location strategy based on the fixed physical interface is mainly used to ensure compatibility with various third-party scanning devices at the customer's site.

[0042] Administrators will pre-define one or more specific physical USB ports on the POS machine for connecting scanning devices, such as USB Port 1 on the back panel of the host.

[0043] Once the background service starts, regardless of the brand or model of the device connected to the designated port, the system will default to it as a barcode scanner and bind it to a fixed device file path corresponding to that port. This method simplifies the software identification logic by ensuring the determinacy of the hardware connection location, achieving broad compatibility with USB barcode scanners of any brand.

[0044] Preferably, the two positioning strategies described above can be combined to form a hierarchical positioning logic. The system first attempts to perform accurate identification based on VID & PID; if no match is found, it then uses a fixed interface binding method as a fallback. This ensures both the accuracy and automation of identification for proprietary devices and general compatibility with external devices.

[0045] In some embodiments, the Linux POS machine maintenance method of the present invention further includes a device status monitoring step, which includes: Monitor the connection status of the barcode scanning device; When a reconnection of a scanning device is detected, update the scanning device binding information in the background service.

[0046] Preferably, in order to achieve reliable monitoring and automatic recovery of the connection status of the barcode scanning device, this embodiment utilizes the udev (user space device manager) mechanism provided by the Linux operating system kernel to monitor the status of the barcode scanning device.

[0047] udev is responsible for dynamically managing device nodes under the / dev directory in user space and can respond to device events issued by the kernel in real time, such as the connection, removal, and status changes of USB devices.

[0048] Furthermore, the system listens for events from the target barcode scanning device by configuring a custom udev rule file.

[0049] udev rule files can perform precise filtering based on the device's VID & PID or a fixed kernel device path, such as matching a specific USB port using KERNELS.

[0050] For example, udev will detect a remove event when the target scanning device is unplugged; when the same device is plugged in again, an add event will be triggered.

[0051] In this embodiment, the background service acts as a handler after a udev rule is triggered, or obtains state change notifications by monitoring udev events.

[0052] When the service receives a remove event from the scanning device, it can record the device's offline status and optionally pause data reading from the corresponding buffer.

[0053] When an add event is received for the same device, the service immediately performs the following key operations: Re-query and determine the new device file path for the device in the system, and update the device handle within the service; Actively clear the input buffer associated with the old device handle, discard incomplete or erroneous data that may be generated due to accidental disconnection, and ensure the purity of the data stream after the new connection is established; Use the new device file path to restart the data listening thread or resume polling reads to ensure a rapid recovery of the maintenance command channel.

[0054] In addition, to cope with complex field environments, the service can perform a quick device self-test or handshake communication after the device is reconnected to confirm that the device is functioning normally, thereby ensuring the robustness of the entire command input link.

[0055] It should be noted that, Figure 1 Here is a flowchart of the server-side task generation and publishing method according to the embodiments of this application, such as... Figure 1 As shown, before executing the Linux POS machine maintenance method on the Linux POS machine device side, the server first executes the task publishing process to provide the target POS machine device side with scannable and executable task instructions.

[0056] Specifically, the task release process includes: after receiving a maintenance request for the target POS machine, the server first determines the on-site environment of the target POS machine and the specific maintenance task to be performed; then, it creates a corresponding remote system maintenance task package based on the maintenance task. The remote task package typically contains the Shell scripts and related resource files required to implement the maintenance function; next, it uploads the created remote task package to a publicly accessible file server and generates a unique download link for the remote task package; then, it concatenates a predefined trigger command string with this download link and encodes the concatenated complete string to generate a task QR code image.

[0057] After generating the task QR code image, the QR code can be scanned to test whether it can be correctly parsed and trigger the expected process. After the test is passed, the task QR code will be published to the users or operators at the target POS terminal on-site via instant messaging tools, email, etc.

[0058] In some embodiments, such as Figures 2-4 As shown, the present invention provides a Linux POS machine maintenance method, applied to the POS machine device, including a monitoring step S1, an identification step S2, an acquisition step S3, and an execution step S4.

[0059] Monitoring step S1: Run the background service to continuously monitor the input data of the scanning device connected to the POS machine.

[0060] Preferably, the raw input data is obtained by reading the device file node created by the Linux kernel for the barcode scanning device; wherein, the device file node is usually in the form of / dev / input / event or / dev / ttyUSB.

[0061] In some embodiments, such as Figure 4 As shown, the monitoring step S1 includes: Set a fixed-size input buffer; store the input data from the barcode scanner into the input buffer; When a newline character is detected, the input buffer data is extracted, and the recognition step is triggered; After the recognition step is completed, clear the input buffer.

[0062] Preferably, to handle the high-speed, high-frequency input characteristics of the scanning device, the service sets up a fixed-size input buffer and stores the scanned character data into the buffer in real time. When a carriage return character indicating the end of the instruction is detected in the input data, the system extracts the complete data in the buffer and triggers the subsequent recognition steps. After the recognition steps are completed, the buffer is cleared to prepare for receiving the next input.

[0063] Furthermore, the input buffer is managed by one or more of the following enhancement logic.

[0064] The input buffer prevents memory overflow by setting a fixed capacity limit and triggering a policy of discarding the oldest data or clearing the buffer when it is full.

[0065] The input buffer is set with a carriage return clearing mechanism to ensure that the input buffer is reset immediately after each processing to avoid the sticking of previous and subsequent instructions.

[0066] The input buffer is configured with a device reconnection clearing mechanism. By using Linux's udev mechanism to monitor device plugging and unplugging events, the buffer is actively cleared when a scanning device reconnects, in order to eliminate any incomplete data that may remain due to accidental disconnection, thereby ensuring the integrity of data processing and the robustness of the system.

[0067] Identification step S2: Identify the task triggering instruction that conforms to the preset format from the input data. The task triggering instruction includes the acquisition path of the remote task package.

[0068] Preferably, the preset format can be set as a concatenated string structure of a fixed command header and task data, wherein the fixed command header is a predefined trigger command string and the task data is a Uniform Resource Locator (URL) pointing to a remote task package.

[0069] In some embodiments, the identification step S2 specifically includes: The input buffer data is matched and judged. If the input buffer data contains a predefined trigger command string, the task trigger instruction is identified and the string following it is used as the acquisition path of the remote task package.

[0070] Preferably, the predefined trigger command string can be set to "WTRUNTASK". As a unique instruction identifier for remote tasks, the trigger command string can effectively distinguish between routine business barcode scanning and system maintenance instructions.

[0071] Furthermore, the URL address in complete HTTP or HTTPS format is obtained. After extracting the URL, identification step S2 passes it to the subsequent acquisition step S3 for downloading the task package from the corresponding file server. To improve reliability, a format validation step can also be included after parsing the URL, such as checking whether it contains a valid protocol header (e.g., http: / / or https: / / ) and domain name, to avoid invalid requests due to scanning errors or data corruption.

[0072] In addition, if the string does not start with "WTRUNTASK", the recognition step S2 determines that the input is ordinary data, the process ends, and the remote maintenance task is not triggered, thus ensuring the transparency and non-interference of the background service to the daily scanning business.

[0073] Step S3: In response to the recognition of the task trigger command, obtain the remote task package according to the acquisition path.

[0074] Preferably, step S3 is implemented by downloading from the network and includes an integrity verification mechanism to ensure that the acquired task package file is complete and usable.

[0075] In some embodiments, obtaining step S3 includes: Parse the task trigger command to extract the acquisition path; Based on the acquisition path, download the corresponding remote task package from the remote file server.

[0076] Preferably, the download process is executed using command-line network tools that come with the Linux system, such as wget or curl. These command-line network tools are widely available and used consistently, further enhancing compatibility with different Linux distributions.

[0077] Furthermore, during or after the download process, the system can perform one or more enhancement operations to improve reliability, security, and resource management efficiency.

[0078] Specifically, if a download fails, such as due to a network timeout or a server not responding, the system will initiate an error retry mechanism, automatically making a limited number of retries, and recording the error information in the system log or providing a prompt through the user interface when it ultimately fails, to facilitate problem tracking.

[0079] To ensure the integrity and accuracy of the acquired file content, the system supports integrity verification, which involves obtaining the checksum of the remote task package file from the file server or task instruction, comparing it after the local download is complete, and only when the checksum matches is the acquisition considered successful and the subsequent steps proceed.

[0080] Regarding transmission security, when the acquisition path is an HTTPS link, the download process can be encrypted using the SSL / TLS protocol supported by the tool, thereby ensuring the security of the task package during transmission.

[0081] The system manages downloaded files in an orderly manner, saving them to a designated temporary directory on the POS machine. After the task is completed or before a new round of downloads begins, the system automatically cleans up the relevant files in this directory to free up storage space and prevent old files from causing interference.

[0082] In addition, a remote task package is usually a compressed file, such as ZIP or TAR.GZ format, which contains shell scripts required to perform system maintenance, as well as configuration files, binary programs, or data files that may be used.

[0083] Step S4: Parse and execute the script in the remote task package to complete the maintenance operation on the POS machine device.

[0084] In some embodiments, performing step S4 includes: Unzip the remote task package; The script parser on the POS machine is invoked to sequentially execute the predefined script files within the remote task package.

[0085] In some embodiments, the script parser is a shell parser.

[0086] Preferably, the script parser uses a Shell interpreter. Based on the fact that Shell is widely available in most Linux distributions and has a unified syntax, this ensures broad compatibility of the maintenance solution and direct execution.

[0087] Furthermore, step S4 also includes environmental preparation and reliability assurance mechanisms.

[0088] For example, before executing the main maintenance script, an environment check script can be run to verify whether the necessary system tools, dependencies, or disk space meet the requirements.

[0089] Furthermore, during the script execution sequence, command output and return codes are captured in real time to determine the success or failure of each step. If a step fails, subsequent processes can be aborted, a rollback operation performed, or a detailed error log recorded according to preset strategies. All output information generated during execution can be redirected to a temporary log file for easy result verification or problem diagnosis after maintenance operations are completed.

[0090] In addition, the maintenance operations contained in the script file may specifically involve software package upgrades, configuration file modifications, service restarts, log cleanup, or the collection and reporting of specific diagnostic information.

[0091] By encapsulating complex maintenance processes into versionable and remotely distributable script packages, even users unfamiliar with Linux commands can trigger and complete professional system maintenance through a simple QR code scan, thereby significantly reducing the technical threshold and service costs.

[0092] The results of the entire execution process can be concisely displayed through the user interface of the POS machine, and key summaries will also be written to the system log to provide a basis for possible remote status monitoring or subsequent auditing.

[0093] like Figure 5 As shown, the present invention provides a Linux POS machine maintenance system for implementing the Linux POS machine maintenance method described above, including a monitoring module 100, an identification module 200, an acquisition module 300, and an execution module 400.

[0094] The monitoring module 100 is used to run background services and continuously monitor the input data of the scanning device connected to the POS machine. The recognition module 200 is used to identify task triggering instructions that conform to a preset format from the input data. The task triggering instructions include the acquisition path of the remote task package. The acquisition module 300 is used to acquire a remote task package according to the acquisition path in response to the identified task trigger command; The execution module 400 is used to parse and execute the scripts in the remote task package to complete the maintenance operations on the POS machine device.

[0095] Combination Figure 6 As shown, this embodiment discloses a specific implementation of a computer device. The computer device may include a processor 41 and a memory 42 storing computer program instructions.

[0096] Specifically, the processor 41 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0097] The memory 42 may include a large-capacity storage device for data or instructions. For example, and not limitingly, the memory 42 may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 42 may include removable or non-removable (or fixed) media. Where appropriate, the memory 42 may be internal or external to the data processing device. In a particular embodiment, the memory 42 is non-volatile. Volatile memory. In a particular embodiment, memory 42 includes read-only memory. ROM (ROM-only memory) and RAM (Random Access Memory). Where appropriate, the ROM can be a mask-programmed ROM or a programmable ROM. Only Memory (PROM) and Erasable Programmable Read-Only Memory (EPRROM) The RAM can be a type of RAM, such as EPROM (Electrically Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), EAROM (Electrically Alterable Read-Only Memory), or FLASH (Flash Memory), or a combination of two or more of these. Where appropriate, the RAM can be a Static Random Access Memory (SRAM). Access Memory (SRAM) or Dynamic Random Access Memory (DRAM) can be Fast Page Mode Dynamic Random Access Memory (FPMDRAM), Extended Data Out Dynamic Random Access Memory (EDODRAM), Synchronous Dynamic Random-Access Memory (SDRAM), etc.

[0098] The memory 42 can be used to store or cache various data files that need to be processed and / or used for communication, as well as possible computer program instructions executed by the processor 41.

[0099] The processor 41 implements the Linux POS machine maintenance method in the above embodiments by reading and executing computer program instructions stored in the memory 42.

[0100] In some embodiments, the computer device may further include a communication interface 43 and a bus 40. For example, Figure 6 As shown, the processor 41, memory 42, and communication interface 43 are connected through bus 40 and complete communication with each other.

[0101] Communication interface 43 is used to enable communication between modules, devices, units and / or equipment in the embodiments of this application.

[0102] Communication port 43 can also enable data communication with other components such as external devices, image / data acquisition devices, databases, external storage, and image / data processing workstations.

[0103] Bus 40 includes hardware, software, or both, that couples components of a computer device together. Bus 40 includes, but is not limited to, at least one of the following: a data bus, an address bus, a control bus, an expansion bus, and a local bus. For example, and not as a limitation, bus 40 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, and a PCI bus. Express (PCI The bus may be an X-bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 40 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0104] Furthermore, in conjunction with the Linux POS machine maintenance methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the Linux POS machine maintenance methods in the above embodiments.

[0105] The present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-described Linux POS machine maintenance method.

[0106] The present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described Linux POS machine maintenance method.

[0107] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments for application in other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A Linux POS machine maintenance method, applied to the POS machine device, characterized in that, Includes the following steps: Monitoring steps: Run a background service to continuously monitor the input data of the scanning device connected to the POS machine. Identification step: Identify a task trigger instruction that conforms to a preset format from the input data, wherein the task trigger instruction contains the acquisition path of the remote task package; Acquisition Steps: In response to recognizing the task trigger command, acquire the remote task package according to the acquisition path; Execution steps: Parse and execute the script in the remote task package to complete the maintenance operation on the POS machine device.

2. The Linux POS machine maintenance method according to claim 1, characterized in that, It also includes the device positioning step, including: The scanning device is bound to the supplier's identifier and product identifier; or... The device connected to a specific physical USB interface on the POS machine is designated as the scanning device.

3. The Linux POS machine maintenance method according to claim 1, characterized in that, It also includes equipment status monitoring steps: Monitor the connection status of the scanning device; When the reconnection of the scanning device is detected, the scanning device binding information of the background service is updated.

4. The Linux POS machine maintenance method according to claim 1, characterized in that, The monitoring steps include: Set a fixed-size input buffer; store the input data of the barcode scanner into the input buffer; When a newline character is detected, the data in the input buffer is extracted, and the recognition step is triggered. After the recognition step is completed, the input buffer is cleared.

5. The Linux POS machine maintenance method according to claim 4, characterized in that, The identification steps specifically include: The input buffer data is matched and judged. If the input buffer data contains a predefined trigger command string, the task trigger instruction is identified and the string following it is used as the acquisition path of the remote task package.

6. The Linux POS machine maintenance method according to claim 1, characterized in that, The acquisition steps include: Parse the task trigger command to extract the acquisition path; Based on the acquisition path, download the corresponding remote task package from the remote file server.

7. The Linux POS machine maintenance method according to claim 1, characterized in that, The execution steps include: Decompress the remote task package; The script parser on the POS machine is invoked to sequentially execute the predefined script files within the remote task package.

8. The Linux POS machine maintenance method according to claim 7, characterized in that, The script parser is a Shell parser.

9. A Linux POS machine maintenance system, used to implement the Linux POS machine maintenance method as described in any one of claims 1-8, characterized in that, include: The monitoring module is used to run background services and continuously monitor the input data of the scanning device connected to the POS machine. The identification module is used to identify task triggering instructions that conform to a preset format from the input data, wherein the task triggering instructions include the acquisition path of the remote task package; The acquisition module is used to acquire a remote task package according to the acquisition path in response to the identified task triggering instruction; The execution module is used to parse and execute the scripts in the remote task package to complete the maintenance operations on the POS machine device.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the Linux POS machine maintenance method as described in any one of claims 1-8.

Images