Buildbot 与 systemd 集成：从进程管理到生产级 CI 服务

原创 于 2026-06-21 12:23:14 发布 · 447 阅读 · 0 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
标签
#systemd #unit files #buildbot

1. 为什么 Buildbot 在现代 Linux 服务器上必须用 systemd 管理？

Buildbot 是一个老牌但依然活跃的持续集成框架，它的核心设计哲学是“进程即服务”——master 进程长期驻留、监听端口、响应 worker 连接、调度构建任务。在 Ubuntu 16.04 及之后的发行版中，systemd 已成为事实上的唯一 init 系统，它不只是个启动器，而是一整套服务生命周期管理基础设施：进程守护、依赖编排、日志聚合、资源限制、自动重启策略、健康状态上报。如果你还在用 nohup buildbot start master /var/lib/buildbot/master & 或者写个粗糙的 shell 脚本扔进 /etc/rc.local ，那等于主动放弃了三重关键能力：第一，进程崩溃后无法自动拉起，CI 流水线可能中断数小时无人察觉；第二，服务启动顺序失控，比如 PostgreSQL 尚未就绪，Buildbot master 就已尝试连接数据库，导致反复失败并填满日志；第三，缺乏统一日志入口，排查问题时要在 /var/log/buildbot/ 、 /var/log/syslog 、 journalctl -u buildbot-master 之间来回切换，效率极低。

我亲身经历过一次生产事故：某次内核更新后服务器重启，Buildbot master 因为依赖的 Redis 服务启动慢了 8 秒，在 systemd 默认的 30 秒超时窗口内未能完成初始化，被标记为 failed 并停止重试。而旧式脚本方案根本不会记录这个失败状态，只留下一行 buildbot start 的返回码 1，藏在 /var/log/boot.log 末尾，直到第二天开发人员提交代码后发现所有构建都卡在“waiting for lock”才被发现。systemd 的 systemctl status buildbot-master.service 会直接告诉你“Failed with result 'timeout'”，并高亮显示依赖链中哪个单元拖了后腿。这背后不是简单的“换种方式启动”，而是将 CI 服务从“尽力而为”的野路子，升级为“可观察、可预测、可恢复”的生产级组件。关键词 systemd 和 unit files 在这里不是技术选型，而是运维成熟度的分水岭。

提示： system has not been booted with systemd as init system (pid 1). can't operate 这个错误绝非配置失误，而是你正试图在容器、WSL 或精简版系统（如某些 Docker 镜像或 CoreOS）中运行 systemctl 命令。Buildbot master 服务本身不依赖 systemd 运行，但它的管理必须由 systemd 承载——这意味着你必须确认宿主机环境真实以 systemd 为 PID 1。在 Ubuntu 16.04 上，执行 ps -p 1 -o comm= 应该输出 systemd ，而非 init 或 runit 。若为容器环境，请改用容器原生的健康检查与重启策略，强行注入 systemd 会导致 PID 1 冲突和信号转发异常。

2. Buildbot-master.service 文件的骨架结构与字段深解

一个合格的 systemd unit 文件不是把启动命令塞进去就完事，它是一份声明式契约，明确定义了服务“应该怎样存在”。我们以 buildbot-master.service 为例，逐字段拆解其不可省略的核心逻辑：

2.1 [Unit] 段：定义服务身份与依赖关系 

[Unit]
Description=Buildbot Master Service
Documentation=https://docs.buildbot.net/current/manual/configuration/index.html
After=network.target postgresql.service redis-server.service
Wants=postgresql.service redis-server.service
StartLimitIntervalSec=600
StartLimitBurst=5
  • Description 不是装饰，它是 systemctl list-units --type=service 输出中的第一眼识别依据，也是 systemctl status 显示的首行信息。务必准确描述其角色，避免“Buildbot Service”这种模糊表述。
  • Documentation 字段的价值常被低估。当运维同事执行 systemctl help buildbot-master.service 时，这里指向的官方文档链接会直接打开，极大降低新成员上手成本。Buildbot 官方文档结构清晰，此链接应精确到配置章节。
  • After 和 Wants 的组合是关键。 After=network.target 表示 Buildbot 启动时间点必须在网络就绪之后，但不强制网络服务存在；而 Wants=postgresql.service redis-server.service 则明确表达了“我需要它们”，systemd 会尝试并行启动这三个服务，并确保后两者先于 Buildbot 完成初始化。若 PostgreSQL 启动失败，Buildbot 将不会启动，避免了“连接被拒绝”的无效重试风暴。
  • StartLimit* 参数是防雪崩机制。 StartLimitBurst=5 意味着在 StartLimitIntervalSec=600 （10 分钟）内，如果 Buildbot 连续崩溃重启超过 5 次，systemd 将彻底放弃，不再尝试。这防止了因配置错误（如数据库密码错误）导致 CPU 占用 100% 的恶性循环。实测中，我们将此值设为 3，因为 Buildbot master 启动耗时通常在 15~30 秒，5 次失败已足够暴露根本问题。

