Urbackup does not start with Raising nice-ceiling to 35 failed

Server
1

I’m using an Fedora 38 LXC in Proxmox.

I was trying to start UrBackup so I created this simple SystemD service:

[Unit]
Description=UrBackup
After=network-online.target
Requires=mnt-backup1.mount mnt-backup2.mount

[Service]
User=urbackup
Group=urbackup
ExecStart=/usr/bin/urbackupsrv run -d

[Install]
WantedBy=multi-user.target

SystemD is unable to start it:

$ sudo systemctl start urbackup
$ sudo systemctl status urbackup
○ urbackup.service - UrBackup
     Loaded: loaded (/usr/lib/systemd/system/urbackup.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: inactive (dead) since Fri 2023-09-22 23:00:08 -03; 2s ago
   Duration: 8ms
    Process: 8646 ExecStart=/usr/bin/urbackupsrv run -d (code=exited, status=0/SUCCESS)
   Main PID: 8646 (code=exited, status=0/SUCCESS)
        CPU: 7ms

Sep 22 23:00:08 urbackup systemd[1]: Started urbackup.service - UrBackup.
Sep 22 23:00:08 urbackup urbackupsrv[8646]: Raising nice-ceiling to 35 failed. (errno=1)
Sep 22 23:00:08 urbackup systemd[1]: urbackup.service: Deactivated successfully.

However, when I start UrBackup manually, it shows the same error, but the process is started.

$ sudo urbackupsrv run -d -u urbackup
Raising nice-ceiling to 35 failed. (errno=1)

So, what does Raising nice-ceiling to 35 failed. (errno=1) means after all?

2

Run this inside the container:

capsh --print | grep cap_sys_resource

If nothing is printed, you should add this capability to the container in Proxmox:

  1. SSH to the Proxmox node hosting this container
  2. Edit /etc/pve/lxc/123.conf (change 123 to the container’s id)
  3. Add sys_resource to lxc.cap.keep, separated by space (if such line doesn’t exist, add it: lxc.cap.keep: sys_resource)
  4. Remove sys_resource from lxc.cap.drop (if it exists)
  5. Save and restart the container
3

Thanks your quick reply.

The container appears to have this capability.

$ sudo capsh --print | grep cap_sys_resource
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,
**cap_sys_resource**
,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore

This is the LXC configuration:

# cat /etc/pve/lxc/914.conf
arch: amd64
cores: 2
cpulimit: 2
features: nesting=1
hostname: urbackup
memory: 2048
mp0: /mnt/backup1,mp=/mnt/backup1
mp1: /mnt/backup2,mp=/mnt/backup2
nameserver: 192.168.7.1
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.7.1,hwaddr=1A:78:C7:8A:6D:BD,ip=192.168.7.220/24,type=veth
ostype: fedora
rootfs: VMs:vm-914-disk-0,mountoptions=lazytime,size=200G
searchdomain: local.prox
swap: 0
unprivileged: 1

I tried adding the lxc.cap.keep: sys_resource line, but that made the container fail to start.

4

Great, it means the container has the required capability.

Now let’s check the user running urbackup.

$ sudo su - urbackup -s /usr/bin/bash
$ getpcaps $$

5

Urbackup user:

$ sudo su - urbackup -s /usr/bin/bash
[urbackup@urbackup tmp]$ getpcaps $$
219: =
6

Now for the final blow:

setcap cap_sys_resource,cap_sys_nice=+ep /usr/bin/urbackupsrv

7

I’ve set the capability.

# setcap cap_sys_resource,cap_sys_nice=+ep /usr/bin/urbackupsrv
# setcap -v cap_sys_resource,cap_sys_nice=+ep /usr/bin/urbackupsrv
/usr/bin/urbackupsrv: OK

Then, tried to start Urbackup, but, once again, I got the same error.

# systemctl start urbackup
# systemctl status urbackup
○ urbackup.service - UrBackup
     Loaded: loaded (/usr/lib/systemd/system/urbackup.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: inactive (dead) since Thu 2023-09-28 20:36:01 -03; 1s ago
   Duration: 12ms
    Process: 6112 ExecStart=/usr/bin/urbackupsrv run -d (code=exited, status=0/SUCCESS)
   Main PID: 6112 (code=exited, status=0/SUCCESS)
        CPU: 12ms

Sep 28 20:36:01 urbackup systemd[1]: Started urbackup.service - UrBackup.
Sep 28 20:36:01 urbackup urbackupsrv[6112]: Raising nice-ceiling to 35 failed. (errno=1)
Sep 28 20:36:01 urbackup systemd[1]: urbackup.service: Deactivated successfully.

When I check Urbackup user’s capabilities, I see that it changed.

# su - urbackup -s /usr/bin/bash
$ getpcaps $$
6149: =
8

Why are things more difficult than they have to be :slight_smile:

Try adding this line to the service:

AmbientCapabilities=CAP_SYS_RESOURCE CAP_SYS_NICE

Then reload with:

sudo systemctl daemon-reload

And restart the service.

If this doesn’t help, I have one more thing to try involving PAM, but let’s cross our fingers with this one.

9

Unfortunately, that did not help.

# cat /lib/systemd/system/urbackup.service
[Unit]
Description=UrBackup
After=network-online.target
Requires=mnt-backup1.mount mnt-backup2.mount

[Service]
User=urbackup
Group=urbackup
ExecStart=/usr/bin/urbackupsrv run -d
AmbientCapabilities=CAP_SYS_RESOURCE CAP_SYS_NICE

[Install]
WantedBy=multi-user.target

# systemctl daemon-reload
# systemctl start urbackup
# systemctl status urbackup
○ urbackup.service - UrBackup
     Loaded: loaded (/usr/lib/systemd/system/urbackup.service; disabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: inactive (dead)

Sep 30 11:36:48 urbackup systemd[1]: Started urbackup.service - UrBackup.
Sep 30 11:36:48 urbackup urbackupsrv[289]: Raising nice-ceiling to 35 failed. (errno=1)
Sep 30 11:36:48 urbackup systemd[1]: urbackup.service: Deactivated successfully.
10

This indicates something system wide since not even root are allowed to increase it.

ps -eo pid,ppid,pri,ni,comm shows the niceness (ni) and priority (pri), could be a good place to start.
There are utilities like nice and renice but IIRC only root can change the niceness so this might not be the way to do it.

I think (big emphasis on think) you can set the prio and nice level in /etc/security/limits.conf on a per user level, maybe that is what you should look into.

Have you tried defining the systemd service with Type=simple?

Edit
I just checked how I made my systemd service and I did not include user or group, but urbackupsrv is running as urbackup. Try removing user and group, deamon-reload and restart the service.