Is not loaded properly exec format error

Fix “Exec format error” When Running Scripts With run-parts Command

When I was trying to run all scripts in a directory using run-parts command, I encountered with an error — «run-parts: failed to exec script.sh: Exec format error». The scripts worked just fine when I directly execute them like «./script.sh» and «sh script.sh». But they didn’t work when I ran them with run-parts command. For those wondering, the run-parts command will run all scripts in a directory. If you got an error like this while running a script, this quick tip will help you to fix «Exec format error» when running scripts with run-parts command in Linux.

Fix «Exec format error» When Running Scripts With run-parts Command

To run all scripts in the Documents folder, I ran:

I got the following error message:

run-parts: failed to exec script.sh: Exec format error

To fix «Exec format error», you need to add a shebang at the start of your scripts so the kernel will know how to run them. For those wondering, a shebang is the character sequence consisting of the characters number sign and exclamation mark (#!) at the beginning of a script. When you add the shebang at the start of a text file, it is interpreted as an executable file.

Most scripts starts with a shebang. Here are some typical shebang examples.

Bourne shell, or a compatible shell:

Bash:

Perl:

Python 2.x:

Python 3.x:

This is what we call a shebang.

Now, let us get back to the topic. Edit your scripts using your favorite editor:

Add the following shebang at the beginning of the script:

Fix «Exec format error» When Running Scripts With run-parts

Now you can be able to run the scripts with run-parts command without any issues using run-parts command.

Update:

As one of our reader Mr.Danesh mentioned in the comment section below, Instead of hard-coding the path of the interpreter, e.g.

This is more portable in case the interpreter is installed in some other (non-default) directory. env is a shell command for Linux and Unix-like operating systems. It is often used by shell scripts to launch the correct interpreter.

You can also use ShellCheck utility to find problems in your shell scripts.

Источник

nodejs not working, exec format error #8151

Version

Microsoft Windows [Version 10.0.19044.1586]

WSL Version

Kernel Version

Distro Version

Other Software

Repro Steps

Install nodejs from Archlinux repo with pacman -S nodejs , and run node

Expected Behavior

Actual Behavior

nodejs does not start. exec format error.

Diagnostic Logs

nodejs can start if we manually invoke ld-linux, although it is already the interpreter in the ELF.

$ /lib64/ld-linux-x86-64.so.2 /usr/bin/node Welcome to Node.js v17.7.1. Type «.help» for more information. > wangqr@ocalhost:

$ file /usr/bin/node /usr/bin/node: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=10ec67f51a763d04ac6e1fe305ce214fb40eabda, for GNU/Linux 4.4.0, stripped wangqr@ocalhost:

$ readelf -h /usr/bin/node ELF Header: Magic: 7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2’s complement, little endian Version: 1 (current) OS/ABI: UNIX — GNU ABI Version: 0 Type: DYN (Position-Independent Executable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x6aa570 Start of program headers: 64 (bytes into file) Start of section headers: 34087608 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 16 Size of section headers: 64 (bytes) Number of section headers: 30 Section header string table index: 29 «>

The text was updated successfully, but these errors were encountered:

Источник

Thread: systemd-resolved.service is not loaded properly: Exec format error.

Thread Tools

Display

systemd-resolved.service is not loaded properly: Exec format error.

I have a headless Ubuntu Server with some DNS trouble. After some troubeshooting to find out why it did not have an internet connection I found that starting systemd-resolved.service fixed the issue.
I didn’t have time to figure out how to start it automatically at boot so I’ve been doing that manually via ssh for now.
This time it won’t start the service;

Some advice on how to troubleshoot would be great!

Re: systemd-resolved.service is not loaded properly: Exec format error.

What do you see in /var/log/syslog? That’s where systemd logs everything.

An «Exec format error» usually means the executable program is somehow bad. Might I suggest reinstalling systemd-resolved?

If you ask for help, do not abandon your request. Please have the courtesy to check for responses and thank the people who helped you.

Re: systemd-resolved.service is not loaded properly: Exec format error.

I tried tailing it but nothing happens. I can see other events, like me logging in to ssh, but nothing about systemd-resolved. «cat /var/log/syslog | grep resolved» gives nothing.

An «Exec format error» usually means the executable program is somehow bad. Might I suggest reinstalling systemd-resolved?

Is it possible to use apt without internet? I am running Linux Mint on another machine. Can I download the files needed there and copy them over to my server?

Re: systemd-resolved.service is not loaded properly: Exec format error.

Ok, so I’ve been tinkering with this a bit and I found a solution.

Being the linux-noob that I am, I might be doing this a bit cumbersome.
I tried to figure out if I could somehow download the packages on another pc and copy them over, but I didn’t find what I needed. I found something called openvpn-systemd-resolved https://packages.ubuntu.com/bionic/o. stemd-resolved, but I’m not sure if it is the same as systemd-resolved. Also, from what I understand I would have to download all dependecies manually to transfer over to the server and install with dpkg, so I tried something else.

I downloaded the ubuntu server 18.04 LTS image from canonical and installed it in a virtualbox vm.
I could find from «sudo systemctl status systemd-resolved.service» which file was loaded;

After a reboot it worked like charm.
I notice that the file sizes are quite different, the old one is quite small compared to the new one.
Any insight here would be great.

Could I have done this an easier way? Should I have done it differently or is it ok to replace this service-file like I did?

Источник

Fix “Exec format error” When Running Scripts With run-parts Command

When I was trying to run all scripts in a directory using run-parts command, I encountered with an error – “run-parts: failed to exec script.sh: Exec format error”. The scripts worked just fine when I directly execute them like “./script.sh” and “sh script.sh”. But they didn’t work when I ran them with run-parts command. For those wondering, the run-parts command will run all scripts in a directory. If you got an error like this while running a script, this quick tip will help you to fix “Exec format error” when running scripts with run-parts command in Linux.

Fix “Exec format error” When Running Scripts With run-parts Command

To run all scripts in the Documents folder, I ran:

I got the following error message:

To fix “Exec format error”, you need to add a shebang at the start of your scripts so the kernel will know how to run them. For those wondering, a shebang is the character sequence consisting of the characters number sign and exclamation mark (#!) at the beginning of a script. When you add the shebang at the start of a text file, it is interpreted as an executable file.

Most scripts starts with a shebang. Here are some typical shebang examples.

Bourne shell, or a compatible shell:

Bash:

Perl:

Python 2.x:

Python 3.x:

This is what we call a shebang.

Now, let us get back to the topic. Edit your scripts using your favorite editor:

Add the following shebang at the beginning of the script:

Now you can be able to run the scripts with run-parts command without any issues using run-parts command.

You can also use ShellCheck utility to find problems in your shell scripts.

Источник

exec format error when building or restarting container after docker server restart #7527

On a fresh install of docker on Ubuntu 14.04 LTS (GNU/Linux 3.13.0-29-generic x86_64) I use a remote docker client to build/start container on another machine (same ubuntu version same docker version.

First I get this error while building:

I always get the same message when trying to re-build a dockerfile even with —no-cache=true

If I restart the docker server, some of the running container are still running and the one not running throw this error if I try to restart them.

The text was updated successfully, but these errors were encountered:

If I stop the docker server and try to delete the docker root file I get this

Are you sure you are not missing a chmod +x on any of the binaries that are you trying to exec?

It fails on cd /tmp (I tried to decompose the RUN command) and it also failed on ln -s . on another server.

Those dockerfiles already runs on a couple of different configurations like

• ubuntu 12.04 (paravirtual) on ec2 with docker 1.1.0
• ubuntu 14.04 (hvm) on ec2 with docker 1.1.2
• boot2docker on development box with docker 1.0.1

• ubuntu 14.04 (paravirtual) on ec2 with docker 1.1.2

I also got this error

With those errors:

if docker is using devicemapper on ubuntu it looks like you have a non standard ubuntu kernel because they should be compiled with AUFS support.

Can you run check-config.sh on your system having issues and paste the output?

could it be related with #4036 ?

Are you telling docker to use devicemapper over AUFS?

Maybe this can this tell docker to use devicemapper over AUFS? /mnt is a ext3 partition from what I see.

DOCKER_OPTS=»-g=/mnt/docker -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock»

humm, I’m guessing the other systems that you tested on did not use the -g option?

The system on 12.04 use the -g option but not the other one on 14.04. So the 12.04 use AUFS (with -g option) and 14.04 seems to use devicemapper by default (-g or not)!

Does the 12.04 system have an ext3 formatted partition that is being used?

Yes /mnt type ext3 like the other one

But I think that I updated it from 0.8 or 0.9, maybe back then it wasn’t default to devicemapper.

I deleted my docker directory (/mnt/docker) install the kernel extra

Now docker use AUFS by default and no more weird behavior. In addition, it’s way faster! I don’t know what’s the plan for devicemapper, but it seems that it still need a bit of love!

@synhaptein: one interesting thing to try would be to compare the checksum (md5 or sha1) of the binary you are executing (dnsmasq?) from a failing container versus a working one. If they are different, this may be a duplicate of #7229

i have same error with restarting a container that runned befor !
frank@h1: $ docker start proxy
Error response from daemon: Cannot start container proxy: exec format error
2014/09/23 07:33:15 Error: failed to start one or more containers
frank@h1: $ docker-current start proxy
Error response from daemon: Cannot start container proxy: exec format error
2014/09/23 07:33:23 Error: failed to start one or more containers
frank@h1:

Had the same thing. It turned out we had built and committed our repos on CoreOS/btrfs locally and downloaded them on Trusty with devicemapper. Just crapped out.

Downloaded a base ubuntu image, installed docker, rebuilt the exact same dockerfile and filesystem, recommited and it worked perfectly on our servers

Scratch that, any time I changed the cmd using «docker run» this happened — even after recompiling on the same OS/driver pair. Had to change to AUFS the same way @synhaptein did.

closing as this seems to be resolved but let me know otherwise

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх

Common systemd usage is to manage global linux services, that can be created/modified only with root/sudo credentials.

But systemd have the great user mode, that allow to create and control any services without sudo permissions, that runs as user owner, we simply need to add the `—user` argument.

For allow to start user services on system boot, you must one-time launch the command for needed user: sudo loginctl enable-linger LOGIN

General commands to list and control the systemd user services:

List of all available services for user: systemctl --user list-units --type=service -a — example of output:

UNIT                             LOAD   ACTIVE   SUB     DESCRIPTION                                   
admin-mongo.service              loaded active   running admin-mongo.service              
dirmngr.service                  loaded inactive dead    GnuPG network certificate management daemon   
gpg-agent.service                loaded inactive dead    GnuPG cryptographic agent and passphrase cache

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

3 loaded units listed.

Show the status of specific service: systemctl --user status admin-mongo.service — example of output:

● dev.brick.ru_admin-mongo.service
   Loaded: loaded (/home/alice/.config/systemd/user/admin-mongo.service; enabled; vendor 
   Active: active (running) since Fri 2021-03-12 16:17:04 MSK; 1s ago
 Main PID: 30089 (node)
   CGroup: /user.slice/user-1001.slice/user@1001.service/admin-mongo.service
           ├─30089 node /usr/bin/yarn start
           ├─30104 /bin/sh -c node app.js
           └─30105 /usr/bin/node app.js

Mar 12 16:17:04 brs.brick.ru systemd[1598]: Started admin-mongo.service.
Mar 12 16:17:04 brs.brick.ru yarn[30089]: yarn run v1.22.10

Controlling the specific systemd user service:

• Start: systemctl --user start admin-mongo.service
• Stop: systemctl --user stop admin-mongo.service
• Restart: systemctl --user restart admin-mongo.service
• Watch logs online: journalctl --user -u admin-mongo -n 10 -f (10 — number of last lines to display)

Creating new services:

For create the new services you need to create the file in user’s homefolder at subpath .config/systemd/user/SERVICENAME.service with content like this:

[Unit]
AssertPathExists=/home/alice/tools/adminMongo

[Service]
WorkingDirectory=/home/alicetools/adminMongo
Environment=GHOST_NODE_VERSION_CHECK=false
ExecStart=/usr/bin/yarn start
Restart=always
PrivateTmp=true
NoNewPrivileges=true

[Install]
WantedBy=default.target

If you modify the file after, don’t forget to reload the service information via command: systemctl --user daemon-reload

If you got the: Exec format error

Note, that user’s service files must not contain the User=alice and Group=alice lines, like the system-wide services, otherwise you will got the error:

Failed to start admin-mongo.service: Unit admin-mongo.service is not loaded properly: Exec format error.
See user logs and 'systemctl --user status admin-mongo.service' for details.

Solution is to remove (or comment-out via #) thouse lines in .service file, and do the daemon-reload.