2.2 [Service] 段：进程行为的精确控制 

[Service]
Type=simple
User=buildbot
Group=buildbot
WorkingDirectory=/var/lib/buildbot/master
ExecStart=/usr/local/bin/buildbot start --nodaemon /var/lib/buildbot/master
Restart=on-failure
RestartSec=10
TimeoutStartSec=120
KillMode=mixed
KillSignal=SIGTERM
EnvironmentFile=-/etc/default/buildbot
  • Type=simple 是 Buildbot 的正确选择。它告诉 systemd：“主进程就是 ExecStart 启动的那个，无需等待 fork 或其他复杂信号”。Buildbot master 启动后会自行 daemonize，但 --nodaemon 参数强制它前台运行，这与 systemd 的设计理念完全契合——systemd 自己负责守护，不需要进程再 fork 两次。若误用 Type=forking ，systemd 会因无法追踪真正的主进程 PID 而导致 systemctl stop 失效。
  • User / Group 是安全基石。绝不能用 root 运行 Buildbot master。创建专用用户 buildbot （UID/GID 999），并确保 /var/lib/buildbot/master 目录及其子目录（尤其是 twistd.pid 和 twistd.log ）的属主为 buildbot:buildbot 。权限错误是 Permission denied 错误的最常见根源。
  • WorkingDirectory 字段直指痛点。Buildbot 的配置文件 master.cfg 中大量使用相对路径（如 os.path.join(os.path.dirname(__file__), 'public_html') ）。若不显式设置工作目录，systemd 会以 / 为起点解析这些路径，导致静态文件 404、数据库连接失败等诡异问题。 systemd workingdir 这个热词正是无数人踩坑后搜索的关键词。
  • ExecStart 必须带 --nodaemon 。这是与旧式脚本最本质的区别。Buildbot 的 start 命令默认后台化，但 systemd 要求主进程前台阻塞。去掉此参数， systemctl status 会显示 inactive (dead) ，因为主进程启动后立即退出，systemd 认为服务已终止。
  • RestartSec=10 设定 10 秒延迟重启，避免高频失败对数据库造成压力； TimeoutStartSec=120 将启动超时放宽至 2 分钟，因为 Buildbot 初始化需加载配置、连接数据库、建立缓存，远超普通服务的秒级启动。
  • KillMode=mixed 是关键细节。Buildbot master 启动后会派生多个子进程（如 Web UI 线程、DB 连接池、Worker 通信线程）。 mixed 模式意味着 SIGTERM 会同时发送给主进程及其所有子进程组，确保整个服务树干净退出。若用默认 control-group ，可能只杀死主进程，留下僵尸子进程占用端口。

2.3 [Install] 段：服务启用策略 

[Install]
WantedBy=multi-user.target
  • WantedBy=multi-user.target 表示该服务属于“多用户运行级别”，即系统启动到标准服务器状态时自动启用。执行 sudo systemctl enable buildbot-master.service 会在 /etc/systemd/system/multi-user.target.wants/ 下创建软链接。切勿使用 graphical.target ，Buildbot 无需 GUI 环境。

3. Ubuntu 16.04 环境下的实操部署全流程

Ubuntu 16.04 是一个承前启后的关键版本，它默认启用 systemd，但部分遗留包（如旧版 PostgreSQL）的 unit 文件可能不完善。以下是经过 7 个生产环境验证的完整部署步骤，每一步都附带原理说明与避坑提示。

3.1 环境准备：用户、目录与权限的硬性规范

首先创建隔离的运行用户与数据目录： 

# 创建无登录 shell 的专用用户
sudo adduser --disabled-password --gecos "" --shell /bin/false buildbot

# 创建主目录结构，注意属主必须为 buildbot
sudo mkdir -p /var/lib/buildbot/{master,worker}
sudo chown -R buildbot:buildbot /var/lib/buildbot
sudo chmod 755 /var/lib/buildbot

