TL;DR
If your user-level systemd service on Ubuntu doesn't start automatically after a reboot, enable it with systemctl --user enable HappyNotes.Api.service
. If you encounter an error about an existing symlink, remove it first. To allow the service to run without an active user session, enable lingering using loginctl enable-linger <username>
. Finally, ensure your service file has the correct [Install]
section and reboot to check if the service starts as expected.
The Problem
After configuring a user-level service with systemd, you might find that it remains inactive after rebooting your server. For example, you may run the command:
systemctl --user status HappyNotes.Api.service
And see output indicating that the service is inactive (dead) and disabled.
Solution Steps
-
Enable the Service:
First, ensure your service is enabled to start at boot:
systemctl --user enable HappyNotes.Api.service
If you encounter an error stating that the service is already linked, you may need to remove the existing symlink:
rm ~/.config/systemd/user/default.target.wants/HappyNotes.Api.service
-
Check for Linger:
User-level services require an active user session to run. To allow your user services to run even when you're not logged in, enable lingering:
loginctl enable-linger $USER
-
Verify Service Configuration:
Ensure your service file has the correct [Install]
section:
[Install]
WantedBy=default.target
-
Reboot and Test:
After enabling lingering and ensuring your service is set up correctly, reboot your server:
sudo reboot
After rebooting, check the status of your service again:
systemctl --user status HappyNotes.Api.service
By following these steps, you can ensure that your user-level systemd services start automatically after a reboot on Ubuntu. Enabling lingering
is the key, which is particularly useful for server environments where continuous operation of services is desired.
When working with Docker containers in production, understanding volume management is crucial. This guide will help you make informed decisions about when to use named volumes versus bind mounts (directory mapping).
TL;DR
- Use named volumes for persistent data (databases, application state)
- Use bind mounts for config files and development
- Combine both in production for optimal setup
Understanding the Basics
Named Volumes
volumes:
- postgres_data:/var/lib/postgresql/data
Docker manages these volumes internally. Think of them as "black boxes" that Docker handles for you.
Bind Mounts (Directory Mapping)
volumes:
- ./config:/etc/app/config
You manage these directories directly on your host machine.
When to Use What?
Use Named Volumes For:
- Database storage
- Application state
- Generated assets
- Any data that needs persistence but not direct access
Benefits:
- Managed by Docker
- Better performance
- Automatic permissions handling
- Easier backups
- Portable across environments
- Built-in volume management commands
Use Bind Mounts For:
- Configuration files
- Static files during development
- Source code in development
- Any files you need to edit from host
Benefits:
- Direct access from host
- Easy to edit
- Version control friendly
- Quick updates without container restart
- Shareable across environments
Real-World Example
Here's a typical production setup combining both approaches:
version: '3'
services:
db:
image: postgres:15
volumes:
# Data persistence with named volume
- postgres_data:/var/lib/postgresql/data
# Configuration with bind mounts
- ./config/postgres.conf:/etc/postgresql/postgresql.conf:ro
nginx:
image: nginx
volumes:
# Config files with bind mounts
- ./config/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
- ./config/nginx/conf.d:/etc/nginx/conf.d:ro
# Static files with bind mount
- ./static:/usr/share/nginx/html:ro
app:
image: node:18
volumes:
# Application data with named volume
- app_data:/app/data
# Config with bind mount
- ./config/app.json:/app/config/app.json:ro
volumes:
postgres_data:
app_data:
Migration Tips
Moving from Bind Mounts to Named Volumes
If you're currently using bind mounts for data and want to switch to named volumes:
# Create new volume
docker volume create myapp_data
# Copy data
docker run --rm \
-v /old/path:/source:ro \
-v myapp_data:/destination \
ubuntu \
bash -c "cp -av /source/. /destination/"
Best Practices
-
Named Volumes
- Always use for persistent data
- Name them descriptively
- Regular backups
- Don't manipulate directly on host
-
Bind Mounts
- Use read-only (
:ro
) when possible
- Keep configs in version control
- Use relative paths for portability
- Store in a
config/
directory
-
General
- Document your volume strategy
- Regular backups for both types
- Monitor disk usage
- Use clear naming conventions
Common Pitfalls to Avoid
- Using bind mounts for database storage
- Hardcoding absolute paths
- Not setting proper permissions
- Forgetting to backup named volumes
- Direct manipulation of named volume directories
Conclusion
The key to successful Docker volume management is using the right tool for the job:
- Named volumes for data that needs persistence
- Bind mounts for configs and development
- Combine both for a robust production setup
Remember: When in doubt, prefer named volumes for data and bind mounts for configuration.
When using sed
on Windows, you might run into unexpected behavior, especially with line endings. If you're editing files with Windows-style line endings (\r\n
), sed
can unintentionally modify them, causing issues with tools like git diff
. Here’s how you can use sed
effectively on Windows without breaking your line endings.
The Problem: Unexpected \r\n
to \n
Conversion
On Windows, text files usually use \r\n
(carriage return + line feed) as line endings. However, sed
, depending on its mode, may treat these as Unix-style \n
line endings, removing the \r
and leading to issues like:
- Files appearing changed when they shouldn’t.
- Tools like
git diff
showing extra changes due to the altered line endings.
Solution: Use sed -b
to Prevent Line Ending Conversion
To avoid this, you need to force sed
to operate in binary mode, which prevents automatic conversion of line endings.
Example:
sed -b 's/old_text/new_text/' filename.txt
In this example:
- The
-b
flag ensures sed
works in binary mode, preserving the \r\n
line endings.
- The
s/old_text/new_text/
part performs the actual substitution.
绝对支配别人会产生大量的多巴胺,比吸毒还 high,而且成瘾。不要給他人這樣的機會。
不直接创造财富的群体,如果始终处在分配财富的有利位置上,而创造财富的群体又无法制约他们,那么其长期结果一定是经济停滞与社会衰败。
一张图说清英文地理术语
除了生病以外,所有的痛苦都是价值观带来的。
哈耶克说:金钱是人类发明的最伟大的自由工具。只有金钱会向穷人开放,而权力不会;
愿意放弃自由来换取保障的人,最终既得不到自由,也得不到保障;
一个富人得势的世界,总比一个只有得势的人才能富有的世界要好得多;
如果一个人不需要服从任何人,只需服从法律,那么他就是自由的;
为什么一些问题永远得不到解决?因为解决问题的人,正是制造问题的人;
如果允许人类自由迁徒,那人流的方向就是文明的方向。
米福根:恨可以登堂入室,爱却需要躲藏。
过去,我们将已知最耐用的材料用于整座建筑,比如说花岗岩石块,其成果仍令当代人赞赏、惊叹。但我们却几乎不再模仿这种行为,因为石料的采集、切割、运输和搭建都极其考验耐心,而耐心正是我们不再具备的品质。摘自《没有我们的世界》
网摘:"与其担心宏观经济,不如关注自己。你对自己生活的影响,往往比宏观经济对你的影响大得多。"
公司裁员肯定会对一个人产生影响,但是它决定不了你的未来,你自己才是最大的影响因素。
世界最大对冲基金"桥水基金"创始人达里奥,说过一句话,可以用在这里:"如果你忧心忡忡,那是不必要的;如果你毫不担心,那么你需要担心。"
TNT007: 我可能比较老派,认为如果恋爱还需要技巧的话,那就不是爱情。爱情是双向的不可自抑的。
小青: I am who I am becoming.
网摘:作家兼冥想老师大卫·凯恩(David Cain)鼓励他的学生别当“好天气的冥想者”。同样,你也不想成为一名努力与否全凭心情好坏的运动员、作家,等等。当一个习惯对你来说真正重要时,你必须愿意在任何心情下坚持下去。专业人士不会因自己心情不好而改变行动的时间表。他们可能享受不到乐趣,但是他们仍能做到坚持不懈。
《成为乔布斯》
作者:布伦特·施兰德 里克·特策利
175个笔记
我的点评:
◆ 2016/10/15 认为好看
虽然不可能读了这本书就能真的“成为乔布斯”,成为更好的自己却是非常可能的。要成为一个更出色的人,直率,不拐弯抹角比世故或者中庸更有价值,更容易结交到志同道合的朋友。真想给这本书打一百颗星。
前言
◆ 他总是喜欢对别人的生活方式指手画脚,劝了我好几年让我戒烟。
◆ 是如何改变的,在谁的影响下做出了改变,以及他又是如何将心得体会运用到公司的运作中去的。
◆ 他深信自己的工作所创造的价值,也希望身边的好友能够和他一样,深信他们的工作所创造的价值。
第一章 安拉的花园
◆ 对于一个橱柜来说,别人看不到的底面与表面的抛光一样重要;对于一辆雪佛兰汽车来说,别人看不到的刹车片和汽车的油漆一样重要。
◆ 生命常常被比喻成一条奔流不息的河,世间万物、每个个体都处于永恒的变动中。以这样的世界观来看,追求完美也是一个渐进持续的过程,永远都不可能彻底完成。
◆ 他的脾气如果使用得当,会是非常有效的团队激励工具。
第二章 “我不想当商人”
◆ 财务数据是最好的营销工具
◆ 2016/09/30发表想法
任何行业都是如此
原文:出色的财务数据是引起人们关注的最好方式,在电脑行业尤其如此。
◆ 至繁归于至简
第三章 突破与崩塌
◆ 一点就通的老板和怎么讲都讲不明白的老板是不同的。
◆ 你得经过七层管理层才能找到工程师。一家技术公司变成这样是很危险的。
…more