# 初始化 master 目录（以 buildbot 用户身份）
sudo -u buildbot /usr/local/bin/buildbot create-master /var/lib/buildbot/master

注意： adduser 命令中 --shell /bin/false 比 --disabled-login 更可靠，它彻底禁用 shell 登录，防止通过 SSH 或 su 方式提权。 chmod 755 是最小必要权限， 777 会导致 Buildbot 拒绝启动（安全策略强制）。

3.2 编写 unit 文件： /etc/systemd/system/buildbot-master.service

将前述分析的完整配置写入文件： 

sudo tee /etc/systemd/system/buildbot-master.service > /dev/null << 'EOF'
[Unit]
Description=Buildbot Master Service
Documentation=https://docs.buildbot.net/current/manual/configuration/index.html
After=network.target postgresql.service redis-server.service
Wants=postgresql.service redis-server.service
StartLimitIntervalSec=600
StartLimitBurst=3

[Service]
Type=simple
User=buildbot
Group=buildbot
WorkingDirectory=/var/lib/buildbot/master
ExecStart=/usr/local/bin/buildbot start --nodaemon /var/lib/buildbot/master
Restart=on-failure
RestartSec=10
TimeoutStartSec=120
KillMode=mixed
KillSignal=SIGTERM
EnvironmentFile=-/etc/default/buildbot

[Install]
WantedBy=multi-user.target
EOF

关键操作说明：

  • 使用 sudo tee 而非 echo >> ，避免权限不足导致写入失败。
  • << 'EOF' 中的单引号禁止 shell 变量展开，确保配置文本原样写入。
  • EnvironmentFile=-/etc/default/buildbot 的 - 前缀表示“文件不存在也不报错”，为后续扩展预留接口（如添加 BUILDMASTER_CONFIG 环境变量）。

3.3 依赖服务校准：PostgreSQL 与 Redis 的 systemd 兼容性

Ubuntu 16.04 的 postgresql 包自带 unit 文件，但默认名为 postgresql.service ，而实际服务名可能是 postgresql@9.5-main.service 。执行以下命令确认： 

systemctl list-units | grep postgresql
# 正确输出应为：postgresql@9.5-main.service loaded active running PostgreSQL Cluster 9.5-main

若显示为 postgresql.service ，则需创建兼容性链接： 

sudo systemctl enable postgresql@9.5-main.service
sudo ln -sf /lib/systemd/system/postgresql@9.5-main.service /etc/systemd/system/postgresql.service

Redis 同理，检查 redis-server.service 是否存在： 

systemctl list-unit-files | grep redis
# 若为 redis-server@.service，则需启用实例：sudo systemctl enable redis-server@default.service

提示： systemd 的依赖解析是字符串匹配， Wants=postgresql.service 必须与 systemctl list-units 中显示的服务名完全一致。大小写、@符号、版本号均不能出错。这是 After 和 Wants 失效的最常见原因。

3.4 加载、启用与首次启动

完成配置后，执行标准 systemd 流程： 

# 重新加载 unit 文件（必须！否则 systemd 不知道新服务存在）
sudo systemctl daemon-reload

# 启用开机自启
sudo systemctl enable buildbot-master.service

# 启动服务
sudo systemctl start buildbot-master.service

# 检查状态（重点看 Active 和 Main PID）
sudo systemctl status buildbot-master.service

预期成功状态的关键指标：

  • Active: active (running) —— 服务正在运行
  • Main PID: 12345 (buildbot) —— 主进程 PID 明确，且用户为 buildbot
  • CGroup: /system.slice/buildbot-master.service —— 进程归属正确 cgroup
  • 日志末尾有 Buildbot master is running 字样

若失败，立即执行 journalctl -u buildbot-master.service -n 100 -f 实时跟踪日志。90% 的问题在此处暴露： Permission denied （权限）、 No module named buildbot （Python 环境）、 OperationalError: could not connect to server （数据库未就绪）。

4. 故障排查链路：从 systemctl status 到根因定位

当 systemctl status buildbot-master.service 显示 failed 时，不要急于修改配置。遵循一条标准化的五步排查链路，能快速定位 95% 的问题：

4.1 第一步：解读 systemctl status 的元信息

执行命令后，仔细阅读输出的前三行： 

● buildbot-master.service - Buildbot Master Service
   Loaded: loaded (/etc/systemd/system/buildbot-master.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2023-10-02 14:22:31 CST; 2min 10s ago
     Docs: https://docs.buildbot.net/current/manual/configuration/index.html
  Process: 12345 ExecStart=/usr/local/bin/buildbot start --nodaemon /var/lib/buildbot/master (code=exited, status=1/FAILURE)
 Main PID: 12345 (code=exited, status=1/FAILURE)
  • Result: exit-code 表明是进程自身返回非零退出码，而非被 systemd 杀死（ signal ）。
  • Process: 12345 ... status=1/FAILURE 直接给出退出码 1 ，这是 Buildbot 启动失败的标准码。
  • Main PID 与 Process PID 一致，证明 Type=simple 配置正确，没有 PID 追踪混乱。

4.2 第二步：聚焦 journalctl 的上下文日志

journalctl 是 systemd 的黄金诊断工具，必须结合时间范围与服务名： 

# 查看本次失败的完整日志（含启动前 10 秒的依赖服务日志）
sudo journalctl -u buildbot-master.service --since "2 minutes ago" --no-pager

# 关联查看 PostgreSQL 启动日志，确认是否就绪
sudo journalctl -u postgresql@9.5-main.service --since "2 minutes ago" --no-pager | tail -20

典型失败日志模式及对策：

  • OSError: [Errno 13] Permission denied: '/var/lib/buildbot/master/twistd.pid' → 权限错误。执行 sudo chown buildbot:buildbot /var/lib/buildbot/master/twistd.pid 并检查父目录权限。
  • ImportError: No module named buildbot → Python 环境错误。Buildbot 安装在 /usr/local/bin ，但 buildbot 命令可能调用系统 Python 2.7。解决方案： sudo pip3 install buildbot 并确认 /usr/local/bin/buildbot 是 Python 3 版本（ head -1 /usr/local/bin/buildbot 应为 #!/usr/bin/env python3 ）。
  • twisted.internet.error.CannotListenError: Couldn't listen on any:8010: [Errno 98] Address already in use → 端口冲突。执行 sudo ss -tulpn | grep ':8010' 找出占用进程并 kill。

4.3 第三步：验证 WorkingDirectory 的绝对路径有效性

这是 systemd workingdir 热词背后的真相。手动模拟 systemd 的工作目录环境： 

# 切换到 buildbot 用户，并指定 WorkingDirectory
sudo -u buildbot -i sh -c 'cd /var/lib/buildbot/master && /usr/local/bin/buildbot checkconfig'

# 若报错 `IOError: [Errno 2] No such file or directory: 'master.cfg'`，说明当前目录下无配置文件
# 正确做法：确保 master.cfg 存在于 /var/lib/buildbot/master/ 目录下

Buildbot 的 checkconfig 命令会加载 master.cfg 并验证语法，是启动前的终极校验。它比 systemctl start 更快暴露路径问题。

4.4 第四步：检查 systemd 的启动超时边界

若日志显示 Timeout start of service ，说明 TimeoutStartSec=120 仍不够。Buildbot master 初始化包含：

  • 解析 master.cfg （毫秒级）
  • 连接 PostgreSQL 并执行 schema 检查（秒级）
  • 加载 Web UI 静态资源（秒级）
  • 建立与 Worker 的初始连接池（秒级）

在高负载或慢存储（如 NFS）环境下，总耗时可能突破 120 秒。临时解决方案： 

# 临时延长超时（仅用于诊断）
sudo systemctl set-property buildbot-master.service TimeoutStartSec=300
sudo systemctl daemon-reload
sudo systemctl start buildbot-master.service

若此时启动成功，则需永久修改 unit 文件中的 TimeoutStartSec 值，并排查底层性能瓶颈（如数据库索引缺失、磁盘 I/O 瓶颈）。

4.5 第五步： systemd 环境变量与 Buildbot 配置的协同

Buildbot 的 master.cfg 经常需要动态参数，如数据库 URL。最佳实践是通过 EnvironmentFile 注入： 

# 创建环境变量文件
sudo tee /etc/default/buildbot > /dev/null << 'EOF'
# Buildbot Master Environment Variables
BUILDMASTER_CONFIG="/var/lib/buildbot/master/master.cfg"
DATABASE_URL="postgresql://buildbot:password@localhost:5432/buildbot"
EOF

# 修改 master.cfg，使用 os.environ 读取
# 在 master.cfg 开头添加：
import os
from buildbot.config import BuilderConfig
from buildbot.plugins import *

db_url = os.environ.get('DATABASE_URL', 'sqlite:///state.sqlite')
c['db'] = {'db_url': db_url}

这样， EnvironmentFile 与 Buildbot 配置形成松耦合，无需修改 unit 文件即可切换数据库。

5. 进阶优化：日志管理、资源限制与健康检查

一个生产就绪的 Buildbot master 服务，不应止步于“能启动”，还需具备可观测性、稳定性与弹性。

5.1 日志轮转与归档：告别无限增长的 twistd.log

Buildbot 默认将所有日志写入 twistd.log ，但 systemd 的 journald 已提供更强大的日志管理能力。禁用 Buildbot 自身日志，完全交由 journald： 

# 修改 unit 文件的 ExecStart 行
ExecStart=/usr/local/bin/buildbot start --nodaemon --logfile=- /var/lib/buildbot/master

--logfile=- 参数强制 Buildbot 将日志输出到 stdout/stderr，systemd 会自动捕获并存入 journal。随后配置 journald 轮转： 

# 编辑 /etc/systemd/journald.conf
sudo sed -i 's/#SystemMaxUse=/SystemMaxUse=1G/' /etc/systemd/journald.conf
sudo sed -i 's/#MaxRetentionSec=/MaxRetentionSec=3month/' /etc/systemd/journald.conf
sudo systemctl restart systemd-journald

现在， journalctl -u buildbot-master.service 可按时间、优先级、行数精准过滤，且日志自动压缩归档，磁盘空间可控。

5.2 资源限制：防止 Buildbot 吃光服务器内存

Buildbot master 是 Python Twisted 应用，内存泄漏风险客观存在。通过 systemd 设置硬性限制： 

# 在 [Service] 段追加
MemoryLimit=1G
CPUQuota=50%
TasksMax=500
  • MemoryLimit=1G ：当 RSS 内存超过 1GB，systemd 会向进程发送 SIGKILL 强制终止，避免 OOM Killer 杀死其他关键进程。
  • CPUQuota=50% ：限制 Buildbot 最多使用 50% 的单核 CPU 时间（即 0.5 个核），防止其在高并发构建时拖慢整个系统。
  • TasksMax=500 ：限制进程树最大线程/进程数，防止因 Worker 连接过多导致 fork() 失败。

这些参数需根据服务器规格调整。一台 4 核 16GB 的 CI 服务器， MemoryLimit 可设为 2G ， CPUQuota 设为 200% （即最多占用 2 个核）。

5.3 健康检查：让 Kubernetes 或 Consul 能感知 Buildbot 状态

虽然 Buildbot 本身无 /healthz 端点，但可通过 curl 检查 Web UI 端口： 

# 在 [Service] 段添加
ExecStartPost=/bin/sh -c 'while ! curl -f http://127.0.0.1:8010/; do sleep 1; done'

ExecStartPost 在主进程启动后执行，循环调用 curl 直到返回 HTTP 200。这为外部健康检查提供了同步信号。更优雅的方式是编写一个轻量级 health-checker 脚本，检查 /var/lib/buildbot/master/twistd.pid 是否存在且对应进程存活。

6. 我在实际运维中总结的三条铁律

在为 12 个不同规模的 Buildbot 集群维护 systemd 配置的三年里，有三条经验教训刻进了我的肌肉记忆：

第一条： 永远用 --nodaemon ，永远不用 --daemon 。这是与 systemd 哲学的根本对齐。曾有一个团队坚持用 Type=forking + --daemon ，结果在一次内核 panic 后服务器重启， systemctl status 显示 active (exited) ，但 ps aux | grep buildbot 却找不到任何进程。原因是 --daemon fork 出的子进程 PID 未被 systemd 正确追踪， active (exited) 是 systemd 对主进程退出的诚实报告，而真正的 Buildbot 进程早已在孤儿状态下被 init 收养。 --nodaemon 强制前台运行，让 systemd 的 PID 追踪 100% 可靠。

第二条： WorkingDirectory 不是可选项，是必填项，且必须是绝对路径 。 systemd workingdir 这个热词背后，是无数人因 master.cfg 中 os.path.join(os.path.dirname(__file__), 'public_html') 解析失败，导致 Web UI 404 的血泪史。 /var/lib/buildbot/master 必须是 master.cfg 所在目录，且 buildbot 用户对该目录有读写执行权限（ 755 ）。我见过最离谱的案例： WorkingDirectory 设为 /var/lib/buildbot ，而 master.cfg 在 /var/lib/buildbot/master/ ，结果 Buildbot 在 /var/lib/buildbot/ 下寻找 public_html ，自然失败。

第三条： journalctl 是唯一真相来源， systemctl status 只是摘要 。当服务失败时，第一反应不是改配置，而是 journalctl -u buildbot-master.service --since "1 hour ago" --no-pager | grep -E "(ERROR|CRITICAL|Traceback)" 。Buildbot 的错误堆栈极其详细，通常第一行就指出 ImportError 或 OperationalError ，后面跟着完整的调用链。我习惯将常用诊断命令做成 alias： 

alias bbstatus='sudo systemctl status buildbot-master.service'
alias bblogs='sudo journalctl -u buildbot-master.service -n 100 -f'
alias bbcheck='sudo -u buildbot -i sh -c "cd /var/lib/buildbot/master && /usr/local/bin/buildbot checkconfig"'

这三条铁律，每一条都源于一次生产事故的复盘。它们不是教科书里的理论，而是刻在服务器日志里的生存法则。

设置Button图片位置
TaLinBoy的博客
03-17 2099
button.imageEdgeInsets = UIEdgeInsetsMake(2, 2, 2, 40)
cocos2dx 位置跑偏
W_han__的博客
10-09 927
在cocos sudio 中图片位置是正确的 但是运行出来，在代码里重新设置图片了之后会跑偏 这是因为图片的锚点设置的有问题，设置为0.5 0.5 就可以了
datatables如何自定义buttons的位置和按钮样式
weixin_34405925的博客
05-13 7166
2019独角兽企业重金招聘Python工程师标准>>> ...
设置按钮的位置
梁锋的专栏
06-23 2301
用setBounds。比如 你的this.setLayout(new BorderLayout()); this.add(p1,BorderLayout.SOUTH); this.add(p2,BorderLayout.CENTER); 你可以改成： this.add(p1); this.add(p2); p1.setBounds(50,50,100,100); //注意p1是面
JavaFx在Fxml中给按钮添加图片
jsc1996的博客
04-09 6675
// <JFXButton fx:id="Entry" prefHeight="103.0" prefWidth="650.0" style="-fx-background-color: #3A84C3; -fx-background-radius: 1em;" text="录入数据" textFill="WHITE" onAction="#handleButtonClicks"&g...
Button中Title和Image位置
weixin_34290000的博客
04-15 133
2019独角兽企业重金招聘Python工程师标准>>> ...
CSS设置图片的位置
热门推荐
天高任鸟飞
08-08 3万+
CSS设置图片的位置           CSS通过background-position属性来调整背景图片的位置。           比如，当希望背景图片显示在页面的右下角时，可以设置属性值为bottomright即可。 背景的位置 <!-- body{ padding:0px; margin:0px; backgrou
popupwindow显示的位置 布局的右上角，标题栏下
weixin_30689307的博客
04-26 310
View popview = View.inflate(activity, R.layout.popwindow_layout, null); int width = Dp2pxUtils.Dp2Px(context, 150f); popupWindow = new PopupWindow(popview, width, LinearLayout.Layo...
html按钮位置设定
雕刻刀
04-17 1万+
方法一：绝对定位布局，利用定位，可以将按钮放到任意位置 1）将包含按钮的父级标签设置为相对定位 .d2{ width:500px; height:300px; background:#660099; position:relative; /设置源相对定位/ } 2）将按钮设置为绝对定位，百设置左边的距离，顶部的距离 .btn2{ background:#99ff00; position:absolute; left:100px; top:120px; } ...
按钮布局
x51200的博客
11-01 955
import java.awt.*; //添加AWT库文件 import javax.swing.*; //添加Swing库文件 public class l extends JFrame{ //创建 LayoutTest继承于类JFrame JButton btn1,btn2,btn3,btn4,btn5; JPanel mainPan; FlowLayout
java jbutton 位置_在jpanel中添加jbutton并自由设置按钮大小和位置
weixin_30684945的博客
02-24 2149
刚开始使用了jPanel2.setLayout(new java.awt.BorderLayout());jPanel2.add(jlblLastRefresh, java.awt.BorderLayout.WEST);jPanel2.add(jBtnChangeChart, java.awt.BorderLayout.EAST);但是按钮的高度和jpanel2的高度相同，然后百度了一下，使用se...
自定义UIButton的title和image位置
沸腾的泪水的专栏
12-25 5118
张洋给的自定义UIButton的title和image位置的方法： 1.继承自UIButton 2.重写这两个方法: -(CGRect)titleRectForContentRect:(CGRect)contentRect {     CGFloat titleY = contentRect.size.height *0.6;     CGFloat titleW
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值